Re: [gentoo-portage-dev] Package compression header for binhosts

2010-06-01 Thread Ned Ludd
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?

2010-02-14 Thread Ned Ludd
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?

2009-07-02 Thread Ned Ludd
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?

2009-07-01 Thread Ned Ludd
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?

2009-05-07 Thread Ned Ludd
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?

2009-05-07 Thread Ned Ludd
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

2009-04-18 Thread Ned Ludd
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

2009-03-26 Thread Ned Ludd
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

2009-03-25 Thread Ned Ludd
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

2009-03-17 Thread Ned Ludd
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

2009-03-17 Thread Ned Ludd
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

2009-03-16 Thread Ned Ludd
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

2009-03-16 Thread Ned Ludd
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

2009-02-04 Thread Ned Ludd
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

2009-02-03 Thread Ned Ludd
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

2008-12-02 Thread Ned Ludd

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

2008-12-01 Thread Ned Ludd

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] How to extract the version/revision of an installed package?

2008-11-25 Thread Ned Ludd

On Tue, 2008-11-25 at 14:03 -0800, Brian Harring wrote:
 On Tue, Nov 25, 2008 at 06:05:21PM +0200, Amit Dor-Shifer wrote:
  Given the following:
  # qlist -Iv sys-apps/portage
  sys-apps/portage-2.1.4.5
 
  How do I safely extract the 2.1.4.5?
 
  (I don't necessarily need to use qlist. Just want to get the version of an 
  installed package within a bash script)
 
 This *really* should be folded into portageq offhand- it's the initial 
 step towards shifting versionator logic (yet another standalone 
 parser/comparison implementation) into the PM.
 
 Counter arguements?
 ~brian

Yes. he said a bash script. portageq still takes a few seconds to load
and invokes far far to many instructions for very simple info.

The 3 execve's I just posted are still faster than one portageq call.
So.. foo.c wins again. :p




-- 
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux




Re: [gentoo-portage-dev] How to extract the version/revision of an installed package?

2008-11-25 Thread Ned Ludd
On Tue, 2008-11-25 at 16:31 -0800, Brian Harring wrote:
 On Tue, Nov 25, 2008 at 04:18:22PM -0800, Ned Ludd wrote:
  
  On Tue, 2008-11-25 at 14:03 -0800, Brian Harring wrote:
   On Tue, Nov 25, 2008 at 06:05:21PM +0200, Amit Dor-Shifer wrote:
Given the following:
# qlist -Iv sys-apps/portage
sys-apps/portage-2.1.4.5
   
How do I safely extract the 2.1.4.5?
   
(I don't necessarily need to use qlist. Just want to get the version of 
an 
installed package within a bash script)
   
   This *really* should be folded into portageq offhand- it's the initial 
   step towards shifting versionator logic (yet another standalone 
   parser/comparison implementation) into the PM.
   
   Counter arguements?
   ~brian
  
  Yes. he said a bash script. portageq still takes a few seconds to load
  and invokes far far to many instructions for very simple info.
  
  The 3 execve's I just posted are still faster than one portageq call.
  So.. foo.c wins again. :p
 
 Curious, does qatom handle use deps?  Slot deps?  Plans to add 
 repository deps (admittedly they've not landed)?

Nope. I'm sticking with EAPI=0 behaviorism's and the development of
those utils has pretty much stopped. Well I did slip in some :slot
handling a little while ago due to the syntax of the world file changing
a while back after being annoyed.

 The point of shifting it into portageq isn't speed based; it's to 
 transfer responsibility for atom parsing from multiple authorities 
 into a single one.

It's still a good idea to expend the functionality of portageq. But for
scripting from bash, reality wins as most everything python-portage
related falls a little short due to the sheer number of file i/o calls
python makes looking for files that might not pertain at all to the info
the user is after. Granted today it's a heck of a lot faster than it
used to be a few years ago when the loading problem was first noticed. 

 Besides, just because portageq is slow for heavy data ops doesn't mean 
 it's going to be slow for doing simple atom splitting.  Quick test 
 locally, cold cache pegs it at 3s- with minor use of snakeoil 
 demandload that's likely halvable.
 
 ~brian


I'm all in favor of using the right tool for the task at hand whatever
that may be.




Re: [gentoo-portage-dev] About system and world

2007-10-21 Thread Ned Ludd
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

2007-08-07 Thread Ned Ludd
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

2007-08-06 Thread Ned Ludd
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?

2007-07-20 Thread Ned Ludd
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...

2007-07-17 Thread Ned Ludd
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)

2007-07-17 Thread Ned Ludd
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

2007-07-17 Thread Ned Ludd
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

2007-07-16 Thread Ned Ludd
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

2007-07-12 Thread Ned Ludd
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

2007-07-12 Thread Ned Ludd
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

2007-07-12 Thread Ned Ludd
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

2007-07-04 Thread Ned Ludd
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

2007-06-21 Thread Ned Ludd
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

2007-06-20 Thread Ned Ludd
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!

2007-05-31 Thread Ned Ludd
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!

2007-05-31 Thread Ned Ludd
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

2007-05-31 Thread Ned Ludd
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.

2007-05-30 Thread Ned Ludd
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

2007-04-27 Thread Ned Ludd
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

2007-04-26 Thread Ned Ludd
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

2007-04-20 Thread Ned Ludd
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

2007-04-20 Thread Ned Ludd
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

2007-04-20 Thread Ned Ludd
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

2007-04-17 Thread Ned Ludd
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

2007-04-10 Thread Ned Ludd
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

2007-04-09 Thread Ned Ludd
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?

2007-04-06 Thread Ned Ludd
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

