Re: [gentoo-portage-dev] Package compression header for binhosts
On Mon, 2010-05-31 at 22:16 -0700, Brian Harring wrote: On Mon, May 31, 2010 at 08:32:34PM -0700, Zac Medico wrote: Hi, In order to support alternative compression types for binhost packages, I was thinking about adding support for a header field in the Packages index file. For example, a header line like PACKAGE_EXTENSION: txz could be used to indicate that clients should download files with txz extensions instead of tbz2 extensions. I'm planning to add support for both tgz [1] and txz extensions. [1] http://bugs.gentoo.org/show_bug.cgi?id=142579 1) requires a version header bump Agreed. But there were some other pending changes for VERSION: 1 Any planned changes to the format should be documented on https://bugs.gentoo.org/show_bug.cgi?id=263994 2) a header alone isn't useful unless it's specifiable per cpv entry; thus it must be inheritable Per CPV entries is going to bloat the format and make me carry around a more data on a per pkg basis then I'd want to. How about we run with zac's idea but use tools to convert a full repo over to $EXTENTION This should keep the portage code fast as well as it checks for invalid binpkgs all the time. Having to have portage process a ton of ever growing extentions is just going to be slow. 3) PACKAGE_EXTENSION is overly verbose and unclear it's specifying the compressor too; it's intention is for compression, state it as such (I mention this in light of URI's existance where PACKAGE_EXTENSION would only be a hint of compressor) Re: #1, there is a decent set of optimizations I'm kicking around in pkgcore for the next version- a discussion should probably be started there. Offhand, having a compression specific header (a simple enumeration of known compressors) and a DEFAULT_URI that is python string No go bro. The 'Packages' format should be independent of python. interpolation assembled (for example, DEFAULT_URI=%(host)s/%(category)s/%(pf)s.txz) seems wiser. Via doing what I'm suggesting, it would be possible to do binpkg repository 'views' w/out having to map each binpkg into the url space for it. ~harring -- Ned Ludd so...@gentoo.org Gentoo Linux
Re: [gentoo-portage-dev] add UUID for comparison of installed package to binary package?
On Sun, 2010-02-14 at 12:11 -0800, Zac Medico wrote: On 02/14/2010 04:36 AM, Brian Harring wrote: This gets nasty... you're basically talking about the rpm equivalent of EPOCH. Not a fan of an adhoc UUID (especially since it'll become standard via portage doing it), but a *timestamp* for the build, labeled as such, gets you what you want and is usable for other things- detecting when to rebuild a scm package for example. That route gets my vote, and should also address your intentions. ~harring Ok, then how about a vdb entry named CTIME that contains an integer number of seconds since the unix Epoch? That would be UNIXTIME vs CTIME I'd think.
[gentoo-dev] Re: A Little Council Reform Anyone?
On Thu, 2009-07-02 at 22:14 +0200, Christian Faulhammer wrote: Hi, in general you speak about the council but do you have any concrete plans/goals you want to achieve? I think we are in the information gathering phase right now on how to best proceed. So nothing concrete as of this point. More abstract ideas at this point. Ned Ludd so...@gentoo.org: The dev population is quite a strange beast. I never expected to win. Nor did I, especially because you were quite low on my ballot. Congratulations. The devs have a voice one time of the year: when it comes time to vote. But what about the rest of the year? What happens when the person you voted for sucks? You are mostly powerless to do anything other than be really vocal in what seems like a never ending battle. That needs to change. I'm not quite sure how. But I'd like to see the dev body have a year-round voice in the council. Either via quick votes year-round on topics or simply by having discussion in the channel. Devs should have a right to voice their concerns to the council and engage in interactive conversations without being labeled troll. We have the forums for quick votes, votify is too much to get a picture of opinions. So use -dev-announce and forums. Another one of the things I'd like to see and help reform with the council. First off it spends way too much time on EAPI/PMS. There is no reason to make the council an extension of the portage team. As member of the PMS team I agree, we have to reach out to more people. No matter how well Ciaran does the job as editor-in-chief the process needs to be broadened to involve other groups, too. For example prefix comes to mind. It was a project I did not like at first. I'm not even a user. And there are things I surely don't like about it as is. But there is community support and it's the icing on the cake for some. So I'll back the fsck up and give credit where it's due. This is a perfectly good example of a project/fork that needs to come back home. Perhaps it's time to cherry pick some more stuff/people out of Sunrise? Fully agree here, my devhood is a product of Sunrise. desultory points out any two council members can decide to approve anything, and that decision is considered to be equivalent to a full council vote until the next meeting. I vaguely recall that rule. I'm not sure about you, but I think that is a little to much power to put in the hands of a few. Any dev mind if we dump that power? Maybe extend that to three, but leave such a emergency measure in place. Meetings will likely go back to one time per month and be +m with +v be handed out per request with open chat pre/post meetings. The reason for this is to keep the meetings on-track. I won't engage in endless discussions. Facts can be presented. They will be reviewed on merit, technical and social. Agree. The reason the meetings should go back to monthly is to allow those who are council members in Gentoo to accomplish things other than the council only. We all have personal lives and we all have our respective roles we play outside of the council. Another note on meetings. The time they are held currently don't fit well with my work schedule. That you have to discuss with your fellow council members. So lets have some damn fun again !...@#$ Oh yeah! V-Li -- Ned Ludd so...@gentoo.org Gentoo Linux
[gentoo-dev] A Little Council Reform Anyone?
The dev population is quite a strange beast. I never expected to win. Why would you vote for somebody who did not even publish a manifesto? I don't know but I love you for it. My only intention was to help offset dev-zero being able force the will of outside forces upon us. Well that has been accomplished for now (w00t). But I never ever expected to be ranked so high. /me blushes So that means you guys/gals expect stuff from me. Well as I never wrote a manifesto but you still voted for me, I guess I should share some of my ideas on what I'd like to see happen over the following year. The devs have a voice one time of the year: when it comes time to vote. But what about the rest of the year? What happens when the person you voted for sucks? You are mostly powerless to do anything other than be really vocal in what seems like a never ending battle. That needs to change. I'm not quite sure how. But I'd like to see the dev body have a year-round voice in the council. Either via quick votes year-round on topics or simply by having discussion in the channel. Devs should have a right to voice their concerns to the council and engage in interactive conversations without being labeled troll. Another one of the things I'd like to see and help reform with the council. First off it spends way too much time on EAPI/PMS. There is no reason to make the council an extension of the portage team. Portage is still the official package manager of Gentoo. Granted it's good to accommodate others to an extent and I've always kept an open mind on other tools. Alternatives are good as there is always the right tool for the task at hand. But the council really should not be getting involved most of the time unless there is a conflict which can't be worked out among the masses and those trying to get portage to adopt new features. If the dev body wants it otherwise then I'd like to turn my vote over to you the devs. Each and every time the council wants/has to vote on an EAPI/PMS feature then I'll happily put my vote in your hands. You fire up that old votify system and use my vote as yours. Note however that zmedico is not in favor of his time being wasted on deciding what PMS/EAPI features are good. He simply likes bugs and solving those. He likes giving us new features and tends to be more in favor of the devs and community figuring out what is best for us. An EAPI review committee could work well also. As long as we could get non bias people in there. The council should be more about community vs technical issues only. We have lots of top level projects within Gentoo which have simply given up on the council as being an outlet to accomplish anything useful. It should be our job to look at the projects in Gentoo. Look at the ones that have a healthy community and encourage and promote them in ways. For example prefix comes to mind. It was a project I did not like at first. I'm not even a user. And there are things I surely don't like about it as is. But there is community support and it's the icing on the cake for some. So I'll back the fsck up and give credit where it's due. This is a perfectly good example of a project/fork that needs to come back home. Perhaps it's time to cherry pick some more stuff/people out of Sunrise? desultory points out any two council members can decide to approve anything, and that decision is considered to be equivalent to a full council vote until the next meeting. I vaguely recall that rule. I'm not sure about you, but I think that is a little to much power to put in the hands of a few. Any dev mind if we dump that power? Meetings will likely go back to one time per month and be +m with +v be handed out per request with open chat pre/post meetings. The reason for this is to keep the meetings on-track. I won't engage in endless discussions. Facts can be presented. They will be reviewed on merit, technical and social. The reason the meetings should go back to monthly is to allow those who are council members in Gentoo to accomplish things other than the council only. We all have personal lives and we all have our respective roles we play outside of the council. Another note on meetings. The time they are held currently don't fit well with my work schedule. I'm not subscribed directly to the gentoo-dev mailing list anymore outside of post-only. And I don't plan to re-subscribe. I do browse the archives regularly however. If there is some topic that should be brought to my attention please point it out to me directly on irc or CC: me. Thank you all and I will try not to let you down. Unless you were one of the ones who wanted to me lose. Then sorry, but I'm going to have fun disappointing you, by doing what is best for Gentoo. If you have any ideas on how you think the council should function or reform itself. Please start a new thread or email those who think will listen to those ideas. I'm open for some real change as long as it's for the the positive. So lets have some
Re: [gentoo-portage-dev] pretend --columns depends on --quiet?
On Thu, 2009-05-07 at 10:00 +0300, Amit Dor-Shifer wrote:
Hi.
Seems like --columns depends on -q to work:
amit0 ~ # emerge -p --color=n --columns -O -q portage
Rsys-apps/portage 2.1.6.7
amit0 ~ # emerge -p --color=n --columns -O portage
These are the packages that would be merged, in order:
[ebuild R ] sys-apps/portage
[2.1.6.7]
Is this WAD?
10x,
Amit
Yep. This looks like a bug with the [] part of the atom display.
emerge -p --columns portage \
| grep \\[ebuild \
| awk '{print $4-$5}'
Results: sys-apps/portage-[2.1.6.11]
Quick work around that should be safe would be to
tr '[,]' ' , ' |awk '{print $3-$4}'
It is expected however that -q vs no -q will result in the atoms being
at the same index.
--
Ned Ludd so...@gentoo.org
Gentoo Linux
Re: [gentoo-portage-dev] pretend --columns depends on --quiet?
On Thu, 2009-05-07 at 13:18 -0700, Zac Medico wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ned Ludd wrote:
On Thu, 2009-05-07 at 10:00 +0300, Amit Dor-Shifer wrote:
Hi.
Seems like --columns depends on -q to work:
amit0 ~ # emerge -p --color=n --columns -O -q portage
Rsys-apps/portage 2.1.6.7
amit0 ~ # emerge -p --color=n --columns -O portage
These are the packages that would be merged, in order:
[ebuild R ] sys-apps/portage
[2.1.6.7]
Is this WAD?
10x,
Amit
Yep. This looks like a bug with the [] part of the atom display.
emerge -p --columns portage \
| grep \\[ebuild \
| awk '{print $4-$5}'
Results: sys-apps/portage-[2.1.6.11]
Quick work around that should be safe would be to
tr '[,]' ' , ' |awk '{print $3-$4}'
It is expected however that -q vs no -q will result in the atoms being
at the same index.
Correction:
It is expected however that -q vs no -q will NOT result in the atoms
being at the same index.
--
Ned Ludd so...@gentoo.org
Gentoo Linux
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Sat, 2009-04-18 at 12:55 -0400, Mike Frysinger wrote: On Thursday 16 April 2009 19:05:46 Ned Ludd wrote: On Tue, 2009-03-17 at 10:50 -0700, Ned Ludd wrote: On Tue, 2009-03-17 at 13:27 -0400, Mike Frysinger wrote: On Tuesday 17 March 2009 12:59:58 Ned Ludd wrote: There is also a bug with atom parsing iirc on 32bit platforms. gradm was the test case. Think we need to change from int to long. the code is documented as having 64bit limitations for any specific component. the last release doesnt have the updated work i did in qatom to handle the latest atom spec though, and that includes moving from 32bit to 64bit for components ... Sounds good. Maybe another with -rX parsing. if you're thinking of the open bug, that's an eprefix specific extension. they turned the X in -rX into a floating point #. which isnt supported currently. I don't think that was it. But I can't recall well enough off the top of my head the problem that somebody pointed out to me one day on irc while I was probably too busy. The error was pointed out to me again today on irc by jmbsvicetto and hoffie, which reminded me of what I had forgot before in this thread. The problem was/is that qpkg is not handling -rX extensions properly. you'll have to be more specific. like i said, -rX extensions are a prefix extension and not part of the standard tree and/or spec. i'm not going to implement every random thing that someone feels like adding. -mike Heh. I don't think you understand the problem yet. Not a feature request.. It's a real bug/regression. See the bug# that jmbsvicetto filed this morn about it. https://bugs.gentoo.org/266646
Re: [gentoo-portage-dev] prefix portage chaining
On Thu, 2009-03-26 at 08:26 +0100, Markus Duft wrote: On Wed, 2009-03-25 at 11:44 -0700, Ned Ludd wrote: [snip] While much of what you are talking about here mainly applies to prefix, it looks to me from glancing over the code that you might of solved a long standing problem in the embedded world with cross compiling via portage. 222895 If that is the case, then I owe you a beer. one about the size of a keg. lol, thx for the beer ;) hmm... looking over that patch again, the only EPREFIX dependent thing is, that i'm removing EPREFIX from the vartree class again :) so this should pretty much plain apply to main too, and simply work. you may want to rename READONLY_EPREFIX to READONLY_ROOT, but thats it :) the other stuff besides portage modification (baselayout patchery, etc. is prefix specific again, so all you'd need is the portage changes. if you will try it, please let me know if it worked :) with the attached patch sed -i -e 's,READONLY_EPREFIX,READONLY_ROOT,g', and applying to an installed /usr/lib/portage should enable you to do it. (backup /usr/lib/portage - i trust my work, but... we never know for sure :)) then add to make.conf: READONLY_ROOT=/my/other/root:DEPEND i hope this is what you where looking for...! and i hope it doesn't somehow clash with the existing cross compile logic in portage regarding where to merge to... Cheers, Markus patch failed a few hunks for me on ~arch vanilla-portage. I did point out the patch to one of the gentoo embedded/openmoko guys. Think they will be the most eager to test this. In our case if the code did work out whatever you call READONLY_ROOT we would probably need to expand to allow for more that one ROOT if it has to be defined in the parent /etc/make.conf -- Ned Ludd so...@gentoo.org Gentoo Linux
Re: [gentoo-portage-dev] prefix portage chaining
On Wed, 2009-03-25 at 14:14 +0100, Markus Duft wrote: On Wed, 2009-03-25 at 12:00 +0100, Fabian Groffen wrote: On 20-03-2009 11:35:09 +0100, Markus Duft wrote: i'll try and explain what i want in the first place: i'm porting things to native windows. since windows isn't too cooperative, i'm unable to merge most things (and with other things, i simply don't want to), and thus i need to take those things from somewhere else (more or less the complete @system). I _am_ able to build all those things for interix (which is the host system in the windows case). So what i want is a setup of two prefix instances with a certain relation to each other: the native windows prefix should be able to recognize installed packages from the other instance, and resolve dependencies by eventually using the other .../var/db/... Since Windows and Interix seem to be two different things to me, can you explain why in this case Portage can resolve the dependencies from the Interix system to use for the Windows system? What dependencies are we talking about? Build tools? Libraries? Runtime dependencies? i'm using it to resolve DEPEND atoms only. of course my notion of valid DEPENDs and RDEPENDs is influenced by this, and i'm alergic against RDEPEND=$DEPEND and such :) since it doesn't work in this setup. however right now most things i need don't make too much problems. This could be (and is) quite usefull for all other platforms too. For exmaple i could use prefix chaining on a linux box. I could create a prefix containing a base system, and then for testing of i-don't-know-whatever, i could create another small prefix inheriting all installed packages from the other one. this way new prefixes can stay very slim, but still the parent prefix is not altered on merges. That potentially is useful, in the case where you want to upgrade a critical system package and test it out or something. Can't think of an example other than Portage itself for the moment, though. (And that one can be hairy, for instance if the vdb format changes NEEDED - NEEDED.ELF.2) ++ :) one issue not handled by the current patch is, that prefixes can have different CHOST/ARCH/... (which is the case with x86-interix and x86-winnt for example). Then how does it work for you? as i said, i'm using DEPENDs only from the other prefix with the different CHOST/ARCH. this works, since on interix i can execute windows binaries, and vice versa (limited). the patch i proposed here and on gentoo-alt@ (btw. i have a fixed version lying around since a few minutes ...) allows the user to set which atoms should be resolve-able from the chain. for exmaple for windows i'm doing this in /my/winnt/prefix/etc/make.conf: READONLY_EROOT=/my/interix/prefix:DEPEND on linux, if both prefixes are x86-linux for example i could to in /my/prefix/two/etc/make.conf: READONLY_EROOT=/my/prefix/one:DEPEND,RDEPEND (btw. this forces PDEPENDs to merge in /my/prefix/two. i guess most of the time this makes sense, since with a PDEPEND from a lib, i want the PDEPEND package to link against this lib... you know what i mean? of course PDEPEND can still be added to the above list...) (btw2. the name READONLY_EROOT is discussed on gentoo-alt@ already, so i won't comment on it beeing cool/uncool here... ;) ) Cheers, Markus \ While much of what you are talking about here mainly applies to prefix, it looks to me from glancing over the code that you might of solved a long standing problem in the embedded world with cross compiling via portage. 222895 If that is the case, then I owe you a beer. one about the size of a keg. -- Ned Ludd so...@gentoo.org Gentoo Linux
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Mon, 2009-03-16 at 19:45 -0400, Mike Frysinger wrote:
On Monday 16 March 2009 18:49:04 Ned Ludd wrote:
On Mon, 2009-03-16 at 17:05 -0400, Mike Frysinger wrote:
On Monday 16 March 2009 14:35:15 Ned Ludd wrote:
On Mon, 2009-03-16 at 18:34 +0200, Amit Dor-Shifer wrote:
Hi all.
While working on my overlay, I stumbled on an issue where qfile
refused to acknowledge an installed file as being part of my package.
Looking into q's implementation (portage-utils-0.1.29), I see:
amit0 portage-utils-0.1.29 # grep -A 2 next_entry
./libq/vdb_get_next_dir.c next_entry:
ret = readdir(dir);
if (ret == NULL) {
--
goto next_entry;
if (strchr(ret-d_name, '-') == NULL)
if ((strcmp(ret-d_name, virtual)) != 0)
goto next_entry;
I encountered this since I used a new category, which only contained
a single word. Adding a hyphen and a 2nd token solved my issue, and
now qfile knows the file's association.
Is this assumption, that category should be stringA-stringB
documented somewhere?
We made that assumption for portage-utils as they can be used on a
device which has no $PORTDIR at all. So when there is no categories
file that exists we fell back to the rules that have been working well
for the past %d years.
We changed that behavior however a while ago. I thought this was in the
tree. But I guess not if you are hitting it.
http://sources.gentoo.org/viewcvs.py/gentoo-projects/portage-utils/libq
/vdb _get_next_dir.c?r1=1.2r2=1.3
we should do a new release already
Why yes.. Yes you should :)
if you dont do it before me, i'll probably try and do it this weekend.
I'd prefer it if you could do it this time. (thanks in advance)
btw, i
went through the bug reports and saw qcache crashes ... are those still
relevant ?
-mike
Yeah. tcort was the guy who wrote most of that. He's retired now.
I never really looked into it much but I think there are some NULL
values he did not check for in the metacache.
There is also a bug with atom parsing iirc on 32bit platforms. gradm was
the test case. Think we need to change from int to long.. Maybe another
with -rX parsing.
--
Ned Ludd so...@gentoo.org
Gentoo Linux
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Tue, 2009-03-17 at 13:27 -0400, Mike Frysinger wrote: On Tuesday 17 March 2009 12:59:58 Ned Ludd wrote: There is also a bug with atom parsing iirc on 32bit platforms. gradm was the test case. Think we need to change from int to long. the code is documented as having 64bit limitations for any specific component. the last release doesnt have the updated work i did in qatom to handle the latest atom spec though, and that includes moving from 32bit to 64bit for components ... Sounds good. Maybe another with -rX parsing. if you're thinking of the open bug, that's an eprefix specific extension. they turned the X in -rX into a floating point #. which isnt supported currently. -mike I don't think that was it. But I can't recall well enough off the top of my head the problem that somebody pointed out to me one day on irc while I was probably too busy. -- Ned Ludd so...@gentoo.org Gentoo Linux
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Mon, 2009-03-16 at 18:34 +0200, Amit Dor-Shifer wrote:
Hi all.
While working on my overlay, I stumbled on an issue where qfile refused
to acknowledge an installed file as being part of my package.
Looking into q's implementation (portage-utils-0.1.29), I see:
amit0 portage-utils-0.1.29 # grep -A 2 next_entry ./libq/vdb_get_next_dir.c
next_entry:
ret = readdir(dir);
if (ret == NULL) {
--
goto next_entry;
if (strchr(ret-d_name, '-') == NULL)
if ((strcmp(ret-d_name, virtual)) != 0)
goto next_entry;
I encountered this since I used a new category, which only contained a
single word. Adding a hyphen and a 2nd token solved my issue, and now
qfile knows the file's association.
Is this assumption, that category should be stringA-stringB documented
somewhere?
We made that assumption for portage-utils as they can be used on a
device which has no $PORTDIR at all. So when there is no categories file
that exists we fell back to the rules that have been working well for
the past %d years.
We changed that behavior however a while ago. I thought this was in the
tree. But I guess not if you are hitting it.
http://sources.gentoo.org/viewcvs.py/gentoo-projects/portage-utils/libq/vdb_get_next_dir.c?r1=1.2r2=1.3
--
Ned Ludd so...@gentoo.org
Gentoo Linux
Re: [gentoo-portage-dev] qfile assumes category names contain a hyphen
On Mon, 2009-03-16 at 17:05 -0400, Mike Frysinger wrote:
On Monday 16 March 2009 14:35:15 Ned Ludd wrote:
On Mon, 2009-03-16 at 18:34 +0200, Amit Dor-Shifer wrote:
Hi all.
While working on my overlay, I stumbled on an issue where qfile refused
to acknowledge an installed file as being part of my package.
Looking into q's implementation (portage-utils-0.1.29), I see:
amit0 portage-utils-0.1.29 # grep -A 2 next_entry
./libq/vdb_get_next_dir.c next_entry:
ret = readdir(dir);
if (ret == NULL) {
--
goto next_entry;
if (strchr(ret-d_name, '-') == NULL)
if ((strcmp(ret-d_name, virtual)) != 0)
goto next_entry;
I encountered this since I used a new category, which only contained a
single word. Adding a hyphen and a 2nd token solved my issue, and now
qfile knows the file's association.
Is this assumption, that category should be stringA-stringB documented
somewhere?
We made that assumption for portage-utils as they can be used on a
device which has no $PORTDIR at all. So when there is no categories file
that exists we fell back to the rules that have been working well for
the past %d years.
We changed that behavior however a while ago. I thought this was in the
tree. But I guess not if you are hitting it.
http://sources.gentoo.org/viewcvs.py/gentoo-projects/portage-utils/libq/vdb
_get_next_dir.c?r1=1.2r2=1.3
we should do a new release already
-mike
Why yes.. Yes you should :)
--
Ned Ludd so...@gentoo.org
Gentoo Linux
Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds
On Thu, 2009-02-05 at 00:37 +, Angelo Arrifano wrote:
On Qua, 2009-02-04 at 18:36 +0200, Petteri Räty wrote:
Some packages are not automake driven. We have to detect those.
make DESTDIR=${D} PREFIX=/usr \
STRIP=true ENABLE_NLS=${USE_NLS} \
$@ install
fi
Should use emake. Stripping should be left to the package manager.
STRIP=true replaces STRIP=strip while also returning a non error status.
This is done in order to ensure that portage handles the stripping using
the correct cross-strip. We also have to sed a bunch of templates out
that use install -s etc which always calls the wrong strip.
But STRIP=true is proper as in /bin/true without the path.
Side note I've already talked with upstream and future versions will
probably drop any default stripping or move towards better unification.
Thanks.
Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds
On Tue, 2009-02-03 at 17:10 +, Angelo Arrifano wrote: On Ter, 2009-02-03 at 11:28 -0500, Richard Freeman wrote: Angelo Arrifano wrote: We at -embedded would like to introduce GPE - The G Palmtop Environment. The GPE Palmtop Environment provides a user interface environment for palmtop/handheld computers running the GNU/Linux or any other UNIX-like operating system. Sounds neat? How long until I'm running gentoo on my android? :) Right away: http://tinderbox.dev.gentoo.org/embedded/linwizard/overlay/ Take the gpe-base/gpe meta ebuild which should pull all the stuff. Happy xcompiling, Assuming you have the G2 you could skip all that and simply merge from these .tbz2 into a $ROOT http://tinderbox.dev.gentoo.org/embedded/armv6j-softfloat-linux-gnueabi -- Ned Ludd so...@gentoo.org Gentoo Linux
Re: [gentoo-portage-dev] About boosting sync
On Tue, 2008-12-02 at 19:46 +0200, Tambet wrote: Has anyone ever noticed that portage tree contains a lot of md5 hashes, which are not at all important for using it? I think that it does not make reliability or functionality smaller any bit if those would all stay in sync servers - anyway, syncing would go much faster and this tree smaller. What about removing all those md5 hashes and downloading them only when they're needed? To build a deptree portage needs to source the ebuild in the depend phase, so portage needs to know that a file is safe to source before it loads it. Being that FEATURES='strict' is enabled per default in all profiles. It's rather vital that things remain the way they are now. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux
Re: [gentoo-portage-dev] Time to say goodbye
On Sun, 2008-11-30 at 16:19 +0100, Marius Mauch wrote: So, time has come for me to realize that my time with Gentoo is over. I haven't actually been doing much Gentoo work over the last months due to personal reasons (nothing Gentoo related), and I don't see that situation changing in the near future. In fact I've already reassigned or dropped most of my responsibilites in Gentoo a while ago, so there are just a few pet projects left to give away: - my gentoo-stats project (in the portage/gentoo-stats svn repository). I know quite a few people are interested in the idea of collecting various statistic data from gentoo user systems, and I'd encourage everyone who wants to implement such a system to at least look at it (I may have even finished it if I wouldn't have wasted my time focusing on the wrong problems). There is quite a bit of documentation also that should help to get you started - a graphical security update tool (see bug #190397) So if anyone wants to adopt those, complete or just parts, just take them. As for Portage, Zac has practically already filled my role. So I guess that wraps it up. It's been a nice ride most of the time, but now it's time for me to leave the Gentoo train. Marius I will always remember you as the guy who provided us with the much needed glsa*.py (thank you again) Take care and I wish you the best in all your future endeavors. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux
Re: [gentoo-portage-dev] About system and world
On Sun, 2007-10-21 at 15:12 +0200, Marius Mauch wrote: On Sun, 21 Oct 2007 05:23:45 -0700 Ned Ludd [EMAIL PROTECTED] wrote: On Sun, 2007-10-21 at 13:01 +0200, Marius Mauch wrote: So, what do people think about removing (some) of the special treatment for the system and world targets? Mainly I'm interested in removing the selective parameter that's currently enabled for them (so for example without that parameter `emerge world` would default to remerging packages, unless --update or --noreplace are specified). That change has already been requested a few times in the past by users, but OTOH it could probably upset people who don't use --update with world/system. What would such a disruptive change really gain us? The goal is to make package sets behave in a consistent way. I personally feel our users need consistency from Gentoo. If they grew up doing 'emerge world' and have come to expect that behavior and all of the sudden we change behavior on them.. Yeah I can see how ppl would get upset. As do I, which is why I haven't simply changed it. Perhaps a less intrusive way would be to introduce another flag to get the specified behavior you are after. Well, the primary goal is to make all sets behave in a consistent way. And some sets have the explicit purpose to rebuild stuff, so making sets selective by default also has issues. The proposed change would also make sets behave in the same way as packages which is IMO another benefit. But as I said, I can see that it could upset people. One possible solution that I've thought about would be to remove the hardcoded selective parameter and let the set configuration determine if a set is selective or not (with missing = false), and then enable it for world and system in our default config, e.g. [world] class = portage.sets.files.WorldSet selective = True and extend the --rebuild option with new arguments always and never. Don't really like the additional complexity though (and I haven't checked how much work it would be). To me this really sounds like it's -e world but just with the world file. Literally as if you were to do an emerge -p $(/var/lib/portage/world) Assuming that is what you intend for it to behave like then how about using -E for this behavior? Everybody would profit and nobody would become disgruntled when all of the sudden emerge started spiking the power bills. :) -- Ned Ludd [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Commitlog-mailinglist
On Tue, 2007-08-07 at 08:28 +0200, Lars Weiler wrote: * Petteri Räty [EMAIL PROTECTED] [07/08/06 19:20 +0300]: Well perhaps we should just look at the overall usage of the mail box instead of how it's used. I think there is already some limit in our policy for how big you can keep your mailbox. Last night some of us infra-folk had a chat in #gentoo-infra about this commitlog-mailinglist. solar stated that the ammount of messages in the dev-mailboxes was the reason to shut down that list some years ago No no. perhaps I was not clear enough. Sorry if that was the case. I was alluding to more of it being a resource pig.. Which it is of course. We also discussed some possible solutions to make this not a resource pig. I'm in favor of the 14-60 day archives and treat it much in the same way we do for ~'/.maildir/.spam/ folders where we simply flush old mails. I'll get a chance to meet up with taco and robbin tmw.. I do hope to poke them to see where they stand on what they see as an ideal solution.. Note that the primary dev mail checking server is already sitting at ~2.00 loads. (I have to fetch my archives to prove that -- AFAIR we only had troubles with the script, as CVS moved away from our dev-box with local mail-delivery to a dedicated server). We thought about distributing the mails via a public IMAP-box or via NNTP only. But if that list is not too urgent, it might be the best idea to produce an RSS-feed out of the commitlogs. Somebody noted that we should include commits to other areas as well and not those to the gentoo-x86 repository only. So, if you can wait, I can search my minimalistic Perl-skillz and write a script for creating the RSS-feed. On the other hand we can just switch on the mailing-list and see how it develops… Regards, Lars -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Commitlog-mailinglist
On Mon, 2007-08-06 at 16:43 +0200, Lars Weiler wrote: * Mike Frysinger [EMAIL PROTECTED] [07/08/06 08:23 -0400]: doit (and update lists.xml in the process) I can't. The list seems to be closed or limited to a special address. Furthermore it seems that our listmaster is either MIA or at LWE. One thing to note.. If we do make mailing list for this. It should not be archived in any such way. devs that subscribe to the mailing list better not be storing mail in imap on infra resources. We simply don't have that kinda spare space to mirror all cvs commits 2-300 times. -- Ned Ludd [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] have any developers subscribed to -project?
On Fri, 2007-07-20 at 20:58 +0100, George Prowse wrote: Do any devs subscribe to -project because no replies have yet to be heard from developers... Please stop flooding my inbox. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] So...
On Mon, 2007-07-16 at 15:06 -0400, Doug Goldstein wrote: So it's 97 degrees outside.. it's pretty hot... Since everyone loves to debate non-technical things on this list.. Let's debate Fahrenheit vs Celcius... Discuss! Well from my POV you have about 13 assholes 14 including me that felt the need need to comment on this stupid ass thread. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: For Jakub (and the other procmail-impaired)
On Tue, 2007-07-17 at 01:30 +0100, Steve Long wrote: Chris Gianelloni wrote: :0 * ^List-Id:.gentoo-dev.gentoo.org. * ^Subject:.*ML changes /dev/null Sorry was there some reason the rest of us had to read this? If so, please explain it like a responsible Council member. Or is this your swansong? If so it's l4m3. Is there some reason you feel fscking compelled to respond to every single mail on this list. You know it's guys like mostly just you that are driving us away.. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-nfp] Nominations open for the 2007/08 Trustees
On Tue, 2007-07-17 at 10:08 -0500, Grant Goodyear wrote: Ned Ludd wrote: [Mon Jul 16 2007, 04:00:44PM CDT] Long term I worry about the foundation. No offense to anybody. I'm sure I don't know or understand the problems you/we have encountered along the way. But I think we need to face it 99.9% of our devs are not suited to run a foundation such as this. That's not a bad thing in any such way. Most of us came to this project cuz we are geeks doing geeky things is what we do best.. I'm sure some of you get roped into doing the foundation because you truly love Gentoo and want to see things be taken care of. However to be frank. I don't think I've seen a single substantial thing accomplished sense cshields left Gentoo. Please don't take that the wrong way. I know we are all busy people. Perhaps you guys have done shitloads and I/we just don't know about it. Perhaps it's still the same old story.. We are waiting on ABC banks. We can't re-incorp without XYZ first. Actually, we have a bank, paypal successfully talks to it, Thats good to hear about paypal/banking. And it's good to know that you guys are still there looking out for Gentoo. and I believe that we're completely caught up w/ all of the various funding requests that we've received. You're point is still a good one, however. Anyway point I'm trying to make here is that I think we might be better off using a 3rd party as our foundation. IE people who have the experience/motivation and time to focus on such things that a foundation should be. Anyway. I'd like to nominate nobody in-house. Yeah, I tend to agree. Not-so-coincidentally, Gentoo's been invited to join the Software Freedom Conservancy, which would provide just the sort of 3rd-party management that you're suggesting. I put a write-up on my blog detailing what we know so far: http://www.grantgoodyear.org/g2blog/gentoo/20070717-sflc.html I'm cross-posting to -dev, and suggesting that comments be sent there as well, since most people don't read -nfp. If you think this is a good idea, a bad idea, or you just want to know more, now's the time to express your opinion. -g2boojum- We're happy to discuss methods that have worked for other projects with you to help you select the solution that is right for you. I defiantly think this makes the most sense for Gentoo at this time. One area that seems a tad fuzzy in details is how Gentoo would handle dealing with Paragraph 6 - Representation of the Project in the Conservancy. If we went to FSC route. Should we bother in even having a foundation? If so what role shall it play other than to be the liaison between internal funding requests? I think clearly it would not be the best of ideas to allow all our devs unilateral spending abilities. Would you mind inquiring about the methods that have worked for other projects ? We are a 501(c)6 right now if I remember correctly and that has been a limiting factor in us receiving donations in this past. By teaming up with them we gain the 501(c)3 status. That seems like a good thing in and of itself as it allows our sponsors to write off donations to the project. Which in turn could lead to a lot more donations, which then turns into Gentoo being able to offer bigger and better things at the end of the day. Thanks for taking the time to work with them, and informing us that the foundation is still active (it's somewhat hard to tell sometimes). -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
[gentoo-dev] About to retire
Well it's clear that nearly everybody is a fucking tard on this list. So before I depart. Here is a list of shit that's going to need to be maintained or dropped from the tree. Do what you will I could give two shits less. dev-embedded/gpio dev-util/elfkickers net-firewall/arptables net-firewall/ebtables net-misc/netkit-telnetd net-misc/vconfig net-proxy/middleman (dead upstream) net-wireless/chillispot sys-devel/sparse -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
On Thu, 2007-07-12 at 13:24 -0700, Mike Doty wrote: All- We're going to change the -dev mailing list from completely open to where only devs can post, but any dev could moderate a non-dev post. devs who moderate in bad posts will be subject to moderation themselves. in addition the gentoo-project list will be created to take over what -dev frequently becomes. there is no requirement to be on this new list. We're voting on this next council meeting so if you have input, now would be the time. This is an absolutely wonderful idea and I can't wait till we implement it. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
On Thu, 2007-07-12 at 13:24 -0700, Mike Doty wrote: All- We're going to change the -dev mailing list from completely open to where only devs can post, but any dev could moderate a non-dev post. devs who moderate in bad posts will be subject to moderation themselves. in addition the gentoo-project list will be created to take over what -dev frequently becomes. there is no requirement to be on this new list. This will probably remove the need for -core(everything gets leaked out anyway) but that's a path to cross later. We're voting on this next council meeting so if you have input, now would be the time. --taco A lot of people seem to be confused about this mail of yours. Namely mainly how it does or does not relate to the core mailing list. Perhaps you could clarify the idea a little bit for those who seem confused. Thanks in advance. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
On Fri, 2007-07-13 at 02:17 +0200, Robert Buchholz wrote: I have to second the voices that a lot of user mails are productive. I did not do any stats, but I feel that most mails to -dev are currently by Gentoo devs anyway, so it will not seriously reduce the amount of mail in total. FYI we do have stats.. http://archives.gentoo.org/stats/gentoo-dev-per-month.xml http://archives.gentoo.org/stats/gentoo-dev-per-year.xml http://archives.gentoo.org/stats/ -- Ned Ludd [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New Linux-PAM stabling plans
Forwarded by request of somebody thats smart/lucky enough to not be on this list but still monitoring it. Forwarded Message From: Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] Subject: New Linux-PAM stabling plans Date: Wed, 4 Jul 2007 20:51:36 +0200 Hi everybody; sorry to mail here rather than -dev, but I'm not subscribed to it and I have no intention to subscribe in the next future. Please forward a copy of this message to gentoo-dev if you can and want, thanks. Since while I was gone nobody took care of PAM, I had to resume work on it (sigh), and almost at the same time I got reported that PAM 0.78 doesn't allow to set some limits in limits.conf to unlimited value. This is a good enough reason to work actively on marking 0.99 stable. Unfortunately, 0.99 upgrade isn't entirely trivial, as pam_stack.so is gone, pam_userdb is moved and so is pam_console, plus a few more modules are no more present at all. To solve this issue, I just wrote an upgrade guide in the PAM project that will appear soon at [1]. That guide should contain all the information needed to pass through the upgrade easily. I also have an ebuild ready to commit that will make a lot of warnings and various noise when the pam.d file in the system still refers to the removed packages, pointing to the upgrade guide. It also dies if the user still has pam_stack or other modules that are not moved but really not available. (I'm still not sure where I should die: pkg_setup would stop users from building pkgs, pkg_preinst would waste people time if they didn't notice the warnings at setup stage, as right now the warnings are printed in both, and preinst dies). I'd really like comments on the guide (that still has to pass through an editor -- Josh would you mind? :) -- so please skip grammar check for now ;) ), so that I can address whatever is needed. Now, I could ask stabilization even right now, but, I'm not sure how to convey enough focus on what is going to happen. I'll write about this on Planet for sure, but then? Is GLEP42 ready? Should I ask PR people to publish this? Anyway, I'll at least give it a week or two for more testing and for proofreading the guide; developers are invited to try the upgrade on their (non-production first) machines, and report immediately any problem with the procedure. Sorry for the delay to get a decent PAM working, thanks for waiting. [1] http://www.gentoo.org/proj/en/base/pam/upgrade-0.99.xml Diego Flameeyes Pettenò http://farragut.flameeyes.is-a-geek.org/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 23:04 -0400, Mike Frysinger wrote: On Wednesday 20 June 2007, Mike Frysinger wrote: On Wednesday 20 June 2007, Josh Saddler wrote: Do potential licensing/copyright issues like these factor into your proposal in any way? no, that's an exercise for the user and no one else ... there's no way i'd have the tools prevent this. about the only thing i'd add is a reminder message if binpkg is in IUSE and not in USE. i like this idea so it's been added: # quickpkg pycrypto * dev-python/pycrypto-2.0.1-r5: package was emerged with USE=-bindist! * dev-python/pycrypto-2.0.1-r5: it may not be legal to redistribute this. * Building package for dev-python/pycrypto-2.0.1-r5 ...[ ok ] * Packages now in '/usr/portage/packages': * dev-python/pycrypto-2.0.1-r5: 188K -mike Please do the same for qpkg.c tia. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 15:57 -0400, Mike Frysinger wrote:
On Wednesday 20 June 2007, Marius Mauch wrote:
Mike Frysinger [EMAIL PROTECTED] wrote:
mayhaps we need a new function to be run in src_install() to label
files as sensitive ... so baselayout would do:
esosensitive /etc/{fstab,group,passwd,shadow}
and then we expand the format of CONTENTS in the vdb:
priv /etc/fstab hash mtime
And what would be phase 2 of that? Just having a new filetype
in CONTENTS doesn't accomplish anything by itself ...
updating any tool that creates binary packages from the live $ROOT of course
silly billy
current behavior:
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
proposed new behavior (exact output here is not part of the discussion so
dont
nit pick it):
# quickpkg baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Skipping sensitive file: /etc/passwd
* Skipping sensitive file: /etc/shadow
* Skipping sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
# quickpkg --iamsensitive baselayout
* Building package for sys-apps/baselayout-1.12.10-r4
* Including sensitive file: /etc/passwd
* Including sensitive file: /etc/shadow
* Including sensitive file: /etc/group
* Packages now in '/usr/portage/pacakges':
* sys-apps/baselayout-1.12.10-r4: 307K
Suggestion:
If you go down this sensitive route. please ensure that the
generated.tbz2 is mode 600 to prevent exposing this sensitive
data more than need be.
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Bye Gentoo!
On Thu, 2007-05-31 at 03:35 +0200, Bryan Østergaard wrote: It's with a bit of sadness but also a bit of relief that I'm finally retiring from Gentoo. I've been a Gentoo developer for nearly 4 years now and I like to at least pretend that I've made some important contributions to Gentoo during that time. I've had a lot of fun but my frustrations have grown these past several months and I've been entertaining the idea about retiring from Gentoo for probably 6 months now. The past couple months the desire to leave Gentoo have become much stronger and I think it's finally time for me and Gentoo to go our separate ways. I think I've put my fingerprint on Gentoo in quite a few important ways but lately I've come to the realization that I probably can't do any more for Gentoo. No matter how hard I try fighting for what I feel is right we seem to end up with petty fights, flamewars or what I consider even worse - people simply ignore what I'm working hard towards. So I think it's high time that I leave the project and start looking for another project where I can contribute something important and not just try to keep afloat in a project that I seem to be at odds with to an ever increasing degree. I'll try to reach all the projects I'm leaving over the next few days and see if I can pass on my work in a reasonable manner. I probably won't be around much on irc but if you really need to contact me you can do so at [EMAIL PROTECTED] Good luck to all of you and may Gentoo development be as much fun for you as it used to be for me. Best regards, Bryan Østergaard I'm going to punch you in the ribs really hard if I ever meet you. I count on a few people in this project and you are one of them. I'm really disappointed you are rolling out on us without no for warning. I can understand your frustration and all but I expected and assumed you had big balls.. None the less. I wish you the best in your future endeavors. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Bye Gentoo!
On Thu, 2007-05-31 at 08:47 +0100, Ciaran McCreesh wrote: On Thu, 31 May 2007 00:05:13 -0700 Ned Ludd [EMAIL PROTECTED] wrote: I can understand your frustration and all but I expected and assumed you had big balls.. It takes more balls to go against the prevailing stagnation than to just sit by idly and remain content with the situation no matter how bad it is... perhaps sometimes yes.. None the less I dislike losing core people so quickly who helped out on the back-end to keep things flowing .. He will be missed for sure. -- Ned Ludd [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Bye2u Gentoo
On Thu, 2007-05-31 at 11:21 -0700, Ilya A. Volynets-Evenbakh wrote: Grmbl Can you do us a favor and provide us with a clone, for doing MIPS keywording? Looks like Kumba has been quite active doing it recently. Alexander Færøy wrote: Hey, It is my time to leave Gentoo as well. It has been some exciting months and I have learned a lot from many of you guys. It has been interesting to be in one of the major open source projects and I have learned a lot from it! I will move on with some new projects and see if I can become useful there. I will be around for the Bugday on Saturday and hopefully finish what we are missing in that project. Then I'll try to point out a new leader for that team. I am really going to miss a lot of you guys. Especially the ones I met during FOSDEM. Hope to see you there next year as well! Best regards, Alex -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Maintainers desired for a few simple pkgs.
I'm looking to get rid of a few ebuilds I half ass maintain. net-wireless/chillispot (Open source captive portal or wireless LAN access point controller) sys-devel/sparse (C semantic parser) Both are relativity low maintenance. Any takers? pretty please with party socks on top. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Planning for automatic assignment of bugs
On Thu, 2007-04-26 at 22:01 -0700, Robin H. Johnson wrote: On Fri, Apr 27, 2007 at 02:33:50AM +0200, Danny van Dyk wrote: Both 'assign' and 'cc' (and derivations thereof are not suitable). notification=assignment|cc|none ? This is to answer expose's question as well, but the attribute should only indicate if the maintainer entry should be used for any automatic process at all, not how to use it. One of the reasons is that multiple maintainers each with notification=assignment obviously won't work, and it's non-trivial to validate via the DTD (yes, DTDs suck compared to XSchema, I know). I intend that the first non-excluded maintainer entry is the one used for the automatic process. In terms of implementing this in the DTD, I'm going to specify that 'contact=1' (or whatever name we settle on) is the default, so that we don't break validation of any existing metadata: !ATTLIST maintainer contact (0|1) 1 -- should this maintainer be used by -- automatic processes? In light of the above, how about 'automatic=0'? Please keep with your original idea of letting maintainers opt out vs some of the ideas proposed in this thread where maintainers have to opt in as I'm sure the metadata.xml files wont be updated by enough people to really gain the benefit of what we are trying to do here if they have to do opt in. Thanks. -- Ned Ludd [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Please fix your metadata.xml ASAP
With the loss of our recent bug-wrangler infra will probably be moving to automated system of reassignment of bugs. In order for this to happen you need to properly have your maintainer and herd tags listed in the metadata.xml files. Things such as maintainer postgresql are not valid when you are using pgsql-bugs@ for bugzilla. In such cases put pgsql-bugs@ as the maintainer. The maintainer tag must be a valid bugzilla alias or user (domain not required). There are many more cases of this outside of the one listed package. I'll see if I can compile a list of the offenders sometime in the near future. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, 2007-04-20 at 08:22 -0400, Mike Frysinger wrote: does anyone actually find this useful ? yes quite useful. i think ive used the value in there like once (when in reality a `md5sum` would have worked just as well) ... otherwise, from my perspective: - it causes annoying bogus hunks in diffs That it does also if the diff is of course in the first few lines. - not uncommon for people to contact me as the maintainer because i'm in that - wastes space (well, probably not a strong argument due to bytes vs blocks) - for mostly green users, it's confusing and they get it wrong -mike -- Ned Ludd [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Deskzilla license for Gentoo Bugzilla for everyone
You sent this to -dev vs -core.. Pretty sure they are going to need to revoke this license now. On Fri, 2007-04-20 at 23:05 +0200, Bjarke Istrup Pedersen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey everyone :-) Infra told me to go ahead and email this around, so here it is. Here is a snippet of the email I got: Thanks for your request. Please find attached a site license for Gentoo Linux project. Feel free to share the license key with anyone interested or post it on the web. The license allows any number of users, and it is locked to Gentoo Linux Bugzilla URL. If in the future the URL changes, please let me know and I'll create another license key. Please note that this license key requires Deskzilla 1.3 or later. You can download the latest version from http://almworks.com/deskzilla/download.html . So there it is. For now you can get the ebuild from java-experimental . Best regards Bjarke Istrup Pedersen AKA GurliGebis -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKSstO+Ewtpi9rLERAq9AAJ9q1soT6/L9fzJlQ9e7PE2nnNrBSQCeK0gE TY3o9fnj09fsmbEZut3VZac= =gPXZ -END PGP SIGNATURE- -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-core] Re: [gentoo-dev] Deskzilla license for Gentoo Bugzilla for everyone
Yeah KingTaco pointed that out on IRC. Sorry for any confusion. On Fri, 2007-04-20 at 23:50 +0200, Bjarke Istrup Pedersen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 That was my intention, since it's public for everyone. - From the email I got it looks like they want me to share it, and spread the word ;-) Bjarke Ned Ludd wrote: You sent this to -dev vs -core.. Pretty sure they are going to need to revoke this license now. On Fri, 2007-04-20 at 23:05 +0200, Bjarke Istrup Pedersen wrote: Hey everyone :-) Infra told me to go ahead and email this around, so here it is. Here is a snippet of the email I got: Thanks for your request. Please find attached a site license for Gentoo Linux project. Feel free to share the license key with anyone interested or post it on the web. The license allows any number of users, and it is locked to Gentoo Linux Bugzilla URL. If in the future the URL changes, please let me know and I'll create another license key. Please note that this license key requires Deskzilla 1.3 or later. You can download the latest version from http://almworks.com/deskzilla/download.html . So there it is. For now you can get the ebuild from java-experimental . Best regards Bjarke Istrup Pedersen AKA GurliGebis -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGKTWNO+Ewtpi9rLERAi12AJoC7LspOu85L+GvYedd7KrhyaQwHwCdE9wY 8VkTaN9fe1jMMG5TRRpOKXU= =AQbG -END PGP SIGNATURE- -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Removing retired developers from project pages
On Tue, 2007-04-17 at 16:10 +0300, Petteri Räty wrote: I made a patch to remove all retired developers from the project pages. If anyone doesn't object I will commit this next week. Feel free to commit any hardened or embedded corrections you have anytime you become aware of them. Thanks. -- Gentoo Linux Ned Ludd [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals
On Tue, 2007-04-10 at 23:34 +0300, Petteri Räty wrote: As the recent thread showed there is a lot going on in Gentoo land although it doesn't always seem so. I propose we extend project xml to describe current stuff going on in the project in question and their estimated completion date. Then we require this file to be updated monthly. What do you think? I'd rather not put this stipulation into place. Unless you are proposing that planet.gentoo.org die. Which I don't think you are doing.. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] base packages up for grabs
On Mon, 2007-04-09 at 13:36 -0700, Donnie Berkholz wrote: Mike Frysinger wrote: three of those should be a cake walk ... mkinitrd is a friggin mess though, so after you check the open bugs on it, i dont feel bad if you change your mind on it Maybe I will take it over, then decide it's obsolete and send out a removal notice. =) Please keep it around. embedded users used to find it a handy pkg. initramfs seems to be be winning users over however these days. It (mkinitrd) only ever had 12 bugs ever, 2 of which are currently open and one of those has an attached patch. In reality it should be fairly trivial to maintain. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] *DEVELOPMENT* mail list, right?
On Thu, 2007-04-05 at 19:03 -0400, Michael Cummings wrote: When you pop into your mail client of choice and find 50+ unread messages in the last few hours, you know what kind of day [EMAIL PROTECTED] is having. Don't suppose we could get on with that silly topical thing of development? Surely there's a usenet channel where you can discuss conspiracy.gentoo at length? Or at least take it to the user list? /me stretches and blinks So, fellow devs, what's new with development? For those interested, genlop has migrated into gentoo as a project with the permission of upstream, which no longer maintain it. Um...any new tools or projects people are working on? Anyone? Oh yeah development. Forgot that's what we do.. Here is what I'm doing these days.. Yesterday I pushed a new portage-utils that includes lots of enhancements to the qgrep util (Thanks TGL). With the help of others we are continuing our support of binary packages for lots of profiles (!releng stuff) which can be used for rescue in a pinch or fresh rapid installs as it's nice being able to setup a fully working current desktop in ~45 mins. http://tinderbox.dev.gentoo.org/portage/local/misc/updates.php In due time I'd like to take each of the major profiles and setup 3 build environments for them. One for strictly server (-X -alsa) then another for (+gnome stuff) and another for (+kde stuff) I'm looking for help from c coders to improve the portage-utils(qmerge) applet and package/profile requests from people who would be interested in rapid install methods. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote: On Sunday 01 April 2007, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. another one i had mentioned earlier: - a time frame on moving gentoo-core to public archives ... two years ? I object and hope this is never done. There are things said on core that I do not wish to be public. I've sent mails myself that if they were ever going to be published publicly I would of never sent them. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] get pci info in Linux?
On Thu, 2007-03-29 at 19:55 +0300, Bilanchuk Vitaly wrote: Use the library provided by the lspci package, that is what it is there for. Ok, thanks for you time. What's wrong with using these interfaces? You can use sysfs and proc from a C/C++ program just fine... sysfs and proc can be unexisting. Chances are you will need to directly communicate with the kernel via a module if proc and sys are not mounted. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 09:56 +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 01:19:45 +0530 Anant Narayanan [EMAIL PROTECTED] wrote: On 28-Mar-07, at 1:45 AM, Ciaran McCreesh wrote: Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? I certainly don't think so. A lot of people *switch* to Gentoo because of portage. Portage is a core part of our distro, and I don't see it being replaced for a long time to come. Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Can you please stop taking cheap pot shots every chance you get. We all get it. You are not a fan of portage. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 20:06 +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 11:57:36 -0700 Ned Ludd [EMAIL PROTECTED] wrote: Portage or the tree? Portage is just a way of using the tree, and it's not a very good one... Can you please stop taking cheap pot shots every chance you get. We all get it. You are not a fan of portage. And that attitude is exactly why Gentoo is no better off than it was two years ago. You are being dismissive of the hard work others are doing. I find that downright offensive. You want to write a kickass package manager then by all means do it. But trying to make yourself look good by making others look bad is an underhanded trick. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 21:02 +0100, Ciaran McCreesh wrote: On Thu, 29 Mar 2007 12:25:00 -0700 Ned Ludd [EMAIL PROTECTED] wrote: You are being dismissive of the hard work others are doing. I find that downright offensive. You want to write a kickass package manager then by all means do it. But trying to make yourself look good by making others look bad is an underhanded trick. This has nothing to do with the people. It's about the code. Not being able to make changes to a huge mess of spaghetti code doesn't imply any lack of talent in those who try... Please stop looking for excuses for interpreting something as offensive... The correct reply should of been. I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 14:03 -0700, Ilya A. Volynets-Evenbakh wrote: Ned Ludd wrote: The correct reply should of been. I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots Man, stop playing the silly Ooh, we are all so fragile and offendable game. Worry about yourself please. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo infra backups (was: Re: [gentoo-dev] Proposed addition to the Social Contract)
On Mon, 2007-03-26 at 19:44 -0400, Mike Frysinger wrote: On Monday 26 March 2007, bret curtis wrote: Only wimps use tape backup: *real **men* just upload their important stuff on *ftp*, and let the rest of the world mirror it. -- LT :1996 actually, i wonder if this would be useful ... we set up a master backup server where we post raw svn/cvs/etc... stuff and then allow people to setup mirrors of it ... Mike, We can't do a full raw mirror. There are restricted things in CVS. A raw copy of the anonymous cvs is about as close as we could do to this. I personally see little to no benefit in the additional overhead in doing that. But if you can make a case to say robbat2 and pylon for why this would be useful to our community then I'm sure we could open up a rsync of the raw anoncvs mirror. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposed addition to the Social Contract
On Mon, 2007-03-26 at 10:28 -0500, Dale wrote: Chris Gianelloni wrote: On Sun, 2007-03-25 at 22:46 +0100, Christel Dahlskjaer wrote: And how exactly does this help us in the event of say the OSL burning down or the GNi suffering flooding? :) Well, we're on the second floor of the data center which has a quite large basement, which would likely absorb most of the water. About the only feasible way for our stuff to get flooded is if the San Andreas finally gets the big one and the west coast of the US falls into the Pacific, in which case, we'll be worried about other issues, I'm sure. 3rd floor in C.06 actually. That being said, you're more than welcome to assist Infrastructure (and the Foundation) in finding new hosting locations as well as the manpower to bring new services up in those locations or moving existing services. Doing moves like this is a bunch of work, and not something I feel we should be dumping on the Infrastructure team. Can I assume this building has indoor plumbing? It can be on the top floor and still get flooded. I saw a house once that the hot water heater busted and water was about a foot deep and was coming out the walls. More than one way to flood a building. :/ Flooding/burning etc are not likely to happen. See page two of the spec for more details. http://www.365main.com/images/365_Main_San_Francisco_CA.pdf -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposed addition to the Social Contract
On Tue, 2007-03-27 at 00:22 +0200, Paul de Vrieze wrote: On Monday 26 March 2007, Dale wrote: Chris Gianelloni wrote: On Sun, 2007-03-25 at 22:46 +0100, Christel Dahlskjaer wrote: And how exactly does this help us in the event of say the OSL burning down or the GNi suffering flooding? :) Well, we're on the second floor of the data center which has a quite large basement, which would likely absorb most of the water. About the only feasible way for our stuff to get flooded is if the San Andreas finally gets the big one and the west coast of the US falls into the Pacific, in which case, we'll be worried about other issues, I'm sure. That being said, you're more than welcome to assist Infrastructure (and the Foundation) in finding new hosting locations as well as the manpower to bring new services up in those locations or moving existing services. Doing moves like this is a bunch of work, and not something I feel we should be dumping on the Infrastructure team. Can I assume this building has indoor plumbing? It can be on the top floor and still get flooded. I saw a house once that the hot water heater busted and water was about a foot deep and was coming out the walls. More than one way to flood a building. :/ Actually the situation is not that hypothetical. Some years ago the datacenter of the University of Twente (The Netherlands) was set to fire by an angry systems administrator. The building housed among other infrastructure vital to the university also some machines of great importance to the debian project. Due to a combined effort of suppliers, the university staff and the fact that they had a new datacenter that happened to be about to open, most things were up an running again in a few days. The thing I'm worried about most is insurrance. I trust that infra has backups of the important things like our repositories. The hosting Gentoo gets from GNi is a world class service in some of the best data centers in the world. Everything important gets backed up nightly from one data center to another. As GNi/365 Main move into more data centers world wide chances are Gentoo will be moving into those additionally as well. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
On Mon, 2007-03-12 at 19:15 -0400, Mike Frysinger wrote: On Monday 12 March 2007, Mike Frysinger wrote: instead, since we require bash for our ebuilds, use the builtin `type -p` err i botched that ;) `type -p` is almost a complete drop in replacement for which ... it does not work on bash builtins however, so people should use `type -P` to force the PATH search in other words, `type -p echo` would return while `type -P echo` would return /bin/echo -mike Here are the remaining offenders for sync 1174037821 that match '$(which ' or '`which ' in eclasses and ebuilds. eclass/mysql.eclass:529: eclass/mysql.eclass:530: app-dicts/stardict/stardict-2.4.8.ebuild:42: sci-mathematics/octave/octave-2.1.57-r1.ebuild:34: sci-mathematics/octave/octave-2.1.69.ebuild:36: www-apps/lxr/lxr-0.3.1.ebuild:37: app-cdr/cdrkit/cdrkit-1.0.ebuild:26: app-cdr/cdrkit/cdrkit-1.0_pre5.ebuild:30: app-cdr/cdrkit/cdrkit-1.1.0.ebuild:28: app-cdr/cdrkit/cdrkit-1.1.1.ebuild:28: app-cdr/cdrkit/cdrkit-1.1.2.ebuild:28: app-dicts/verbiste/verbiste-0.1.16.ebuild:28: app-text/pdftk/pdftk-1.12.ebuild:20: dev-db/hsqldb/hsqldb-1.7.3.1-r1.ebuild:48: dev-util/kdesvn/kdesvn-0.11.1.ebuild:34: dev-util/kdesvn/kdesvn-0.11.1.ebuild:35: media-libs/pdflib/pdflib-5.0.4_p1-r1.ebuild:39: media-libs/pdflib/pdflib-6.0.3-r1.ebuild:48: media-libs/pdflib/pdflib-6.0.3.ebuild:38: sys-process/fcron/fcron-2.0.2.ebuild:28: sys-process/fcron/fcron-2.9.5.1.ebuild:31: sys-process/fcron/fcron-2.9.7.ebuild:26: sys-process/fcron/fcron-3.0.0.ebuild:33: sys-process/fcron/fcron-3.0.1-r1.ebuild:33: sys-process/fcron/fcron-3.0.1.ebuild:33: -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] LC_ALL and friends in make.conf
On Thu, 2007-03-08 at 14:23 -0500, Mike Frysinger wrote: On Thursday 08 March 2007, Kevin F. Quinn wrote: As we all know, setting LC_ALL and friends can cause all sorts of trouble in package builds. However, many users really appreciate being able to set it so that errors from the compiler etc are in their own language. we've fixed our documents so users should be setting LANG, not LC_ALL It occurs to me that during emerge, only LC_MESSAGES is actually useful for the user, to help interpret build errors. LC_COLLATE and the others don't give the user any benefit in the emerge process. So how about if LANG or LC_* are set, portage would set LC_MESSAGES and clear the rest? Is there any real advantage to the user having LC_* set apart from LC_MESSAGES? to answer the question directly, i think you're correct in that only LC_MESSAGES is a benefit to the user and screwing with the localization variables as suggested seems pretty sane hwever, ;) while i see the direction you're looking to go and the burdens you're looking to relieve, i think this just puts us back to the state that i disagree with ... namely that we shouldnt be ignoring these sort of problems, we should be fixing them Seems a forced ignore would fix them. (problem solved! next bug..) -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-dev] more up to date minimal install cd
On Sat, 2007-03-03 at 02:50 -0500, Chris Gianelloni wrote: [snip] Remember, we switched from quarterly to bi-annual releases for a reason. FYI. This archived copy was from 2004 http://staff.osuosl.org/~cshields/gentoosurvey/#doc_chap8 We may wish to consider rerunning this survey annually to see where we stand. We simply didn't have the man power, CPU power, nor time to do vigorous enough testing in the much more shortened time frame. I'm going to be asking for Release Testers again once I return, and if last year's turn out was any indicator (50+ people volunteering, about 5 actually helping *at all*), the chances of a project such as nightly builds ever taking off is well beyond our means at this time. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Thu, 2007-02-08 at 13:23 -0700, Daniel Robbins wrote: I sort of missed this conversation, so apologies in advance if this has already been covered, but wanted to say that gentoo's initscripts are generally not suited for embedded systems. So making baselayout busybox-compatible doesn't seem to be worth the disruption and headaches it would cause. Please read over what's been talked about elsewhere in this thread. He is not trying to break existing functionality at all. Only extend it to be posix aware (additionally) It would be disruptive for gentoo developers who would need to be extra-careful in maintaining their initscripts to ensure busybox compatibility. Not to mention the potential disruption for users. There is no reason this has to be disruptive to the users who don't care about this functionality. If you are building an embedded system using busybox, then generally you will want a single /etc/init.d/rcS script that starts all the stuff you need. As somebody that's had to hand write many of those kinds of scripts. A single rcS is not very ideal. Our init scripts are in fact mostly usable by busybox. Granted there are a few special special cases, but then Roy is offering to update those for free. One of the larger problems really boils down to many packages provide default init.d scripts and these expect the existing baselayout only. That will be a bigger feat to deal with later on down the road. -Daniel On 2/8/07, Mike Frysinger [EMAIL PROTECTED] wrote: On Thursday 08 February 2007, Roy Marples wrote: Mike Frysinger [EMAIL PROTECTED] wrote: On Wednesday 07 February 2007, Roy Marples wrote: In the current code I'm running it's only the network stuff that uses arrays. If you're thinking about /sbin/functions.sh, well that can stay as bash as it's not used by baselayout anymore. some init.d scripts use arrays as well Do we know which ones? grep for it :p netmount for sure right now The actual scripts themselves can be re-worked if they need to be - this problem only when the arrays are used in config files. i guess my point was i think we really need to be consistent here ... either arrays are OK for init.d scripts or they're not OK did you get a chance to see how hard it would be to integrate the bash array code ? -mike -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Thu, 2007-02-08 at 14:49 -0700, Daniel Robbins wrote: On 2/8/07, Ned Ludd [EMAIL PROTECTED] wrote: As somebody that's had to hand write many of those kinds of scripts. A single rcS is not very ideal. Our init scripts are in fact mostly usable by busybox. Granted there are a few special special cases, but then Roy is offering to update those for free. One of the larger problems really boils down to many packages provide default init.d scripts and these expect the existing baselayout only. That will be a bigger feat to deal with later on down the road. Developers will then need to test their init.d scripts to ensure that they are compatible with busybox. This is asking a lot of work of people just so you can use Gentoo's initscripts for something they are not really ideal for. I don't think anybody can/would expect that. They don't test for hardened or uClibc now before stabilizing a pkg. What would be nice to see is if a maintainer is offered a posix compliant init.d script that they merge it or allow those to be merged for a pkg they maintain as long as it does not degrade functionality. Any time a script is updated a new rev of a package is required, and this does impact users and will cause packages to be rebuilt when a user does emerge -u. So I think this should be weighed against the potential benefits of baselayout + busybox. busybox is not Roys underlying goal as far as I understand. I think he simply mentioned it as an example of another group who wishes to unify efforts and have an interest in getting away from arrays where feasible. If you are targetting something smaller than 32MB, then maybe busybox is appropriate. But you are trying to go really small, then you probably don't want all the extra junk in our initscripts. And if you are _not_ trying to go really small, then put bash in your filesystem, not busybox, and the initscripts will work. If bash isn't fast enough from a boot time perspective, then the gentoo initscripts certainly aren't going to be fast enough either. In other words: busybox + single rcS file = fastest and simplest, smallest, best for very small filesystems, not as flexible bash + gentoo baselayout = most flexible, biggest, slower, best for feature-rich systems busybox + gentoo baselayout = ? It's been done in the past by end users. Before there were only about 4 changes needed to make it work. That all changed when bash arrays were introduced. I think that in 99 out of 100 cases, if you have room for baselayout, then you probably have room for bash too. And in 99 out of 100 cases, if you can deal with the load time of baselayout, then you can deal with the overhead that might be incurred from having bash. I'm just pointing out that it's not an obviously good combination. In the grand scheme of things, maybe it's not a great use of developer resources. Or, maybe I'm wrong and it is a great idea. His time and resources. His itch Personally I think that baselayout + busybox may be cool, but adding an aftermarket sunroof to your car can be cool too. But that doesn't mean it's worth the effort :) I don't think those who are not interested in this will be burden by any extra effort. Worst case is maybe getting a bug assigned to you which offers a posix replacement/update for the default init.d a pkg you maintain might provide. Really, it's hard for me to imagine many scenarios where you really need the flexibility of baselayout but can't squeeze in bash. And I have a pretty good imagination. baselayout is only about a half of a meg these days and probably getting smaller/faster with the addition of the multicall rc/runscript work he has been doing. Adding bash also requires ncurses which in turn mostly requires having a c++ aware compiler or using the nocxx,minimal flags. Even with those flags enabled I'm seeing 3M going to ncurses+bash. So I can for sure see the benefits. Also for a moment lets stop and think. Some XYZ update breaks ncurses/bash. Supporting this gives us a nice alternative way to still boot our boxes for rescue using ash or another shell which might not have such big deps. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
On Wed, 2007-02-07 at 13:16 +, Roy Marples wrote:
OK, so everyone wants to keep their conf.d/net in bash. Fine by me.
Welcome to baselayout-ng which will be a virtual and will not require
bash.
Good. Maybe now we can get rid of the pretty much non functional
baselayout-lite which basically only every provided an /etc/inittab and
made a few device nods.
Now that's out of the way, let's discuss configuration :)
We still need something that is array like for want of a better
phrase, so how about delimiting using ; like so
config_eth0=10.1.1.1 netmask 255.255.255.0; 10.1.1.2/24
The ; seems logical.
You could even use bash expansion here, provided that bash is your shell
config_eth0=10.1.1.{1..30}/8; 192.168.0.1 netmask 255.255.255.0
See, that's not too bad is it?
Nope.
Thanks
Roy
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 2007-02-06 at 19:42 -0500, Mike Frysinger wrote: On Tuesday 06 February 2007, Kevin F. Quinn wrote: You need to define what shell (or subset) you want to parse it. 'sh' itself varies from platform to platform. our standard has always (always is relative here; let's say current) been the bash superset of POSIX ... if a request comes up where someone wants to change code because it breaks in their shell but the code in question is POSIX compliant, the answer is simple: blow me if the request is reasonable like stop using some bashism in favor of the POSIX form and the change isnt invasive, then sure we'll generally make the change /me likes the direction Roy is heading with this. -mike -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: eclass proposal - savedconfig.eclass
On Fri, 2007-02-02 at 04:08 +, Duncan wrote: Thomas Rösner [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 01 Feb 2007 20:46:41 +0100: sys-kernel/*? Or perhaps genkernel? Being able to build kernel images just like any other package in Gentoo would be nice. But with make oldconfig, so the user gets asked about new options, and those get saved back to the savedconfig, right? No way.. Please see how we handle this in busybox.ebuild which is the best documented example of the savedconfig option in the tree. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Topic for Feb council meeting
On Mon, 2007-01-29 at 14:46 +, Roy Marples wrote: On Mon, 29 Jan 2007 13:39:05 +0100 Rob C [EMAIL PROTECTED] wrote: For what its worth, I think option #2 is the best. I think option #1 is out of the question and I think that #3 is flawed because the 8th spot developer's situation or commitment to the project may have changed since the last vote and in any case that developer would be free to partake in the running vote with #2. Cheers -Rob Then it should be offered to the 8th person, at which point either he/she will then refuse the nomination and it's offered to the 9th. Rinse and repeat. If we run out of nominees then we'll need another election. Agreed. #3 From my POV having a new election potentially over and over is a waste of time and resources. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: ecompress heads up
On Fri, 2007-01-26 at 19:56 -0600, Ryan Hill wrote: Mike Frysinger wrote: On Friday 26 January 2007 17:19, Mike Frysinger wrote: i purposefully choose to not go this route because i dont want to start adding handling for arbitrary compression types ... when such a list exists, we always get people who want use to add support for their $favorite-compression that said, i would entertain the notion of auto uncompressing just .bz2, .gz, .Z and telling everyone else to toss off ... What about .zip? Not apart of the base-system. *runs away* -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GIT vs? SVN (was: Re: Re: [RFC] Some sync control)
On Thu, 2007-01-25 at 23:37 +0100, Markus Ullmann wrote: So to avoid thread hijacking, starting a new one. What exactly is this thread you are starting about? Just letting us know you did some random testing? I did some tests today and took sunrise overlay as testing ground. It has roughly 2850 revisions. As a blog recommended, I fetched the raw repo first to do the initial conversion to git. Then all I did was a git-svn init file:///home/jokey/sunrise-svn git-svn fetch It took 5 minutes and 12 secs for me on a not-so fast box. Then I had a git repo that could do all the branching, file merging and stuff and it sends it back to repo nicely. Even a reversion of a commit worked perfectly. git log gave this output: commit a8c35b8efe130fca7e2c3bb0d589a2d251f381c3 Author: ndansmith [EMAIL PROTECTED] Date: Thu Jan 25 03:35:02 2007 + Removing old turl files in favor of surl git-svn-id: file:///home/jokey/test/[EMAIL PROTECTED] 12608f7e-a915-0410-b2f3-ce240db1b126 So judging from this, I'd say we could use advantages of both. Those who wish git can go for it (the git repo, as pointed out on this list, can initially be fetched via rsync or tarballs or whatever comes in handy) and those who dislike git can just go with svn and be happy with it. Jokey -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] allow people to disambiguate built_with_use in upgrade situations
On Tue, 2007-01-16 at 19:06 -0500, Mike Frysinger wrote: Diego is proposing a new flag to built_with_use to handle the corner case where you query a package that does not have the requested flag in IUSE built_with_use [--missing action] ... so in the case of version transitions, you can specify the action as either true, false, or die (only current option) seems like a cleaner solution than forcing what can be a rats nest of has_version checks -mike I'd agree. The built_with_use is a thorn in the side with the existing behavior. Adding --missing yes|no 0|1 would be nice. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-dev] deprecating /etc/make.profile
On Wed, 2007-01-10 at 16:30 +0200, Simon Stelling wrote: Hi all, As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of /etc/make.profile and the use of a PORTAGE_PROFILE variable instead. Reason for this change aside from consistency with all other portage settings is the annoyance of re-adjusting the /etc/make.profile link before and after testing a profile change in an overlay/development repo. PORTAGE_CONFIGROOT= kinda solves your problem. But I do admit it would be a lot easier dealing with a variable vs having to parse the symlink to figure out the profile. If this change does happen I'd suggest that we support make.profile symlinks as long as they exist unless the make.conf defines the variable. If variable exists it should override. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] deprecating /etc/make.profile
On Thu, 2007-01-11 at 17:37 +1300, Kent Fredric wrote: On 1/11/07, Marius Mauch [EMAIL PROTECTED] wrote: And I assume there is a non-trivial number of custom scripts out there using make.profile, but that's nothing we can do about. You could give them all a grace period for which have to comply with the new standard by then end of it, and have ( during that grace period ) an automatic symlink generation based on that make.conf flag. And just to make sure, I doubt it would be too difficult to have an application that analyises packages as they install to check whether they reference make.profile or not, and flag a QA warning if they do. And packages that don't switch to the standard by the end of the grace period I guess we'll see on a last rites bulletin ;) Or we/gentoo could just support it and stop breaking the end user. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: PORTAGE_BINHOST Madness
On Sun, 2007-01-07 at 05:16 +, Steve Long wrote: Alec Warner wrote: Talk to solar about binhost, I know he has a better implementation lying around; it's a matter of finalizing it ;) solar: where is it on your site? Tip: If you want me to respond to something that directed to me it's best to CC: me directly as it's easy to miss threads on high volume lists. I use the qmerge applet from portage-utils to grab the pkgs to the localhost then emerge -Kpv $pkg. So on a fresh install I do something like wget hardened-tarball.tbz2 unpack emerge portage-utils set binhost qmerge -f $(qlist -IC) emerge -C pam-login emerge -Ke system otherwise I just qmerge -f $pkg ; emerge -Kpv $pkg The qmerge applet requires the use of the genpkgindex util on the remote bin repo. I know pkgcore is going to start using this same format for it's remote bin repo stuff. I talked with Zac (zmedico) last week about portage supporting it also. I think he is keen on it but the tool will need love on solving the $PN conflicts. Between us 3 we will come up with a standard sooner or later. (probably later vs sooner) http://sources.gentoo.org/viewcvs.py/*checkout*/gentoolkit/trunk/src/genpkgindex/genpkgindex it generates output like the following. http://tinderbox.dev.gentoo.org/hardened/x86/Packages -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentle reminder about ChangeLog entries on profiles
On Mon, 2007-01-08 at 17:40 -0500, Chris Gianelloni wrote: On Mon, 2007-01-08 at 12:20 -0800, Robin H. Johnson wrote: On Mon, Jan 08, 2007 at 08:27:50AM -0500, Chris Gianelloni wrote: Most of the profiles under default-linux have a ChangeLog at the architecture level. If you make *any* changes to a profile, you should be putting your changes in the ChangeLog. Just wondering, any objections if we add ChangeLogs at the rest of the levels in profiles? Would esp. be useful for some of the more global changes. Not really. Personally, I'd prefer there not be ChangeLogs any deeper on default-linux than $arch, so adding one to, say, default-linux would be good, adding one to default-linux/x86/2006.1 would be rather pointless. I could definitely see the use of having one on base and default-linux, for sure. I'll leave it up to other projects (hardened/embedded/etc) if they would want to follow suit, but it definitely makes Release Engineering work much easier having it. No objections. TBH we don't really have to edit those profiles often. We/I try to keep them as static as possible. When they do change it's usually cuz somebody has some brilliant idea for some non linux which forces all other profiles to update to mask or unmask some use flag. We/I tend to request that they update it themselves. But note taken. If I have to edit something I'll try to remember to add a ChangeLog entry. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage feature addition
On Tue, 2006-12-05 at 08:58 +, Steve Long wrote: Ned Ludd wrote: cd $(portageq envvar PORTDIR)/virtual/ mkdir mike cd mike echo 'echo OWNED at phase $EBUILD_PHASE' mike-0.0.ebuild emerge -pv mike Just checking; commands run there are run as root, right? Most often yes they would be preformed as the root user, unless the user of portage is in the portage group and has write access to the tree. Are they run in a chroot jail? umm nope. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
On Sun, 2006-12-03 at 14:33 -0500, Mike Frysinger wrote: On Sunday 03 December 2006 01:00, Alec Warner wrote: Recently commited to svn (but afaik released only in ~arch) is code to prevent the sourcing of ebuilds with no manifest. Thus ebuilds you randomly download off of bugzilla need to get a lookover from you and then ebuild foo.ebuild digest'd. i thought portage always did that ... if you have FEATURES=strict, it'll complain that a file doesnt exist in the Manifest and abort Nope.. Try this.. cd $(portageq envvar PORTDIR)/virtual/ mkdir mike cd mike echo 'echo OWNED at phase $EBUILD_PHASE' mike-0.0.ebuild emerge -pv mike -mike -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft attachments on bugs.g.o
On Sat, 2006-08-12 at 17:17 +0200, Harald van Dijk wrote: On Sat, Aug 12, 2006 at 02:42:32PM +, Francesco Riosa wrote: [...] $ cd gentoo-x86/*/foo This works better: $ cd gentoo-x86/*/foo/ This avoids the case where a file by the same name exists (for example, in licenses/). may be $ cd gentoo-x86/*-*/foo/ ? Maybe. That avoids virtual/*, which may or may not be a good thing, depending on your needs. (The only other case where it helps is uclibc, which is probably already a special enough case that it can be mostly ignored for this thread.) /me lands in the profiles dir when he really wants the *-* dir all the time. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make FEATURES=test the default
On Sat, 2006-08-05 at 12:57 +0200, Kevin F. Quinn wrote: On Sat, 5 Aug 2006 11:49:53 +0200 Danny van Dyk [EMAIL PROTECTED] wrote: Please re-read the list of packages that fail tests: * glibc * autoconf * gettext * tar That makes _4_ system packages. Before I would consider making FEATURES=test a default, I would add least want the system set to actually merge with it. So you're happy to let users install these packages without them knowing the tests would fail? I certainly agree they should pass their tests. autoconf-2.60, gettext-0.15 and tar-1.15.1-r1, which are the latest versions I have installed here, all pass on my system. If they fail on your platform, then you should make sure bugs are open and the relevant maintainers are doing something about it, and IMO they should not go to arch (i.e. should remain ~arch) until the test issues are resolved. Thing is, at the moment you have a bunch of packages installed that fail their tests. This may mean the tests are broken, however it may also mean the packages are not working correctly on your system, and I'd be concerned if I were you. With some arches this is not really an option. Also system pkgs such like the toolchain need to have additional deps. Avoiding the test phase doesn't make the packages work, obviously. glibc is somewhat of a special case; it is especially sensitive to the environment - many of the tests assume a vanilla RedHat environment, and often the test failures in glibc are not actual problems with glibc but limitations of the test suite. Sometimes the tests are flat out wrong. Take for example say we decided to paxtest ran itself in as the test.. This would surely fail on amd64 as one or two of the tests assume page sizes of 4096. However we should not be encouraging people to install glibc versions where the test failures are not understood. The alternative would then become for the end user to use another distro with less hassles. We would surely get the rep of sucking if nobody could even install libc. Clearly if something in glibc is not behaving properly, the effects can be nasty. Which for the most part is why features like this should be opt-in vs opt-out or be left up to the $ARCH teams. A lot of people are opting in so most of these will be fixed in due time.. The $ARCH teams *should* already be setting this feature for the most part before stable markings. It's a noble idea. I just don't think we are ready for FEATURES=test USE=test either. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make FEATURES=test the default
On Sat, 2006-08-05 at 16:07 -0400, Stephen P. Becker wrote: Mike Frysinger wrote: On Saturday 05 August 2006 14:56, Stephen P. Becker wrote: The metadata for sandbox suggests that it is under the control of the portage team, even if they lack a herd: ... because it is tightly integrated with portage ... there is the aspects of portage which require some sandbox env setup/etc..., then there is sandbox itself but seriously, you've been around forever, you know this :p Of course I know this, and it sucks. If sandbox is so tightly integrated with portage, then why *isn't* there a portage team member who works on sandbox? cuz portage is a python beast and azarah wrote sandbox in c as a preload module. And really as Mike already pointed out the problem lies within the mips dynamic linker/loader.. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
On Thu, 2006-08-03 at 11:21 +0200, Jakub Moc wrote: Mike Frysinger wrote: This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday once a month), same bat channel (#gentoo-council @ irc.freenode.net) ! Would like the Council to discuss the current state of Gentoo Bugzilla [1] and anon CVS/SVN [2]. Please elaborate why you need the council to discuss ongoing active bugs that are in progress. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
On Thu, 2006-08-03 at 08:06 -0500, Lance Albertson wrote: Ned Ludd wrote: On Thu, 2006-08-03 at 11:21 +0200, Jakub Moc wrote: Mike Frysinger wrote: This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday once a month), same bat channel (#gentoo-council @ irc.freenode.net) ! Would like the Council to discuss the current state of Gentoo Bugzilla [1] and anon CVS/SVN [2]. Please elaborate why you need the council to discuss ongoing active bugs that are in progress. I would also like to know why the council has to be involved since you've never sent an email to infra specifically asking the same thing first. Sure makes sense to me that you should ask the group involved with the work first instead of going to the top. But since I'm typing it now, I might as well answer it. I finally got the hardware this week for bugs, and I've been working on bringing those boxes online. And it's impressive hardware at a pretty kickass facility :) If I'm lucky, I'll have them at least booting on their own today. The anoncvs/svn stuff needs the attention of some knowledgeable cvs/svn guru. We want to ensure that we cover all our grounds in the setup so that we don't make a system that's easily DoS'able. If anyone wants to help out with that, please contact KingTaco as he's the contact for that project right now. It's just about ready afaik. We just want robbat2 to review the CVS setup and I probably need to drop a patch in the cvs pkg to disable compression. We probably also want Pylon to review the svn setup. Patience is indeed a virtue. Indeed.. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
On Thu, 2006-08-03 at 16:07 +0200, Jakub Moc wrote: Ned Ludd wrote: On Thu, 2006-08-03 at 08:06 -0500, Lance Albertson wrote: Would like the Council to discuss the current state of Gentoo Bugzilla [1] and anon CVS/SVN [2]. Please elaborate why you need the council to discuss ongoing active bugs that are in progress. Progress? Erm... see below. I would also like to know why the council has to be involved since you've never sent an email to infra specifically asking the same thing first. Sure makes sense to me that you should ask the group involved with the work first instead of going to the top. Because it's been broken for ages? Because I've asked the same on the bug I've referred to multiple times, as did quite a few other people, and the thing is still dead ~3 hours a day? (So uhm, the argument that infra doesn't know about is _really_ moot.) Because users complain over and over again? Because we are getting tons of duplicate bugs due to bugzilla being non-responsive? Ok this is basically bitching. Trust me we all know the current state of things with bugzilla and it's not fun for anybody. I'm sure however if you practice a little patience I'm sure you will be quite pleased with the end result. Because it's wasting hours of my time every day? Because if CVS was in the same state, you'd about have a revolution by now? I think you might be misunderstanding the role that the council plays. It's a body for technical matters that effect the mainly the code. Daily matters of infrastructure are handled by our infra team naturally. Funding for hardware is approved by the foundation. The anoncvs/svn stuff needs the attention of some knowledgeable cvs/svn guru. We want to ensure that we cover all our grounds in the setup so that we don't make a system that's easily DoS'able. If anyone wants to help out with that, please contact KingTaco as he's the contact for that project right now. It's just about ready afaik. We just want robbat2 to review the CVS setup and I probably need to drop a patch in the cvs pkg to disable compression. We probably also want Pylon to review the svn setup. Good news, would be nice if you actually responded on the bug maybe? Or send out some status report occasionally, since the bug's been open for ~1 year now? Patience is indeed a virtue. Indeed.. Sorry, having a critical facility broken for ~6 months right now =! patience. It plain sucks. You must live in that town where spare hardware and administrators grow on the trees. As it stands I do not see why this needs to be an agenda item for council discussions. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Tue, 2006-07-04 at 15:04 -0400, Mike Frysinger wrote: On Saturday 01 July 2006 02:46, Mike Frysinger wrote: well it's about that time of the year ... time for nominating people for the next Gentoo Council i guess i'll start off some mass nominations of random people off the top of my head who i think would do a good job ... there's a bunch more people i think would do a good job, but i'm going to cut my list short as it's already ridiculously long ... from current council: koon / agriffis / azarah / seemant / solar Thanks mike but I'm still undecided. A part of me wants to say no to a year long commitment yet another part of me wants to take it on. I for sure wanted to put this off till the last possible moment as I have to tend to a few things in my personal life. Some notes on some of the other people from my POV.. -- Busy/Next Year/Other -- dostrow (not around enough) Flameeyes (nice guy but talks to much, maybe next year) kloeri (nice guy but dunno if the council is a proper match) Pylon (maybe.. not around enough however) -- Maybe Yes -- Kugelfang (amd64/other?) wolf31o2 (releng/future trustee) -- Yes -- vapier (global) KingTaco (infra/amd64) lu_zero (senior dev/ppc) jaervosz (sec dev) ramereth (infra) robbat2 (gpg signing/CGL) -- No -- nattfodd (nfc) patrick (nope) pauldv (probably not/new dad) spb (really bad idea) -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Mon, 2006-07-31 at 14:00 -0700, Daniel Ostrow wrote: snip Some notes on some of the other people from my POV.. -- Busy/Next Year/Other -- dostrow (not around enough) /snip I'd agree that my availability over the past 6 months has been spotty at best. I was ramping up for a cross country move and all that that entails as well as dealing with a new position at work which was keeping me more busy then I thought I could have been. While I'm willing to state that I will be around more from here on out as I'm done moving and have settled into the routine that my job requires I believe that my prior record of availability (as it is all you have to go by) should certainly be taken into account. Thanks for bringing this point up solar. I'd still like to be considered as I believe I have a lot to offer but when you all are voting it should be something you are thinking about. Thanks for clarifying. I wish you the best of luck then. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Mon, 2006-07-31 at 23:30 +0200, Lars Weiler wrote: * Ned Ludd [EMAIL PROTECTED] [06/07/31 16:48 -0400]: Pylon (maybe.. not around enough however) I don't know the basis for your statement, but I'm quite good around. Is it that you don't see that many emails from me here at this list? Or is it that you don't see me hanging out in #gentoo-dev all the day? Neither actually. It's cuz I don't bump into you in that many channels. When I don't bump into people very often it's hard to think that they are around and will have a clear picture of whats going on in gentoo world outside of what we usually see on the lists. Keep in mind, that Gentoo is a quite large project. Usually I hide in the PowerPC department or in it's subsidiary for release engineering (the coffee over there is better!). CVS and SVN are both working, so that I don't have to go out for lunch with the infra-team. But in the evenings I join the German community and keep an ear on their demands. I'm one of those damned Americans. Perhaps that's why our paths don't cross that much outside of infra. None the less you are defiantly somebody I respect and I wish you the best of luck. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Mon, 2006-07-31 at 21:39 +, Bryan Ãstergaard wrote: On Mon, Jul 31, 2006 at 04:48:42PM -0400, Ned Ludd wrote: kloeri (nice guy but dunno if the council is a proper match) Guess I could do a lot worse than nice guy :) I haven't been part of the council before so it's a bit difficult saying if it's a good fit or not. But I'd certainly do my best to improve Gentoo if I'm elected. I can change that text to read.. (pretty kick ass guy but still dunno) I think just about everybody knows my work by now and know that I care deeply about Gentoo. Who knows, maybe I care too much? Or care about the wrong things? I've seen and dealt with you mostly on new recruits and people retiring.. Bit of devrel stuff.. More people oriented vs technical work. I know you also work on the alpha's but that seems more bump here bump there kinda of work. You are around a lot (which is key), and you are pretty personable. Still I have mixed feelings. I think perhaps you would make a kick ass trustee. Fortunately, that's up to the general developer community to decide just as it should be. Let's hope we get the best possible council and that we'll continue to see Gentoo improving. Agreed.. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Tue, 2006-08-01 at 00:29 +0200, Alexandre Buisse wrote: On Mon, Jul 31, 2006 at 23:14:56 +0200, Ned Ludd wrote: -- No -- nattfodd (nfc) ... clue? I might agree to both :) Meaning only that we have not really worked together. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Wed, 2006-07-19 at 17:10 +0100, Ciaran McCreesh wrote: On Wed, 19 Jul 2006 11:10:51 -0400 Ned Ludd [EMAIL PROTECTED] wrote: | Every single year quarter after quarter the more updates | that happen the slower portage is becoming. | Care to solve that? This is a minute amount of time in comparison to anything significant. If you care about Portage speed, you'd be far better off reducing the number of packages that users have installed and reducing the number of packages in the tree. | My fix would be to remove the ability to do package moves | from portage all together. Which makes me rather glad that you're not fixing anything... | |i dont think this sort of thing should hold up tree | shuffles ... | | Well it should. | | package.keywords package.use package.mask etc.. | | Where is the stability and consistency when we end up | forcing people to update /etc/portage files... Erm... Portage updates these automatically. as .cfg_** files. The end user still has to run an etc-update and pray that it was not a file he/she had in masking. None the less I think you missed the part in the tread along time ago which Stefan said he would do the moves at the same time as bumps. Doing it that way solves most of the problems. Granted not all of them like the vdb/*DEPEND entries of other pkgs. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Tue, 2006-07-18 at 14:53 +0200, Stefan Schweizer wrote: Hi, the herd of voip packages is constantly growing and according to herdstat -p voip we already have 60 packages in the voip herd. Those are currently in the categories net-misc, net-im, net-libs, dev-libs and media-libs. Most of them would fit perfectly into a new net-voip category. Those are enough packages to allow the creation of a new category. More important than the current packages I think it is to put new packages into the more precise net-voip instead of net-misc/net-im. For example some packages in my overlay [1] maintained by the fellow gentoo users peper and fuoco. Also there is a lot of stuff waiting in stkn's private voip overlay The 47 voip packages in net-misc and net-im should be moved over to the new category definitely, you can get the list with: herdstat -p voip | grep -e net-im -e net-misc From the others I think dev-libs/ilbc-rfc3951 should be moved, too. Creation of a new categories is fine. pkg moves are bad. See the countless other posting on this subject of why pkg moves are bad. Any objections, problems with the plan, comments? Sure I'll step up and say I object to the part of your plan which involves a shitton of pkgmoves. Moving pkgs from existing categories into another category causes numerous problems that portage can't solve as easy as the rest of us might think so please just don't do that part. I've got no objection to the creation of a new category for *new* packages. [1] http://overlays.gentoo.org/svn/dev/genstef/net-im -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Tue, 2006-07-18 at 15:15 +0100, Ciaran McCreesh wrote: On Tue, 18 Jul 2006 09:34:37 -0400 Ned Ludd [EMAIL PROTECTED] wrote: | Creation of a new categories is fine. pkg moves are bad. | See the countless other posting on this subject of why pkg | moves are bad. Uh, as far as I recall, you've yet to come up with any technical explanation other than it breaks one of my pet projects... The gains of consistency and manageability far outweigh the minor inconvenience. There is no consistency for end users when stuff keeps getting shuffled around. Portage still can't get it right. 'fixpackages' does not correct the installed vdb content so the problems extend past any of my pet projects. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New category: net-voip
On Tue, 2006-07-18 at 15:51 +0200, Stefan Schweizer wrote: Ned Ludd wrote: Creation of a new categories is fine. pkg moves are bad. See the countless other posting on this subject of why pkg moves are bad. yeah new packages is my primary concern. Any objections, problems with the plan, comments? Sure I'll step up and say I object to the part of your plan which involves a shitton of pkgmoves. Moving pkgs from existing categories into another category causes numerous problems that portage can't solve as easy as the rest of us might think so please just don't do that part. I've got no objection to the creation of a new category for *new* packages. I talked with you in IRC about this more. We will do the package moves only when a bump occurs and will make sure that stable as well as ~arch get an updated ebuild. Sweet/Thanks that works and provides a clear path to upgrade/bump. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making procfs mount as nosuid,noexec by default
On Sat, 2006-07-15 at 13:41 -0400, Ned Ludd wrote: On Sat, 2006-07-15 at 17:45 +0100, Daniel Drake wrote: Hi, The local root exploit-of-the-week would have been unable to run if our users systems had /proc mounted with nosuid and/or noexec It would be worthwhile considering making this a default. What are people's thoughts? I mailed Mike about this very thing a month ago. Pretty sure it should be showing up in an upcoming baselayout. But yeah it's a good idea for the nosuid part anyway. Not 100% sure about the noexec part as that might break upx which calls /proc/self/exe as part of it's decompresser routines. Tested it using a and it seems safe across the board. upx,busybox and other multicall binaries seem quite content. Linus also recently suggested that the same be done in the kernel directly via the proc_fill_super() function. This seems like an ideal route to go for us as it would get inherited by all the existing users who wont notice the change in the default fstab file. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] New emerge --mindeps option for exclusion of build time dependencies (bug #132355)
On Tue, 2006-07-11 at 22:32 -0700, Zac Medico wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, The attached patch for bug #132355 [1] adds a --mindeps option for emerge that effectively allows build time dependencies to be excluded from dependency calculations involving binary and installed packages. With this patch, it's possible to remove all build time dependencies from a system with the command `emerge --depclean --mindeps`. When --mindeps is used to install packages, it causes build time dependencies to be excluded for binary packages and packages that are already installed. This patch will change the previous default behavior for `emerge --usepkg package list`, but if desired, the user will be able use --mindeps together with --usepkg. Are there any suggestions to improve on this idea or is it fine the way that it is? Please invert the logic so that rather than changing default behavior you add a new option choose the types of deps to include. I was in favor and thought we were going to do it after 2.1 and the 2006 release under the idea of the variable ACCEPT_DEPENDS export ACCEPT_DEPENDS=DEPEND RDEPEND PDEPEND emerge -K system Whatever we do in the end does not really matter as long as we don't change default expected behaviors. Zac [1] http://bugs.gentoo.org/show_bug.cgi?id=132355 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) iD8DBQFEtIlf/ejvha5XGaMRAo26AKCovCALx/VDIft6e+0lh+FI7IQsoQCg8o6M UW+dnXPwMe/tIje1A4RYqRs= =9uIv -END PGP SIGNATURE- -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On Mon, 2006-07-10 at 01:34 -0700, Richard Fish wrote: On 7/9/06, Denis Dupeyron [EMAIL PROTECTED] wrote: 2) If yes, are there any other flags that ebuilds should die on ? My (user) opinion is that ebuilds should not die on CFLAGS, at least not until per-package CFLAGS are implemented. per pkg cflags are here already it would fall under the per pkg env variables. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 15:18 -0500, Tushar Teredesai wrote: On 7/7/06, Ned Ludd [EMAIL PROTECTED] wrote: You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. LFS http://www.linuxfromscratch.org/lfs has always been based on a vanilla toolchain. Never ran into issues. Of course, we do apply upstream patches when needed. They patch gcc as needed also. http://www.linuxfromscratch.org/hlfs/ -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 23:09 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote: On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. Is that a threat? If not, is there a reason behind this? Yes.. When users or devs complain non stop when they don't understand something it leaves us with a few choices. 1) put up with people not having a clue. 2) remove the option so they can't bitch about it. Option #1 is not fun as it pushes the hand on #2 Option 3: Enlighten me. I have explained why I feel the way I do, so if there's some big flaw in my understanding, please do correct it. Sigh... I'm not going to sit here and bicker with you. At the end of the day here is what matters.. Your giving Mike a hard time on the most vital of all programs in this distro and that just sucks so please stop and just be happy that the toolchain works as well as it does. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
Quite honestly I see this as providing no advantage what so ever over the current USE=mmx blah foo that we already have.. Please explain to me what I'm missing here.. How does this help us? On Fri, 2006-07-07 at 16:20 +0200, Danny van Dyk wrote: OK, this rfc/proposal is competing with Flameeye's proposal: I suggest to add a CPUFLAGS USE_EXPAND variable to the tree. This should be set to sane defaults in the profiles. I.e. for x86, it should not set CPUFLAGS at all, and on AMD64 it should be CPUFLAGS=mmx sse sse2 I'm no quite sure, but i assume ppc/ppc32 should leave CPUFLAGS empty, and ppc/ppc64 should set CPUFLAGS=altivec. The main reasons for a USE-like implementation om contrast to Diego's proposal are: a) There is no call to gcc involved, but only a call to use(). This allows usage in metadata phase. b) There is no implicit (non-transparent) choice made for the users. c) It doesn't mix CFLAGS' purpose (which has a meaning beyond Gentoo) with the purpose of optional codepaths. I know, there aren't use-based deps in portage yet, but I really feel uncomfortable to be unable to use cpuflags in metadata phase. This is what worries me most. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 18:53 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote: On Fri, 7 Jul 2006 07:46:16 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: On Thursday 06 July 2006 16:14, Harald van Dijk wrote: Gentoo's gcc with the vanilla flag isn't the official GCC. Most patches don't get appplied, but some do. Plus, gcc[vanilla] isn't a supported compiler in Gentoo. you're just griping because i forced ssp/pie regardless of USE=vanilla ... I didn't mind that you applied ssp/pie patches regardless of USE=vanilla, I did mind that you applied the stub patches with USE=nossp vanilla, and I also didn't like that this was either done accidentally but ignored when pointed out, or that this was done deliberately with a misleading cvs log message. If you take out the stub patches (which incidentally have no impact on code generation), many builds will simply fail because they expect the additional flags from ssp, htb etc to be there. That's the point. I mentioned being able to test whether your own software compiles with a pure GNU toolchain as a desire. Being able to see whether unofficial compiler options are used is not just a nice extra, but even necessary for that. Since they have no impact on code generation, their presence doesn't impact comparisons with a pure upstream release. since gcc-4.0 and below are on the way out, i have no problem changing this behavior besides, since both of these technologies are in mainline gcc now, i really dont see how you can continue to gripe with gcc-4.1.1+ I don't know how much gcc-spec-env.patch can be trusted, and even if it is 100% safe, such patches don't belong in anything that would be called vanilla. (I have commented on that patch long before this thread started, so don't think I'm just looking for something to complain about now.) Again, if you don't gave GCC_SPECS defined in your environment then that patch makes no difference to code generation. Yes, but if GCC_SPECS is defined in the environment, I don't know enough about it to be sure that it interacts properly with -specs command-line options. Even if it works perfectly, though, the point remains that it does not belong in a USE=vanilla build. Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote: On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. Is that a threat? If not, is there a reason behind this? Yes.. When users or devs complain non stop when they don't understand something it leaves us with a few choices. 1) put up with people not having a clue. 2) remove the option so they can't bitch about it. Option #1 is not fun as it pushes the hand on #2 You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. If you mean modifying the build system to actually work properly, then I have no problem with that. USE=vanilla refers to runtime behaviour, not the build system. (See use.desc.) Specifically, if patches are applied that make sure GCC compiles, and those patches make sure GCC compiles to the same program intended by the GCC devs at that release, those patches are appropriate, IMO. None of the GCC patches I have problems with are of this nature. If you mean vanilla GCC + build fixes is unusable, then I'd appreciate an explanation, because as far as I know, it can work just fine as a system compiler, and plenty of people, at some times myself included, use it as one. You use the Gentoo modified one. Regardless of what USE= flags you have enabled you are still getting Gentoo behaviors. Think vanilla-sources are pure? They are not. They get patched as well with the minimal amount of patches required. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 13:19 +0100, Ciaran McCreesh wrote: On Thu, 6 Jul 2006 12:52:29 +0200 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: | Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags | present in the tree, almost never used to get new dependencies, but | usually used to supply econf switches. | | This works as long as the user enable the flags, but for AMD64 the | story was, until now, that we simply enabled them when they worked, | because we had some minimum support available. Unfortunately this | became a problem with the introduction of nocona, because that is an | amd64-like system but with no 3dnow. And there is the problem that | sse3 is supported only in later versions of Athlon64 and so on. The other option here... Is to rename the x86 flags to x86_mmx, x86_3dnow etc, and use amd64_sse3 for amd64 flags, since they're not really the same as the x86 flags. There's probably some USE_EXPAND trickery that can be used here... CPU_FEATURE_X86=mmx sse - cpu_feature_x86_mmx etc might be cleaner? I tend to agree this might be a cleaner approach vs having to edit redit CFLAGS all over the place. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 17:09 +0200, Simon Stelling wrote:
Ciaran McCreesh wrote:
You can do it through bashrc. But then, if this is about working around
Portage's annoying lack of sane cross compile handling, why not put a
little effort into fixing it properly rather than a lot of effort into
making the tree more complicated?
Err, I think you're mixing up different things.
How should portage be
able to do sane cross compiling if you control the instruction sets
through use flags which are blocked in profiles the build system is
using?
That is not the case anymore.. See PORTAGE_CONFIGROOT= and the
attachment as an example which solves this exact problem.
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
export PORTDIR=$(portageq envvar PORTDIR)
export ROOT=/dev/shm/blah
export PORTAGE_CONFIGROOT=${ROOT}
PROFILES=$(grep ^[a-z,0-9] ${PORTDIR}/profiles/profiles.desc | awk '{print
$2}' | sort -u)
mkdir -p ${PORTAGE_CONFIGROOT}/etc/
cd ${PORTAGE_CONFIGROOT}/etc/
for p in ${PROFILES}; do
rm -f make.profile
ln -s ../../../../${PORTDIR}/profiles/${p} make.profile
touch make.conf
ls -ld $(readlink -f make.profile)
emerge --info
done
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
Diego 'Flameeyes' Pettenò wrote:
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null
Thoughts? Comments?
How will you handle non-gcc compilers?
Non gcc compilers have never been supported and probably never will be.
Gentoo uses the GNU Toolchain.
--
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 18:44 +0200, Diego 'Flameeyes' Pettenò wrote: On Thursday 06 July 2006 17:33, Ned Ludd wrote: I tend to agree this might be a cleaner approach vs having to edit redit CFLAGS all over the place. Really if one has to disable mmx support in one package, it should be disabled altogether, in the real world we're all in, mmx useflag is enabled by the vast majority of our users. All together as in across the board? Or simply for the 1 pkg in question? I seriously hope you are not suggesting across the board cuz that would make me laugh at you for a good hour solid. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 19:09 +0200, Diego 'Flameeyes' Pettenò wrote: On Thursday 06 July 2006 18:58, Ned Ludd wrote: All together as in across the board? Or simply for the 1 pkg in question? For the package in question of course. Do you think I'm an idiot? Seriously? Well. Sorry but there is very little we can assume these days. Just when you think people know what they are doing along comes some hair brained idea that sound ok on the surface but can cause lots of fun problems. -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Announce: standalone libgpm
Please move this thread to the appropriate mailing list.. (ie not this list) On Wed, 2006-07-05 at 14:31 +0200, Enrico Weigelt wrote: * Mike Frysinger [EMAIL PROTECTED] schrieb: snip Yes, would be better, if it's included in the gpm release. But: it should be possible to build/install it independently from gpm, and also to build gpm against an already installed libgpm. So actually two separate packages, maybe distributed in one tarball. considering gpm uses autotools, i really dont see why there needs to be all that many changes ... write it correctly and it'd be easy to fold into configure.ac/Makefile.am ./configure --disable-binaries That doesn't seem to be clean enough for me. I need the libgpm, and only libgpm, built, and then gpm server built against this (already installed) libgpm, found via pkg-config. I've got very strict policies at this point. My further plan in short words: + further tests on libgpm + split off the gpm server and rewrite to build against an already installed libgpm (found via pkg-config) + put both into some cumulative package, which can be build just as the current gpm package. Meanwhile we also should try to get in the pkg-config stuff, and let several parts to be switched off as you suggested, optionally build the server against an installed libgpm, etc. cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