2007-04-05 Thread Ned Ludd
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?

2007-03-29 Thread Ned Ludd
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

2007-03-29 Thread Ned Ludd
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

2007-03-29 Thread Ned Ludd
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

2007-03-29 Thread Ned Ludd
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

2007-03-29 Thread Ned Ludd
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)

2007-03-27 Thread Ned Ludd
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

2007-03-27 Thread Ned Ludd
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

2007-03-26 Thread Ned Ludd
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

2007-03-16 Thread Ned Ludd
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-dev] dont use `which` in ebuilds

2007-03-12 Thread Ned Ludd
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


Quick search shows the following ebuilds are abusing this behavior.

Matches `which 

app-dicts/stardict/stardict-2.4.8.ebuild:42:
app-emulation/xen-tools/xen-tools-3.0.2-r3.ebuild:57:
app-emulation/xen-tools/xen-tools-3.0.2-r4.ebuild:52:
media-gfx/quat/quat-1.20.ebuild:26:
sci-chemistry/molden/molden-4.3.ebuild:30:
sci-libs/blas-atlas/blas-atlas-3.6.0-r1.ebuild:33:
sci-libs/blas-atlas/blas-atlas-3.6.0-r2.ebuild:34:
sci-libs/blas-atlas/blas-atlas-3.6.0.ebuild:28:
sci-libs/lapack-atlas/lapack-atlas-3.6.0.ebuild:64:
sci-libs/lapack-reference/lapack-reference-3.0.ebuild:52:
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:

And matches $(which 
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.0.ebuild:34:
dev-util/kdesvn/kdesvn-0.11.0.ebuild:35:
games-emulation/advancemame/advancemame-0.104.0.ebuild:35:
games-emulation/advancemame/advancemame-0.104.0.ebuild:37:
games-emulation/advancemame/advancemame-0.104.0.ebuild:39:
games-emulation/advancemame/advancemame-0.106.0.ebuild:40:
games-emulation/advancemame/advancemame-0.106.0.ebuild:42:
games-emulation/advancemame/advancemame-0.106.0.ebuild:44:
games-emulation/advancemenu/advancemenu-2.4.13.ebuild:42:
games-emulation/advancemenu/advancemenu-2.4.13.ebuild:43:
games-emulation/advancemenu/advancemenu-2.4.13.ebuild:44:
games-fps/doomsday/doomsday-1.9.0_beta5.ebuild:32:
games-fps/quake2-icculus/quake2-icculus-0.16.1-r1.ebuild:72:
games-fps/quake2-icculus/quake2-icculus-0.16.1.ebuild:51:
games-mud/tkmoo/tkmoo-0.3.32.ebuild:32:
games-strategy/boson/boson-0.13.ebuild:43:
games-strategy/boson/boson-0.13.ebuild:44:
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:
sci-geosciences/grass/grass-6.2.0-r1.ebuild:111:
sci-geosciences/mapserver/mapserver-4.10.0.ebuild:106:
sci-misc/boinc/boinc-4.72.20050813-r3.ebuild:56:
sci-misc/boinc/boinc-5.2.14.ebuild:57:
sci-misc/boinc/boinc-5.4.11.ebuild:53:
sci-misc/boinc/boinc-5.5.6.ebuild:59:
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:
x11-misc/xoo/xoo-0.7.ebuild:25:

-- 
Ned Ludd [EMAIL PROTECTED]
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] LC_ALL and friends in make.conf

2007-03-08 Thread Ned Ludd
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

2007-03-03 Thread Ned Ludd
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

2007-02-08 Thread Ned Ludd
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

2007-02-08 Thread Ned Ludd
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

2007-02-07 Thread Ned Ludd
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

2007-02-06 Thread Ned Ludd
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

2007-02-02 Thread Ned Ludd
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

2007-01-29 Thread Ned Ludd
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

2007-01-27 Thread Ned Ludd
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)

2007-01-25 Thread Ned Ludd
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

2007-01-16 Thread Ned Ludd
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

2007-01-10 Thread Ned Ludd
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

2007-01-10 Thread Ned Ludd
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

2007-01-08 Thread Ned Ludd
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

2007-01-08 Thread Ned Ludd
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

2006-12-05 Thread Ned Ludd
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

2006-12-03 Thread Ned Ludd
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

2006-08-13 Thread Ned Ludd
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

2006-08-05 Thread Ned Ludd
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

2006-08-05 Thread Ned Ludd
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

2006-08-03 Thread Ned Ludd
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

2006-08-03 Thread Ned Ludd
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

2006-08-03 Thread Ned Ludd
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

2006-07-31 Thread Ned Ludd
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

2006-07-31 Thread Ned Ludd
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

2006-07-31 Thread Ned Ludd
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

2006-07-31 Thread Ned Ludd
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

2006-07-31 Thread Ned Ludd
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

2006-07-22 Thread Ned Ludd
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

2006-07-18 Thread Ned Ludd
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

2006-07-18 Thread Ned Ludd
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

2006-07-18 Thread Ned Ludd
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

2006-07-15 Thread Ned Ludd
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)

2006-07-12 Thread Ned Ludd
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.

2006-07-10 Thread Ned Ludd
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)

2006-07-08 Thread Ned Ludd
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)

2006-07-08 Thread Ned Ludd
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

2006-07-07 Thread Ned Ludd
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)

2006-07-07 Thread Ned Ludd
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)

2006-07-07 Thread Ned Ludd
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

2006-07-06 Thread Ned Ludd
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

2006-07-06 Thread Ned Ludd
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

2006-07-06 Thread Ned Ludd
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



  1   2   3   >