Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org

[Patrick Lauer]

On Fri, 2005-11-25 at 12:14 +, kang wrote:
> Now people can also use NCSA Mosaic. It's valid as long as you can run
> it. But a browser with vulns, unsupported by the vendor, with a broken
> CSS, I think you do not have to support it. Well of course, if you like
> it just do it ;)
Hmmm.. I think we should "only" support standard HTML/XHTML/CSS.
No need to add "fixes" for known-broken browsers I guess.
(And no "old cruft" where avoidable)

> Oh btw, *great* progress on the design.
Yess, it's getting somewhere. 

> - The bottom boxes are uneven in size, it looks a bit strange. Also i
> still wonder about this whole concept, as its not the first place you
> look for links. I'll take an example:
I'd have expected those in a nice collapsed menu on top with annoying
mouseOver expansion
(I hate that because if you move your mouse across the page you have one
expanded menu hiding whatever is below)
Like this they are "out of sight" and on smaller screens not directly
visible without scrolling.

> http://wwwredesign.gentoo.org/doc/en/index.xml
> I am in 1024x768 and I don't see the boxes if I don't scroll. I don't
> think you acn reduce every page so that you see them without scrolling.
> Unfortunately I dont see any good solution. 
The common solution is a menu on the left side, but then it gets tricky
with expanding/collapsing and keeping the whole menu visible.
> Maybe it'll stay this way. I
> would put more than 2 news items on the front page then, even if it also
> hides the boxes a bit on 800x600 or 1024, because it doesnt give much
> info to have 2 items per news page ;)
I guess that's part of it being a prototype and all that ;-)

Some usability issues:
The top right textlinks are too dark and quite small. They aren't easily
readable and don't present themselves as clickable items (especially
with the dotted line below them they look like "random" text)

The "manage / customize / optimize / interact" boxes on the startpage
don't give any useful information (all those links are available in the
"unreadable" text above and in the nice boxes at the bottom. Also their
format looks like GoogleAds to me, so I mentally filed them away as
"more ads".
As they don't appear anywhere else on the website I'd just remove them.

Another (minor) inconsistency is that on the startpage the date stamp on
the left shifts the text to the right, but all other subpages have the
text left-aligned. That is unexpected, I'd like all pages to behave
consistently.
This also includes the "infinity" logo that's only in one place (why
have it at all then?)

Apart from that I like the spartan look. 
Keep up the good work!

Patrick

-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Misquoted in the GWN

[Patrick Lauer]

On Mon, 2005-11-28 at 17:54 +, Ciaran McCreesh wrote:
> On Mon, 28 Nov 2005 10:48:01 +0100 Henrik Brix Andersen
> <[EMAIL PROTECTED]> wrote:
> | A friend of mine just alerted me to the fact, that I am featured in
> | this weeks Gentoo Weekly News. Odd, I thought, noone had asked me
> | anything regarding the GWN...
> 
> Not the first time this has happened...

Not the first time that people whine. Meh.

> | I suggest that in the future, all developers who are directly quoted
> | in the GWN are contacted prior to posting the quotes. I realize that
> | this will put a bit more work load on the GWN authors, but it should
> | be as simple as sending a mail with the relevant section quoted for
> | the developer to accept.
> 
> Also, why not bring back the "post to -core" requirement? Make it a
> rule that it can't be labelled as an official Gentoo publication unless
> it gets some review...
Why not bring back the "the GWN is a community thing and YOU can also 
contribute!!!" mentality?

That Ulrich and I have made some suboptimal decisions in the past is a
fact, but why aren't there more contributors to the GWN so that we two
aren't single points of failure?

/me returns to lurking in some dark caves
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Optimizing performance

[Patrick Lauer]

Hi all,

I was wondering if there are any sane ways to optimize the performance
of a Gentoo system.
Overoptimization (the well known "-O9 -fomgomg" CFLAGS etc.) tends to
make things unstable, which is of course not what we want. The "easy"
way out would be buying faster hardware, but that is usually not an
option ;-)

So ... what can be done to get the stable maximum out of your hardware?

In my experience (x86 centric - do other arches have different
"problems"?) the following is stable, but not necessarily the optimum:
- don't overtweak CFLAGS. "-O2 -march=$your_cpu_family" seems to be on
average the best, -O3 is often slower and can cause bugs
- don't do anything with ASFLAGS, LDFLAGS. This causes weird random
breakage (e.g. LDFLAGS="-O1" causes prelink to fail with "absurd"
errors) and doesn't give a noticeable performance boost
- check that all IDE disks use DMA mode, otherwise they are limited to
~16M/s with a huge CPU usage penalty. Sometimes (application-specific)
increasing the readahead with hdparm gives a huge throughput boost.
- kernel tweaks like preempt may increase the responsiveness of the
system, but often reduce throughput and may have unexpected sideeffects
like random audio stutter as well as random kernel crashes ;-)
- kernel tweaks like setting swappiness or using a different I/O
scheduler (CFQ, deadline) should help, but I'm not aware of any "real"
benchmarks except microbenchmarks (can create 1M files 10% faster! -
yes, but how does it behave with a normal workload?)
- using a "smarter" filesystem can dramatically improve performance at
the potential cost of reliability. As data on FS reliability is hard to
find from unbiased sources this becomes a religious issue ... migrating
from ext3 to reiserfs makes "emerge sync" extremely much faster, but is
reiserfs sustainable?

Are there any application-specific tweaks (e.g. "use the prefork MPM
with apache2")? What is known to break things, what has usually
beneficial behaviour? Are there any useful benchmarks that show the
performance difference between different settings?

Thanks for your input,

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Optimizing performance

[Patrick Lauer]

On Thu, 2005-12-15 at 07:43 -0700, Duncan wrote:
> > I was wondering if there are any sane ways to optimize the performance
> > of a Gentoo system.
> This really belongs on user, or perhaps on the appropriate purposed list,
> desktop or hardened or whatever, not on devel.  That said, some
> comments...  (I can't resist. )
-user has the risk of many "use teh -fomglol flag, it si teh fast0r" ;-)
hardened doesn't have much to do with performance (although I'd be
interested what impact - if any - the different security features have!)
 
> > - don't overtweak CFLAGS. "-O2 -march=$your_cpu_family" seems to be on
> > average the best, -O3 is often slower and can cause bugs
> 
> A lot of folks don't realize the effect of cache memory on optimizations. 
> I'll be brief here, but particularly for things like the kernel that stay
> in memory, -Os can at times work wonders, because it means more of the
> working set stays in a cache closer to the CPU, and the additional speed
> in retrieving that code far outweighs the compromises made to
> optimizations to shrink it to size.  Conversely, media streaming or
> encoding apps are constantly throwing out old data and fetching new data,
> and the optimizations are often more effective for them, so they work
> better with -O2 or even -O3.
I've not seen any substantial benefits from -Os over -O2.
Also the size difference is quite small - ~5M on a "normal" install iirc

> There have been occasional problems with -Os, generally because it isn't
> used as much and gets less testing, so earlier in a gcc cycle series. 
> However, I run -Os here (amd64) by default, and haven't seen any issues
> that went away if I reverted to -O2, over the couple years I've been
> running Gentoo. 
I've seen some reproducable breakage, e.g. KDE doesn't like it at all
>  (Actually, that has been the case, even when I've edited
> ebuilds to remove their stripflags calls and the like.  Glibc and xorg
> both stripflags including -Os.  xorg seemed to benefit here from -Os after
> I removed the stripflags call, while glibc worked but seemed slower. Note
> that editing ebuilds means if it breaks, you get to keep the pieces!)
... which is exactly what I wanted to avoid. Ricing for the sake of it is 
boring ;-)

> For gcc, -pipe doesn't improve program optimization, but will make
> compiling faster.  -fomit-frame-pointers makes smaller applications if
> you aren't debugging.  Those are both common enough to be fairly safe. 
agreed
> -frename-registers and -fweb may also be useful. (-fweb ceases to be so on
> gcc4, however, because it is implemented differently.)  -funit-at-a-time
> (new to gcc-3.4, so don't try it with gcc-3.3) may also be worth looking
> into, altho it's already enabled by -Os. These latter flags are less
> commonly used, however, thus less well tested, and may therefore cause
> very occasional problems. (-funit-at-a-time was known to do so early in
> the 3.4 cycle, but those issues should have been long ago dealt with by
> now.)  I consider those /reasonably/ conservative, and it's what I run. 
> If I were running a server, however, I'd probably only run -O2 and the
> first two (-pipe and -fomit-frame-pointers).
on a server you'd not use omit-frame-pointers to keep debuggability I think.
> Do some research on -Os, in any case.  It could be well worth your time.
from my (limited) experience it isn't, especially on CPUs with larger caches

> This suggestion does involve hardware, but not a real heavy cost, and the
> performance boost may be worth it.
That's usually not an option :-)

>  Consider running a RAID system.  I
> recently switched to RAID, a four-disk setup, raid1/mirrored for /boot,
> raid6 (for redundancy) for most of the system, raid0/striped (for speed)
> for /tmp, the portage dir, etc, stuff that was either temporary anyway, or
> could easily be redownloaded. (Swap can also be striped, set equal
> partitions on each disk and set equal priority for them in fstab.) I was
> very pleasantly surprised at how much of a difference it made!
Yes. 4-disk raid5 delivers amazing performance with minimal CPU overhead (~10% 
@1Ghz)
But 4 disks at 100Euro + controller (100 Eur) is more than the price of
a "new" system for most people.
>  If you have
> onboard SATA and are buying new disks so can buy SATA anyway (my case),
> that should do just fine, as SATA runs a dedicated channel to each
> drive anyway.  SCSI is a higher cost option, ruled out here, but SATA
> works very nicely, certainly so for me.
SCSI does deliver better performance, but at a prohibitive cost for "average" 
users.

> Again, a reasonable new-hardware suggestion.  When purchasing a new system
> or considering an upgrade, more memory is often the most effective
> optimization you can make (with the raid suggestion above very close to
> it).
"The only thing better than a large engine is a larger engine" ;-)
Depending on workload 4G does wonders, but again - prohibitive for the
normal user.

>  Slower CPU and more memory, u

Re: [gentoo-dev] Optimizing performance

[Patrick Lauer]

On Thu, 2005-12-15 at 14:43 +0100, Francesco Riosa wrote:
> having more than one disk or a lot of memory add very interesting
> addition, read raid 0 (stripe) or tmpfs for working data that does'nt
> need a backup fex: $PORTIR, /var/tmp ...
tmpfs has miserable performance when larger than RAM iirc - you'd need >5G for 
openoffice :-)

> I've found that preemption with the new standard 250Hz of the kernel is
> suitable for mostly needs, however no server here has preemption enabled ;-)
My system still manages to run a DVD at a load of ~8, so from my point of view 
that is not a problem
(2Ghz Athlon ... one of the "faster" machines I'd say as many people
still use ~500Mhz)

What causes more problems are packages that become slow on update - e.g.
gtk+ 2.8 is _really_ slow (takes a few seconds to redraw apps that took
<1sec with 2.6 ... :-( )
> what is a normal workload ? Define it and creating tests should not be
> so difficult, then there are apps that can help to profiling, thinking
> at bootchart, sysproof, memproof, valgrind ... strace
I guess then you'd have to split into server / desktop / ...


> reiserfs is sustainable, at least for 99.999% of uses, last reiserfs bug
> on very high load (and with degraded raid5) is dated 4 years ago here.
> However upstream is going to the route of reiser4, much more complex,
> and much more unstable, latest problems where in 2.6.14, additionally no
> devs in gentoo are (will?) support it the patch for grub it's still not
> in place I think.
reiser4 is "new and untested", I'd keep away from it until it has shown its 
reliability.
Also in my (limited) testing it is relatively slow (about the same speed
as reiser3)
 
> > Are there any application-specific tweaks (e.g. "use the prefork MPM
> > with apache2")? What is known to break things, what has usually
> > beneficial behaviour? Are there any useful benchmarks that show the
> > performance difference between different settings?
> is'n there "ab" [1] for apache testing ?
Yes, but that's apache specific and is quite hard to use correctly.
(but very nice for slashdotting simulation ;-) )

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] glep 42 (news) round six

[Patrick Lauer]

On Sun, 2005-12-18 at 09:57 -0500, Philip Webb wrote:
> > You are encouraged to reply to this thread
> > saying "I agree with ciaranm
> > that repository IDs should not be allowed to contain spaces".
> 
> No problem at all there (smile): spaces in names are A Bad Thing for Unix,
> as they conflict with the basic format of the command-line
> & were introduced by M$ (Mac ?) to make things easier for idiots.
So you're saying long filenames were invented by Microsoft for Windows
95? ;-)
As long as programmers don't assume that filenames won't have spaces I
don't see the problem

> The proper procedure for Unix-type systems is to use an underline symbol.
Which "standard" says that, and how silly is that?
We're past the 80s, there's no reason to limit filenames to alphanumeric
(as I think with the same reasoning you'd forbid unicode ...)
> > Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
> Does your brain really contain that many viruses ... ?
Only because it runs Windows ;-)
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's

[Patrick Lauer]

On Mon, 2005-12-19 at 11:44 -0800, Donnie Berkholz wrote:
> Hi all,
> 
> I know some of you have done research on how gentoo-x86 converts over to
> other systems besides CVS such as SVN, arch, etc. But I can't find the
> info anywhere in my archives.
> 
> Could whoever's got it, post it?
> 
> I'm particularly interested in hearing about CVS, SVN, mercurial,
> bazaar, darcs.
I've only tried svn with the cvs2svn script.
Importing with history took ~8h on a 500Mhz box (which surprised me
because I had heard "it takes days"). Doing checkouts caused about the
same load as cvs, but I have no data points on multi-user behaviour. 

http://www.keltia.net/EuroBSDCon/slides.pdf has some performance data on
mercurial for FreeBSD, roughly the same size as the Gentoo cvs
repositories. 

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's

[Patrick Lauer]

On Mon, 2005-12-19 at 21:23 +, Ciaran McCreesh wrote:
> On Mon, 19 Dec 2005 22:17:56 +0100 Patrick Lauer <[EMAIL PROTECTED]>
> wrote:
> | I've only tried svn with the cvs2svn script.
> | Importing with history took ~8h on a 500Mhz box (which surprised me
> | because I had heard "it takes days"). Doing checkouts caused about the
> | same load as cvs, but I have no data points on multi-user behaviour. 
> 
> The interesting part isn't really how long it takes to convert things
> or how long it takes to do a checkout, since they're in effect one time
> costs.
Yes, but generating a "realistic" workload isn't trivial.If we had cvs
logs to replay we might get some good data.
>  I'm guessing we have at least a hundred full tree updates and a
> thousand commits for every full checkout...
Provide us with a script to generate partial updates/commits and I think
many people will just run it for fun ...

Maybe the nice Infra dudes could provide cvs snapshots for testing?


Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Patrick Lauer]

On Mon, 2006-01-02 at 12:50 -0600, Lance Albertson wrote:
> A mission statement only goes so far. The underlying leadership has to
> make sure that statement is upheld and kept alive. Too many folks have a
> mission statement, but no one ever remembers what it is or abides by it.
I guess there isn't one driving force behind Gentoo - we have many 
differing opinions on things like QA, handling of bugs, ...

It's just that usually Gentoo gets the least in your way when you're
trying 
to do something :-)

> I guess I'm almost hinting at that Gentoo needs a single entity that's
> sole purpose is to drive/research the direction and goals for Gentoo.
There was this Robbins guy ... remember him? ;-)
> It'd be almost ceo-like, but the council is still top dawg. Right now, I
> view our group as a bunch of chiefs with no real single leader saying
> "lets strive to do this". The main problem is, too many people fear
> about such a person could turn into a dictator, so I'm not sure if this
> could ever happen. 
I wonder if any single person would be accepted?
After all there is noone capable of forcing anyone to do anything as far
as I can tell - worst case you fork Gentoo (again) and don't resolve
the issues.
> This person would be in constant contact of all the
> groups and try to muck together what everyone is doing. They could
> suggest things to help minimize user impact, maybe try to join two
> projects if they are both working on a similar goal, thus minimizing the
> workload. Stuff like that essentially.
Communication ... should happen anyway, but it seems to get more and
more 
difficult. Another layer of bureaucracy won't help that ...
>  We need a good visionary. If such
> a position were created, I also think that person's sole focus should be
> that focus within Gentoo. (i.e. they aren't a major contributor for a
> subproject in Gentoo). This position would take too much time for them
> to keep those other duties.
... and you'd burn out a capable person within half a year I think
> Dunno, maybe I'm the loner here thinking this...
Maybe a bit idealistic, but I mostly agree :-)

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] developer keyring?

[Patrick Lauer]

Hi all,

I'm wondering if there is an easy way to get a keyring with all
developer gpg keys pushed to users.
I know that carpaski had at one point put such a keyring online, but it
hasn't been maintained.

So right now you'd have to go through the website (fetch the keys from
the roll-call page ... if you remember where that is) and import them
one by one (time-consuming).

Any automation of that process would be really appreciated :-)
(Also it would make any mandatory ebuild signing much easier to handle
from a user p.o.v. ...)

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Patrick Lauer]

On Mon, 2006-01-02 at 20:49 +0100, Grobian wrote:
> On 02-01-2006 20:03:54 +0100, Patrick Lauer wrote:
> > On Mon, 2006-01-02 at 12:50 -0600, Lance Albertson wrote:
> > > I guess I'm almost hinting at that Gentoo needs a single entity that's
> > > sole purpose is to drive/research the direction and goals for Gentoo.
> Or call it proper hierarchy.  Management.  Probably all evil words, in
> this context, but they for sure apply.
Well ... it's like every dev has a special title - Gentoo/MIPS gcc senior 
integration specialist and stuff like that ;-)
Doesn't resolve the communication / hierarchy issues, but makes us all
feel warm and fuzzy inside.
(I know I'm a bit evil here, but ...) what I think is needed is more
communication. Not more "discussing", trolling, yelling etc. etc. but
general info. Quite some time ago I tried to get some info from all
subprojects what they had been doing - security and docs replied, then a
bit later I think Alt and Toolchain gave a short "we're not dead yet".
If all projectss could agree to deliver a "mission statement", progress
report or whatever you wish to call it every $TIMEUNIT (3 months? 6
months?) it'd be really nice ... (and would make the GWN really exciting
*nudge nudge wink wink*)

> If it isn't one person, then you would need to find two persons or even
> more that are completely aligned and have the same visions.  Since
> leaders usually are charismatic and controversial where necessary to
> achieve their goals, it is hard to find two that don't get conflicts,
> stalling any vision to become a mission.
To extrapolate from that ... council etc. are incapable of doing "real work"? 
;-)
Or in other words, a person is smart, people are dumb

> > After all there is noone capable of forcing anyone to do anything as far
> > as I can tell - worst case you fork Gentoo (again) and don't resolve
> > the issues.
> 
> ...or only resolve the ones that you care about.  Your first sentence
> forms the basis of the problem, IMHO.
There are ways to get people to do what you want, but they are quite limited.
For example for QA reasons you can make people fix their ebuilds, but
that's about the limit of influence you can have right now.

> Call it "bureaucrazy", or whatever you like.  I think it has nothing
> to do with bureaucracy at all.  It's just a matter of having
> communication on a high level, in order to get an overall view of
> Gentoo.  IIRC this is one of the tasks of the council, to align teams
> somehow, for example.
I don't know if the council is the right group to get project progress
reports collected, but the point stands - communication is good :-) 

> > ... and you'd burn out a capable person within half a year I think
> 
> Depends on the person.  Lance is just putting a lot of Mintzberg and
> probably (work) experience on the table to apply it to Gentoo.
> But ok, fine, if that's the case, gives a nice refresh rate :) (j/k)
 I say we put ciaran first to that job ... 

> > > Dunno, maybe I'm the loner here thinking this...
> 
> Well, you're not alone for sure ;)  However, the amount of measures to
> take, why and what are a bit of an open question to me.  I do, however,
> share your concerns of a missing 'Mission Statement'.  It is a commonly
> known problem and primary point of concern (ie. Heene).
I guess we should decide on a problem before solving it :-)
Is the problem the lack of a mission statement? I don't see the need for
that, we all have our own definitions what a Gentoo is and why it's
cool. Trying to get that defined will be really tricky (and I predict a
smallish flamewar)

We already have a mission statement - to produce the best software
distribution, ever ;-)
Wether it should be Linux only, GNU-based or a metadistribution is a
rather touchy subject, so please try to keep the discussion
civilized ...

wkr,
Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Patrick Lauer]

On Mon, 2006-01-02 at 15:03 -0600, Lance Albertson wrote:
> > Lance mentioned something about what he sees is a niche where Gentoo
> > does quite well.  "Produce the best software distribution, ever" sounds
> > a bit vague to me.  That's why I agree with Lance for now.  Maybe after
> > a little research, trial and error period it turns out to be better to
> > keep the target vague.
> 
> Yeah, if we're content to being a hobbyist distro, then that mission
> statement will work. But, the technology behind Gentoo has far broader
> benefits for various things. Especially with the recent work of the alt
> related subprojects, embedded, etc ... its changing. Like for me, I
> would love to use the portage technology to build packages for solaris
> machines I maintain at work.
While I do agree with you here there's still the problem that each and
every one of us has his (or her or its) own idea what "we" should do.

Some want the ricer flags and tweakability.
Others want to see one package manager to rule them all.
Then there's the "because we can" group.
The enterprise-oriented persons.

I wonder ... can we have one precise mission statement without
alienating a big part of our user base? 


>  We have a build system currently, but its
> nothing like portage. Gentoo is more than just Linux now and we should
> have goals that fit that.
I guess some people would like to disagree there. (Not me, I like that
whole "metadistribution thingy, it's the way to world domination)
>  When I say "we have a niche we're perfect at",
> I'm mainly referring to the source-based nature of our OS. There isn't
> another distro out there that does it as well as us and we should
> improve on that fact. Let the other distros get better at being
> binary-based.
Why would one prevent the other from happening? 
Maybe someone finds an elegant way for "Binary Gentoo" ... should we
stop that person because it conflicts with a weird mission statement?

-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] SLOTs and libraries

[Patrick Lauer]

Hi all,

I recently ran into an interesting problem:

One app I have seems to trigger a bug in Python 2.4, so I want to use it
with Python 2.3
But, as it imports a few python modules I can't use it - the modules
only get installed to the most recent Python version.

From a portage dependency p.o.v it is satisfied - $program needs Python
2.3 and (among others) PyCrypto, but PyCrypto is only available in
Python 2.4 and fails to import in 2.3

Now I'm wondering - is there a sane way of handling this that doesn't
forcefully remove python 2.4?
e.g. could python modules be installed to multiple python versions? How
do others (ruby, perl, ...) handle it? For the moment I've "solved" that
by package.masking python 2.4, unmerging it and rebuilding all Python
modules - less than optimal ...

Thanks,

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] SLOTs and libraries

[Patrick Lauer]

On Wed, 2006-01-04 at 09:04 -0800, Donnie Berkholz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Patrick Lauer wrote:
> | Hi all,
> |
> | I recently ran into an interesting problem:
> |
> | One app I have seems to trigger a bug in Python 2.4, so I want to use it
> | with Python 2.3
> | But, as it imports a few python modules I can't use it - the modules
> | only get installed to the most recent Python version.
> |
> | From a portage dependency p.o.v it is satisfied - $program needs Python
> | 2.3 and (among others) PyCrypto, but PyCrypto is only available in
> | Python 2.4 and fails to import in 2.3
> |
> | Now I'm wondering - is there a sane way of handling this that doesn't
> | forcefully remove python 2.4?
> | e.g. could python modules be installed to multiple python versions? How
> | do others (ruby, perl, ...) handle it? For the moment I've "solved" that
> | by package.masking python 2.4, unmerging it and rebuilding all Python
> | modules - less than optimal ...
> 
> Many programs have configure options for where the python module
> directory is, or which python version they're using. If not, move the
> files around manually in src_install().
> 
> sci-chemistry/sparky installs for python 2.3 only.
That won't solve the basic problem - how would I be able to have
programs using Python 2.3 and Python 2.4 at the same time? Also, having
to manually fiddle with the almost 60 packages depending on Python on my
system doesn't seem very useable to me ...

Still, thanks for the input,

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] SLOTs and libraries

[Patrick Lauer]

On Wed, 2006-01-04 at 09:13 -0800, Robin H. Johnson wrote:
> On Wed, Jan 04, 2006 at 05:45:22PM +0100, Patrick Lauer wrote:
> > Now I'm wondering - is there a sane way of handling this that doesn't
> > forcefully remove python 2.4?
> > e.g. could python modules be installed to multiple python versions? How
> > do others (ruby, perl, ...) handle it? For the moment I've "solved" that
> > by package.masking python 2.4, unmerging it and rebuilding all Python
> > modules - less than optimal ...
> See dev-python/validation-1.2.3 for another solution.
> It installs itself for all versions of Python that are on the system.
I don't fully understand the magic how it finds all Python versions, but can 
this be applied to other packages?
Are there reasons for not doing this (besides increasing build time)?

Also - how does portage react to "multi-installing" packages? 


Thanks,

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] RFC: regular project updates

[Patrick Lauer]

Hi all,

as the debate about the future direction of Gentoo continues it's
getting more and more obvious to me that there's a lack of information
skewing the debate. It seems that while most devs (and users) have a
good idea what's happening in "their" projects it's quite difficult to
see what is happening in other projects.

So - as GWN monkey - I'm offering my services as aggregator for project
updates. Maybe someone from the doc project wants to help to get this
information put on the website so that it's visible?

I suggest project updates every 6 months (which roughly is the same
timeframe as releases)
Maybe this helps people get a "global vision" of where Gentoo is and
where it's going.

Any feedback appreciated :-)

wkr,
Patrick 
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Patrick Lauer]

On Thu, 2006-01-05 at 09:42 -0600, Lance Albertson wrote:
> Chris Gianelloni wrote:
> 
> > Really, I don't have any vision for Gentoo and I like it that way. 
> Amazing words to come from Gentoo's release manager. We might as well
> call our releases 'maintenance updates' then if thats the case.
I guess we're at a point where many parts "just work" - I still have 
some ideas where Gentoo could be improved, but if Chris doesn't and
prefers to do some cat-herding I support him in his lack of vision ;-)

After all, without some level of QA / "managment" all those visions will
end in half-assed prototypes that almost work, but don't do much.
The mundane tasks of keeping the wheels greased so that others can
experiment around shouldn't be dismissed like that ...

> I give up on this whole thread. I was hoping people would see past the
> automatic "OMG!! We can't have a leader because it would restrict what I
> can do!" mentality. But apparently that isn't the case here.
You know as well as I do that any leader will only have a nominal
position
and most devs will just do what they want, bypassing such a person 
whenever necessary. So for now we should focus on how to coordinate our
goals - if we agree that a "leader" is needed, why not, but we should
find out if that is even needed. 
>  Yes, we
> didn't have the best experience with previous attempts at having some
> kind of a leader. And automatically thinking that it'll turn into a
> corporate bureaucratic mess is also incorrect. If you can open up your
> mind and see past those automatic assumptions and see the value it would
> be amazing.
But it's already getting too bureaucratic ;-)
It's getting more and more difficult to get things done, more and more 
people / groups / herds to wait on to decide "obvious" things.

> Anyways, as I said. I give up on this getting anywhere.
That's the spirit. (just kidding, but it is kinda funny)

I noticed that Gentoo seems to have this cycle where all 3 months or so
the same theme comes up, causes a long discussion and then goes nowhere.
And then stuff does happen - maybe it's not obvious, but we're not yet
Debian ;-)

For example - our baselayout supports UML and vServer (almost fully)
native. Most of you won't see that, but to those that do it's something
that's really nice. 

wkr,
Patrick

-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] RFC: regular project updates

[Patrick Lauer]

On Thu, 2006-01-05 at 16:41 +, Ciaran McCreesh wrote:
> On Thu, 5 Jan 2006 17:28:13 +0100 Grobian <[EMAIL PROTECTED]> wrote:
> | I'm thinking of quite dull news, so absolutely not meant to be a
> | publication like GWN, but just thingis like some commits on the
> | portage sources that say to fix/implement X, a discussion on project
> | ML Y working on Z.
> 
> Would our users really like to read a lengthy discussion on the
> intricacies of the changes made to versionator.eclass to improve
> performance, or the way in which the ten zillion packages needed by
> the new KDE/Gnome/Xorg release were keyworded for a particular arch,
> or the design decisions made for vim-spell.eclass to avoid requiring
> that our users have four gigs of RAM? I mean, it'd be pretty frickin'
> boring...
I think Fabian is targetting cross-dev communications there ...

It'd be time-consuming but sounds interesting.

There's lots of "unimportant" info, like ... say ... what fixes are in
the new baselayout? Is gcc4 safe to use? ...
Having all that in a central place (like planet.g.o, only moderated)
might help - if there is enough support! 

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Patrick Lauer]

On Thu, 2006-01-05 at 16:33 +, Ciaran McCreesh wrote:
> On Thu, 05 Jan 2006 17:20:09 +0100 Patrick Lauer <[EMAIL PROTECTED]>
> wrote:
> | It's getting more and more difficult to get things done, more and
> | more people / groups / herds to wait on to decide "obvious" things.
> 
> Hrm, it is? Seems to me that it's no worse that it used to be. It's
> just that the stalling points are in different areas.
Hmmm ... I get the impression that there are more stalling points

> As for obvious... For any problem there's at least one solution that is
> both obvious and wrong...
Exactly :-) But I guess many among us have become a bit disillusioned and 
try to stay away from what is perceived as useless trolling and silly 
infights. So things either stall in discussion or get implemented with
the "obvious" flawed approach (early webapp-config and portage are good
examples) and then take a long time to become "fixed". There's still a 
lot of good stuff happening, but as someone else said in this thread,
"we suck at execution" :-(

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Monthly Gentoo Council Reminder for January

[Patrick Lauer]

On Thu, 2006-01-05 at 23:23 -0500, Philip Webb wrote:
> After reading -- quickly -- this thread for a day or two,
> to see what Gentoo devs are thinking, I'm surprised
> anyone has been taking this rubbish seriously enough to reply at length.
> The final line suggests the writer has no serious interest in Gentoo.
I'd say the writer has an interest in Gentoo that does not fully overlap
with what has happened lately and wants to see things move
differently ...

> "Appoint one person to lead": the Germans did that back in 1933
> -- as did the French in 1799, the Russians in 1917 & the Chinese in 1949 --
dude ... like ... y'know ... the americans have one of those, too?
That was a really unneeded comment.

> & we have had a long time to reflect on the kind of thing which results.
... but still haven't learned much yet I think

> The community which achieved the most with the least in human history
> was ancient Athens, which was even less directed than Gentoo.
How about the Mongols or Turks? Atlantis? 

> Democracy ?  Consensus ?  Co-operative efforts ?  Rational discussion ?
> Apparently they are of no interest to the OP.
hmmm?
> As soon as anyone starts to order Gentoo devs to do anything,
> they will leave & not come back & the project really will die a prompt death.
> What makes it work is precisely "arguing among ourselves".
Inefficient. The collective demands to assimilate your individuality.


-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds

[Patrick Lauer]

On Fri, 2006-01-13 at 19:53 +0900, Kalin KOZHUHAROV wrote:
> > Make this distributed tool for tar zip bzip2 and gzip and I'm in, I
> > don't think it would be useful with anything else than Gigabit Ethernet.
One 2Ghz CPU can't even saturate a 100Mbit line with bzip2 as far as I
can tell.
Although the speedups won't be extreme it could just work.

> > We might want to have in the make.conf 2 separate variables, one of them
> > saying how many threads can be run on the machine, then How many
> > threads/process across a cluster.
> > 
> > For example, my Dual Xeon EM64T file server can do make -j4  locally,
> > like in make install, make docs etc etc, But for compiling I can use
> > -j20, really not useful over -j8 anyway. But the point is, it would be
> > usefully to separate the load distribution on the local machine and
> > cluster nodes.
> 
> As the discusison started...
> 
> I would like to be able to limit the -jN when there is no distcc host
> available or when compiling c++ code, otherwise my poor laptop is dead with
> -j5 compiling pwlib when the network is down
As far as I can tell distcc isn't smart enough for dynamic load balancing.
One could hack portage to "test" each server in the distcc host list and
remove missing servers for each run - doesn't look elegant to me.

> It is particular example, but being able to limit portage in some way as
> total CPU, total MEM might be interesting (just nice-ing is not enough)
Very difficult - usually gcc uses ~25M per process (small source files), but 
I've seen >100M (most larger C++ files) and heard of ~600M per process for MySQL

Limiting that is beyond the scope of portage.

wkr,
Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Eclass for prime numbers

[Patrick Lauer]

On Sun, 2006-02-12 at 18:22 +0100, Michael Hanselmann wrote:
> Hello
> 
> For an ebuild I'm working on, I need a function to test wether a number
> is a prime number. For that, I wrote an Eclass you find attached to this
> e-mail. Can this be commited?
In what range do you need the random numbers?
Your implementation uses a naive test that runs in O(n), so any large
input will cause it to take excessively long:

time primes 100 1000
real0m0.160s

time primes 1 10100
real0m7.309s

And I guess a 32-bit prime is out of reach :-)
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] FOSDEM developer (and user) meeting

[Patrick Lauer]

Hi all,

as you might have read in the GWN already we're going to be present at
FOSDEM [1] in Brussels next weekend, February 25 and 26. Sunday will
feature some talks by devs in our own devroom, Saturday will be limited
to a small booth as there aren't enough devrooms.

The talks [2] include topics like the Gentoo project structure, Release
engineering and "Towards a european Gentoo foundation" - over 25
developers from 3 continents have confirmed their presence. We will try
to videotape the talks so that they can be made available to the general
public. 

We hope that we get many interested users there to enjoy a great weekend
among geeks, nerds and hackers, fueled by lots of excellent belgian
beer, chocolate and (belgian) french fries.

Hope to see many of you there,

Patrick

P.S. If you intend to be at FOSDEM and you have a car and you wouldn't
mind driving a few of your fellow developers I'd appreciate off-list
replies - we sadly have a minor lack of automobiles among us. Many
thanks in advance!

[1] http://www.fosdem.org/2006
[2] http://www.fosdem.org/2006/index/dev_room_gentoo/schedule
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] enable UTF8 per default?

[Patrick Lauer]

Hi all,

at FOSDEM we had a nice discussion about languages, translations etc.
Having people from the US (wolf31o2) who never have problems and people
from Japan (usata) who always have problems with encodings /
charsets / ... was quite interesting.

During that discussion we realized that having utf-8 not enabled by
default and no utf8 fonts available by default causes lots of
recompilation and reconfiguration. 

Enabling the unicode useflag in the profiles should help our
international users and should not cause any problems. Are there any
known bugs / problems this would trigger? Any reasons against that?

If there are no objections this should be a small but helpful change.

On a tangent I wonder if pulling in extra fonts as a dependency of X
makes sense (useflag controlled, enabled by default) - that way the
unicode capabilities are available without any configuration.

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] enable UTF8 per default?

[Patrick Lauer]

On Tue, 2006-02-28 at 12:32 +0100, Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 28 February 2006 11:58, Patrick Lauer wrote:
> > During that discussion we realized that having utf-8 not enabled by
> > default and no utf8 fonts available by default causes lots of
> > recompilation and reconfiguration.
> At the same time, you'll probably hear people bitching about UTF-8 being 
> enabled because "it's not needed for me, should be the rest of the world to 
> change"
It is still optional, just enabled by default :-)
All the people with non-ASCII charsets will have less work, only that we
switch the load from, say, 75% of the users fixing their environment to
25% of users having to switch.

And who doesn't want UTF-8? Just being able to see a Japanese Website as
it was intended (even if I can't read it) is a nice feature.

So - apart from some users maybe not wanting it, any technical reasons
against?
 
> I'd be the first to be interested in having it enabled by default, tho.
Yes, otherwise spelling your name is almost impossible :-)

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] enable UTF8 per default?

[Patrick Lauer]

On Tue, 2006-02-28 at 13:50 +0100, Lars Weiler wrote:
> * Patrick Lauer <[EMAIL PROTECTED]> [06/02/28 11:58 +0100]:
> > Enabling the unicode useflag in the profiles should help our
> > international users and should not cause any problems. Are there any
> > known bugs / problems this would trigger? Any reasons against that?
> 
> It is enabled by default.  At least on ppc.
As far as I can tell that's not the case on x86
>   And that since,
> uhm, summer 2004?
Ok, so it should be quite well-tested.

> I can't say if there are any problems, as I didn't received
> a bug for a long time.  The only thing that's nasty: we
> don't have any good utf8-fonts for the console.
I think that's acceptable.
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

On Tue, 2006-02-28 at 14:52 +, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 10:38:17 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | You still haven't posted posted a *single example* of webapp-config
> | brokeness. You, I'd say you should either back up claims about "all
> | the ways in which webapp-config is broken" or apologize to the
> | concerned developers for false claims.
> 
> Fine. If posting a single way in which webapp-config is broken will
> make you happy, here you go:
> 
> From webapp.eclass:
> 
> function webapp_read_config ()
> {
> 
> This is a whitespace / coding style breakage. The correct format should
> be:
> 
> webapp_read_config() {
> 
> Yes, it's an utterly trivial problem, but it is a QA violation. Getting
> a complete list is something that takes a heck of a lot longer, and I
> have yet to be convinced that my time would not be better spent
> elsewhere.
Wow. That is ... impressive. After about two days of asking for any real
bugs you are able to show a trivial syntax issue?

Please stop yelling "it si teh b0rk!" if you can't even list any serious
issues, and stop being rude to other people.

Thanks,
Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

On Tue, 2006-02-28 at 15:42 +, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
> | If you can't do any better, then please apologize for your conduct
> | and false claims and shut up... TIA.
> 
> Sure I can do better. But you didn't originally ask for better, you
> asked for anything. If better's what you're after:
> 
> SLOT="${PVR}"
> 
> Now, please apologise for insinuating that I don't have any real claims
> to make. I find it extremely offensive that you're questioning my
> technical ability.
Ok, sorry for being dumb :-)
What exactly is the issue there? I don't see the issue in setting SLOT
depending on ... uhm ... some variable. Looks kinda logical at first
glance, but I'm not aware of the issues it causes.

Thanks for explaining,

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

On Tue, 2006-02-28 at 17:38 +, Ciaran McCreesh wrote:
> Sheesh, you'll probably claim that this isn't broken next too:
> 
> if [ "${IS_UPGRADE}" = "1" ] ; then
> einfo "Removing old version ${REMOVE_PKG}"
> 
> emerge -C "${REMOVE_PKG}"
> fi
Ciaran,
(and this is valid for all emails to technical lists,)
please save us some time and many emails by stating what is wrong when
you show a QA violation.
Many among us don't think in assembler and don't know enough about the
code to decide if/why something is wrong. This in turn causes someone
(like me) to send an email asking what is wrong, causing another reply
by you etc. etc.

It's a bit like me stating:
"The bug is in line 14:
i+=2
"
If you don't know the code you won't understand why.

Now if I said "line 14 increments by two, but then you won't ever get
out of the loop since the exit condition won't be met" everyone could
understand it and evaluate my statement.

If you show a wrong code snippet please explain _why_ it is wrong in the
same email.

Thanks,

Patrick

-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

On Tue, 2006-02-28 at 18:19 +, Stephen Bennett wrote:
> On Tue, 28 Feb 2006 18:59:49 +0100
> Patrick Lauer <[EMAIL PROTECTED]> wrote:
> 
> > (and this is valid for all emails to technical lists,)
> > please save us some time and many emails by stating what is wrong when
> > you show a QA violation.
> 
> This is a technical discussion list, and as such it is fair to assume
> that anyone getting involved in a discussion on a particularly topic
> knows enough about said topic to understand what is going on. If you
> can't see what's wrong with the snippet he gave, then you shouldn't be
> in the discussion, and, frankly, probably shouldn't have commit rights
> to the tree either.
Yeah, like it took me about two minutes of staring at the snippet to see
why it's evil when reading a short explanation would have made me see
that in 15 seconds. 

After all not everyone reading this list is a code ninja, please just
stop this email pingpong and (like we do it with bugs) explain what is
the issue instead of letting people guess. 

That might even teach those that are not yet super-gurus and is in
general a nice thing to do.
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

On Tue, 2006-02-28 at 16:14 -0600, Grant Goodyear wrote:
> So, back to the big issue, are there any real complaints about the QA
> team essentially formulating QA policy?  Should new QA policies instead
> follow the same rules as new global USE flags or eclasses--an e-mail to
> -dev asking for comments first?  Does QA trump, or does the maintainer
> trump when it comes to disputes?
I think the QA team is free to classify QA bugs, but any changes should
be pushed to the -dev ML just so that everyone is aware what is
happening. It's a bit, well, annoying if QA decides that we have to use
the Wrong Bracing Style in eclasses and files 50 bugs for cosmetic fixes
while there are ebuilds doing evil things, but if there's a warning
("We'll file bugs on Saturday if there are no objections to removal of
mkdir in global scope") I can live with that. Also QA should not just
decide on something without a documented explanation - it will erode
their credibility as it is seen as a random process unless there is
documentation.

In case of dispute in general QA should be stronger than a single
maintainer, but combined with the fact that QA also creates policy that
would be a bit tricky. Disputes should be escalated along the normal
devrel dispute lines I think, just think of QA as another herd/project
and that mostly makes sense :-)
QA is still new, so the communication channels might not be perfect- I
hope everybody manages to cooperate so that Gentoo is the least buggy
distro of them all when 2006.1 comes out ;-)

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

On Tue, 2006-02-28 at 22:50 +, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 23:42:34 +0100 Patrick Lauer <[EMAIL PROTECTED]>
> wrote:
> | ("We'll file bugs on Saturday if there are no objections to removal
> | of mkdir in global scope")
> 
> Eek no. Have you any idea what happens when someone shoves an mkdir in
> global scope? That one is most definitely on the list of "stuff that
> gets fixed in any way, up to and including immediate cvs rm even if it
> screws up deps for an arch" list.
> 
It seems that your sense of humor has gone missing ...
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] QA Roles v2

[Patrick Lauer]

On Thu, 2006-03-02 at 09:01 +, Stuart Herbert wrote:
[snip]
> * There's nothing in this policy about end users.  If this QA team is
> not *focused* on delivering benefit to end users, then (as has
> happened this week) it becomes a self-serving team, focused instead on
> what can only be described as a destructive path.  No-one benefits
> from that, no-one at all.
> 
> * The QA team is asking for more than it needs to perform its role. 
> The UNIX principle is that of "least privilege".  Donnie's already
> pointed out that FreeBSD is able to conduct effective QA without the
> extra power that the QA team is continuing to ask for.
So I see two scenarios for that:
- A QA team with a purely advisory function, helping with communication.
pro: no big policy changes etc.
con: teethless QA may get ignored

- A QA team with limited executive power, fixing bugs as they are found
pro: fast turnaround times on bugs
con: resistance from developers

The second approach needs to be carefully implemented, people need to
have trust in the QA team to empower them.

> * There is no proposal for a process to formulate, and gain wide
> approval for new QA standards.  This week, there's been an example of
> the QA team documenting a QA standard *after* a bug was raised about a
> QA violation ... and then that document being used as if that
> particular QA standard had always been in the document.
Communications issue. This thread should help fix the policies for that I hope.

> Mistakes will always be made by all developers, and good QA is
> essential to Gentoo's future.  We need a good QA team for Gentoo.  Not
> having a QA team is, in my eyes, not an option at all.
Fully agreed.
> But, as this week has shown, QA members are also developers (and
> human), and are just as capable of making mistakes as anyone else.
Obviously :-)
> We need a quality assurance team that conducts all its activities in a
> quality manner.  I'm not just talking about personal behaviour, or of
> any one individual.  The way *everything* is done must be in a quality
> manner.  That should mean a high quality process for creating QA
> standards, having them approved, and making sure developers know what
> changes are coming and when.  That should mean high quality automated
> tools that cope with the real world, not some ivory tower that has no
> real pay-off for users.  It should mean an interpretation and
> application of QA standards that is focused on how it improves matters
> for real users - and not a "tick in a box" QA approach.  It should
> mean a team of educators, not a team out to bully with the mandate to
> do so.
That sounds like a mission statement and should be part of QA policy

> In twelve years of being a professional software engineer, I've never
> seen a successful QA team that didn't match that description above.
> 
> Mark, in the discussions about the QA policy, your fallback
> justification always seems to be "Trust us".  I think this week's
> events have put a big dent in the credibility of that argument, if not
> holed it below the water line.  If the QA team followed processes
> similar to what I've described above, I believe that this week's
> events wouldn't have happened.  What started off as a worthy piece of
> QA work, which I'm sure has fixed many real problems for users,
> degenerated into something altogether unpleasant and unnecessary for
> all involved.  We've all gotten a week older and a week greyer out of
> this.  Have we fixed any real problems that stop our users installing
> and running Gentoo?  No, we haven't.  I hope we can all (and I include
> myself in that) learn something from this to prevent a repeat.
> 
> I call for Mark's proposed policy to be rejected as it stands.
I'd like to see it extended with the ideas shown in this thread. Also
the QA team should consider ways of getting higher acceptance - I
suggest that a general vote should be done, that's about as democratic
as we can get and noone can weasel put after that (although I'm open for
other processes to give the QA team support)

Patrick 
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] firefox-1.5.x still in ~arch

[Patrick Lauer]

On Sun, 2006-03-19 at 15:24 +0100, Matthias Langer wrote:
> I'm just curious: What is the reason that firefox-1.5.x is still in
> ~arch ?
Looking at bugreports it seems that firefox 1.5 has - at least on some systems 
- quite serious issues.

Some users report excessive memory usage, I've masked it on my system
because it was unbearably slow (multiple seconds to open a new empty
tab). As long as these issues are not reliably fixed I think firefox
should stay in ~arch


Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] who renamed adsl-start to pppoe-start and why

[Patrick Lauer]

On Fri, 2006-03-31 at 13:26 +0200, Jürgen Schinker wrote:
> how ca i make sure that i am informed earlier about such changes?

Hi Juergen,

I haven't seen this myself yet, searching on bugs.gentoo.org hasn't
shown me any known bugs.
I assume you are talking about the net-dialup/rp-pppoe package - since
you don't mention that in your email it's not easy to know what exactly
happened there. In fact, your email is one of the less helpful ways of
communicating a problem. Next time when you have a problem please try to
describe it in detail, then we don't have to guess and can help you much
better.

The gentoo-dev mailinglist is not used for "small" bug discussion, the
mail volume would be prohibitive. bugs.gentoo.org and IRC (#gentoo,
#gentoo-bugs on irc.freenode.net) are usually much better for finding
help. 

The best way to find out about changes would be reading the Changelogs
provided by all Gentoo ebuilds. Usually disruptive changes are described
there, so if you read the Changelog before updating you should be safe.
Often changes are announced in the Gentoo Weekly Newsletter, the forums
may also be useful.

Some time ago we had a discussion about the problem of getting updates
to users - you should be able to find it in the archives (dir.gmane.org
and marc.theaimsgroup.com (?) have a web-interface for just that).


Hope that helps,

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Improving Gentoo User Relations

[Patrick Lauer]

On Fri, 2006-04-07 at 11:33 +0200, Grobian wrote:
> Maybe user-rel should, together with GWN bridge this problem by keeping
> the source of news anonymous?  Just to use it as teasers of what kind of
> things are being done in Gentoo's kitchen?
> Of course this only holds for new projects like in your hypothetical
> example.
GWN has a section "Future Zone" where any Gentoo project can announce
new ideas, roadmaps or previews. It is not used that often, but if
anyone wants some testing of a pre-release version or some user feedback
on ideas ... just tell the GWN :-)


Patrick

-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] General flaming guidelines ;-)

[Patrick Lauer]

On Wed, 2006-04-26 at 15:55 -0400, Kevin wrote:
> Which is it, Chris?
You've taken that out of context ...

> Make up your mind...
I think he has, but wasn't able to communicate his ideas to you in an adequte 
way

> For all the credit that I give to the Gentoo developers, you are one
> from whom I would withdraw it.  You are merely a polarity responder and
> as such, not worth engaging any further.  You would do Gentoo a service
> by keeping your mouth shut in response to posts like mine (and many
> others I'm sure).  If I were not so self-assured, you would simply drive
> me away from Gentoo with such ugly remarks, and I've no doubt that you
> have driven away many others who are less self-assured.
Dude ... calm down. Seriously. Insulting or angering us won't help anything and 
will only make us ignore any good ideas you may have.
Your condescending tone makes me want to ignore anything you say ...

> You're in my kill file now, so don't waste your time and the bandwidth
> by responding.  All mailing lists have a topic and attempting to
> ridicule other people is not on-topic in any of them...  certainly not
> here.  It just facilitates making you look like a jerk which you need no
> assistance with.
Deliberately misunderstanding people and then yelling at them is also
not something that's on-topic for a mailinglist. 

In the last two weeks or so I've seen many users that ignore advice,
feel insulted at every turn and are not cooperative in any way. This is
frustrating and makes those of us who interact with users irritated. I
really wish we could have a level-headed discussion instead of
insulting, insinuating and trying to annoy people.

If you feel that a developer is uncooperative, that you don't get the
attention you deserve ... if you have any idea how to make things
better, send a mail to [EMAIL PROTECTED] 
Please don't take your frustrations out on developers, let us try to fix
the problem.
I hope that we can help you resolve any conflicts you may or may not
have.

wkr,
Patrick,
UserRel Monkey 
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Having fun with compression

[Patrick Lauer]

Hi all,

I had this random idea that many of our distfiles are .tar.gz while more
efficient compression methods exist. So I did some testing for fun:

We have ~15k .tar.gz in distfiles. ~6500 .tar.bz2, ~2000 others.
A short run over 477 distfiles spanning 833M gave me 586M of .tar.bz2 -
roughly 30% more efficient!
A comparison run with 7zip gave me 590M files, so bzip2 seems to be
quite good.

I don't think repackaging every .tar.gz as .tar.bz2 is a reasonable
option (breaks MD5 digests, we lose the fallback download from the
homepage), but maybe this motivates people to save bandwidth and migrate
their packaging to bzip2.

Happy hacking,

Patrick

-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Having fun with compression

[Patrick Lauer]

On Sun, 2006-04-30 at 10:30 -0700, Robin H. Johnson wrote:
> On Sun, Apr 30, 2006 at 06:30:23PM +0200, Patrick Lauer wrote:
> > We have ~15k .tar.gz in distfiles. ~6500 .tar.bz2, ~2000 others.
> > A short run over 477 distfiles spanning 833M gave me 586M of .tar.bz2 -
> > roughly 30% more efficient!
> > A comparison run with 7zip gave me 590M files, so bzip2 seems to be
> > quite good.
> Try rzip, esp. on the larger files, and see a serious improvement, with
> the cost of one major penalty [*].
> 
> * rzip cannot handle streams, it seeks across the file multiple times
>   for what it does.
> 
642M on my data set - not bad, but bzip2 seems to be better on the files
I have tested.

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Having fun with compression

[Patrick Lauer]

On Sun, 2006-04-30 at 22:36 -0500, Jon Hood wrote:
> Hey Patrick,
> I agree, tar.bz2 is the way to go when possible, but I have many
> friends on old bsd-based systems and some old linux boxes I must
> maintain that don't have bzip2 support. Normally if I know a package I
> write is going to need to go on an older system, I'll package it in both
> formats, but there are times when bz2 is just not an option.
Is that a problem in the sense "it doesn't run at all" or is it "they'd
need to install extra dependencies" ?

> That having been said, it IS an option in 95%+ of the cases I deal
> with, and for being on a cable modem, bzip2 has saved quite a bit of
> time (and money) in the past.
I just did a conversion run over all of distfiles just for fun (~10h on
an AMD64)

Input: 15634581 kB
Output: 13462050 kB
Difference: ~14%
Compared to my earlier run with ~830M this has less difference, but I
think users would appreciate a reduction of 10-30% of their downloads. 

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Having fun with compression

[Patrick Lauer]

On Tue, 2006-05-02 at 08:50 -0700, Ryan Phillips wrote:

> Patrick, 
> 
> did you benchmark CPU load?  Often bzip2 takes 3x as long to
> uncompress a package than bzip.  Often, the space savings doesn't
> justify the cost of how long it takes for the cpu to decompress the
> archive.

I did not compare CPU load. Maybe I should do that :-)

But the average user will take longer to download than to uncompress, so
my rationale for this experiment was space reduction "at all costs". The
15% average gain should outweigh CPU issues.

Also - on my test system I managed to _compress_ at 1,5MB/s. If anyone
could provide some performance numbers for slower systems  it'd be
easier to evaluate the tradeoff. 

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Re: Re: When will KDE 3.5 be marked as stable?

[Patrick Lauer]

On Fri, 2006-05-05 at 09:20 +0200, Bart Braem wrote:
> > That way, people who prefer stability over the latest features can run
> > "arch", and everyone who bitches about packages being out of date can run
> > the middle tag, and "~arch" can be kept for testing.
> 
> I really, really agree here. I know this seems like a flamewar but it is
> starting to annoy me. There are several packages that are several months
> behind the official releases. I am going to name some of them:
> Firefox 1.5: 5 months (the entire world uses it now, in stable)
broken, unstable, no good
(memleaks and horrible performance on a substantial amount of
systems ...)

> KDE 3.5.2: 1.5 months (I know our devs get prereleases, so we had this time)
~40 bugs open as Chris said. No go.

> Xorg 7: 5 months
I don't know the status on this one, but I guess it's going to be done
when it's done

Also GCC 4.x - all others are using it, right?
Well ... 4.0 was a mess, 4.1 is looking good and should be available
soon - when everything compiles with it.

> I know we have a lot of work to do, but I have some concerns. How long are
> we going to maintain old packages? KDE 3.4.3 is no longer supported by the
> KDE developpers. Firefox extensions for 1.0 are becoming extinct. 
> You are also getting a lot of work trying to fix bugs in old software. Most
> probably you are starting to backport bugfixes, is this the way we want
> things to go?
No, but if the new version is buggy it's not going to be unmasked just
because upstream would prefer that.

> I understand you don't care about how many users you have, Gentoo is not a
> bussiness. But if I try to convince users about the current situation that
> is hard. I can't explain this, I really can't. My only answer is "put it
> in /etc/portage/package.keywords". But that one is growing very fast...
So go ~x86 all the way ... it's been good enough for me for ~2 years now

I understand your frustration, I'd like Gentoo to be more "bleeding
edge" as it used to be, but then I have an install that was originally
1.2 (I think, might have been 1.4rc) that was updated and recompiled
every now and then - that's really awesome, I don't know of any other
distro that offers such good migration paths.

Just my 2 cents,

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] RFC: etiquette enforcement

[Patrick Lauer]

On Thu, 2006-05-18 at 14:54 -0500, Mike Doty wrote:

> Developer relations has started a discussion about how to handle
> etiquette problems on public communication channels.  The discussion is
> currently taking place on the gentoo-devrel mailing list.  This list is
> public and we appreciate anyone who has constructive input to provide.
> 
> If you don't want to participate in the discussion but still want to
> follow it, the gentoo-devrel ML is archived at
> http://dir.gmane.org/gmane.linux.gentoo.devrel

I like the idea. While I'm not sure it can be implemented in a fair and
sane fashion I hope y'all can find a policy that helps to improve
communication.

Thanks for your efforts,

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

Hello all,

I flood you again with a long email. Apologies to all that don't
want to read so much, but it is a problem of rather high importance that
has not really been fixed, and the first discussions happened in 2003 as
far as I can tell. Time to FIX IT!!!

The problem, in short, is how to handle the checksumming and signing of
gentoo-provided files so that manipulation by external entities becomes
difficult. I expect many disagreements on the "best" strategy to
implement, but I hope that a sensible compromise will be reached so that
this can finally be implemented.

All the lazy people may stop reading here ;-)

Short overview:
The Problem
The Attacker
Defending
Policies and open problems



The Problem:


A malicious person could modify the files provided by Gentoo to 
manipulate and take over the computers of Gentoo users. To avoid such 
problems all files provided and used by Gentoo need to be identifiable 
as "correct" - we need integrity checks.

An attacker should not be able to easily circumvent these checks. There 
are some attacks that can't be prevented, so we also have to see the 
practical limits of any scheme we define - for example an attacker
could 
be a Gentoo dev with full access to all ressources, stopping that
person 
will be more difficult (if not impossible) than stopping a random
script 
kiddie that hax0rs a distfile mirror with a 0-day exploit.

The files
=

There are two groups of files at the moment that need to be secured:
- distfiles: The large archives of source code and binary blobs from 
which we install a package
- "the tree": metadata, ebuilds and patches containing all the 
information to manage the local software installation.

The default distribution methods are rsync for the tree and http/ftp
for 
distfiles. As there are too many users for a single server theservers
are 
provided by external contributors and are not directly controlled by 
Gentoo. In almost all cases a fallback to the original download
location 
of a file is provided.

The Attacker


Any security policy has to take into account how strong an attacker is. 
For example securing against your grandmother with checksums signed by 
multiple independent persons is most likely overkill. A simple checksum 
would most likely be enough there.
On the other end of the spectrum we have aliens that can crack any 
encryption scheme in roughly two minutes, obviously we can't do
anything 
to really stop them.

What attackers are then reasonable?
- the script kiddie that takes over one single mirror
- a large multinational monopolist that tries to sabotage any potential 
competitors
- a mirror operator that has a bad days and manipulates files for fun
- a really strong hax0r that takes over the Gentoo CVS server
- a social hacker that takes a dev hostage and forces that dev to
insert 
evil bad data

This is by far not a complete list, it should only help with figuring 
out what can go wrong.

Now let's classify the attackers:
* local attacker ("your roommate") - nothing we can defend against,
your 
responsability.
* single compromised mirror - only with checksums can this be found. If 
the checksums are distributed on a different path than the distfiles 
a single compromised mirror has a very low impact as checksums don't 
match.
* compromised rsync mirror - now the checksums can be forged. The 
attacker will have to change the SRC_URI too so that only the 
compromised distfiles are transferred. Also changes in the ebuilds must 
be considered - a "rm -rf" in the right place in an ebuild will have a 
large impact and can't be caught with checksums (since those could be 
forged by the same attacker). We need signed checksums here.
* compromised developer - this is hard to detect, but once detected all 
files involved can be checked and corrected. The impact of this is very 
high, it is very difficult to avoid. (So we just assume that no dev
will 
go berserk and look for low-impact methods that allow us to clean up if 
that ever happens)

Note: a possible defense against rogue devs would be multi-signing, i.e.
having all commits checked by at least one other person. This does not
help much as there can be collusion between devs and the impact on all
devs is very high. It would effectively deadlock Gentoo and prevent any
useful progress.

Defense methods
===

1) Checksums
A Checksum is a one-way function that returns a constant-length 
identifier. The checksum is designed so that changing one bit in the 
input totally changes the output (quite simplified, but that's all that 
matters). Thus any changes to a file lead to a bad checksum, finding a 
collision (two files with the same checksum) is hard.
Some checksum algorithms have known weaknesses, so relying on a single 
algorithm is not advised. For example MD5 suffers from precomputation 
attacks where one can generate two files with equal checksums (but it
is 
not possible to find a matching second file to a given file).

Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

On Fri, 2006-05-19 at 10:46 +0100, Chris Bainbridge wrote:
> The only attack most people really care about is a compromised rsync
> server. There is no practical way to protect against the other attacks
> - and at the end of the day, if a developer gets compromised it
> doesn't matter whether it's a gpg key or ssh key, the effect is the
> same. 
The difference is how you handle any problems. You can't avoid it, but
you can reduce the impact.

> The discussion about which files to sign is pointless - the extra
> computational cost of signing all files in the tree is insignificant,
> and how are we supposed to know how future tools will handle things
> like the licenses? Just do it properly now and sign every file. 
In theory yes.
Practically you have to find a non-intrusive way so signatures are per
file.
There are potential problems with "special" files like package.mask that
will be modified often by different people ... signing that is a bit
silly

> We already trust the master cvs server admins (and they could just
> replace the whole tree anyway), so what benefit does a distributed
> signing system like gpg actually give to the developers or users? I
> can't see any that are worth the costs of key management (and there
> are costs, otherwise a system would've been put into place years
> ago). 
No central authority --> no single point of failure

Give me a central server and I will focus on hacking that ... hacking 50
developers is much harder ;-)

> So my simple proposal would be to use a single key, and a post-commit
> cvs hook to sign the whole tree. It takes me 1.5 seconds with gnupg to
> generate a signature covering the whole tree on my desktop here. I
> don't know how many commits per day there are (and maybe that would be
> reduced with an atomic commit system like svn), so I don't know if
> this is an acceptable cost. I think it probably is, but if not, then
> signing could be done per-directory. 
I don't see what that gains you ... what exactly does this signature
express?
and 1.5sec doesn't appear realistic to me, I'd expect it to take ~1
minute even on a fast system

> The benefits of this would be that changes are minimised - developers
> and users act the same, the impact on the tree is a 191 byte
> signature, and yet it will protect against the most likely and most
> practical form of attack. 
So ... DoS scenario
I just add one byte to the tree and the signature fails ... what then? 

> I was much more pro-distributed trust system in 2003 (or whenever this
> was last discussed), but I think the right solution now is the
> practical, easy to implement one.
I think I'd prefer a hybrid.

One possibillity would be:
- every dev signs as it is done now
- post commit an automated signature from a master key is added

so the normal user can check the master signature, and the paranoid
people can use the per-dev keys.

Where I fully agree is "practical" and "low impact" - it should be easy
to use so that everyone can use it without lots of configuring. This of
course limits the complexity that we can allow.


wkr,
 Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

On Fri, 2006-05-19 at 15:13 +0100, Chris Bainbridge wrote:
> There are now several hundred gentoo developers. It is more likely
> that one of them has a security lapse than cvs.gentoo.org.
One is a "local" bug, the other one "global".
I'd prefer a system that is resilient against two devs going crazy -
right now the "right" persons could stage a manipulation that would be
hard to detect and where your (single central) signature fails quite
nicely.

> It is a single signature across the entire portage tree. It means that
> after rsync emerge can check the signature against the retrieved tree
> to validate the whole tree (or overlay).
It's very coarse - Yes / No
Doesn't tell you what failed how ... so I DoS it by inserting one bit on
any rsync mirror and it will "fail". You don't know what fails where ...

> Instead of guessing performance, test it. We can assume that disk
> activity is negligible  - we have a dedicated server, and the portage
> tree is ~115MB, so most of it will be cached in main memory. In
> particular there is no disk seek latency. To simulate that we can
> gather everything into a single file (which also has the side effect
> of pulling into the cache) and then gpg sign that file:
> 
> find /usr/portage -path '/usr/portage/metadata' -prune -o -path
> '/usr/portage/distfiles' -prune -o -path '/usr/portage/packages'
> -prune -o -type f -exec cat {} > /tmp/blah \;
> time gpg --detach-sign -a /tmp/blah
> 
> I get 1.5 seconds on a desktop and 6.5 seconds on a laptop.
ok

> > > The benefits of this would be that changes are minimised - developers
> > > and users act the same, the impact on the tree is a 191 byte
> > > signature, and yet it will protect against the most likely and most
> > > practical form of attack.
> > So ... DoS scenario
> > I just add one byte to the tree and the signature fails ... what then?
> 
> Emerge informs the user that the rsync server has been corrupted and
> terminates. How would this be any different with distributed file
> signing?
You can't upgrade and you don't know what fails where ...

>  You have to rsync the entire tree, and then verify it - at
> that point the tree is already corrupt. Ideally overlayfs (or just
> plain old keeping a backup) could be used to restore the pre-sync
> tree.
Right, but ... what caused the error?

> It could be done in stages. Start with the (easier) central key, then
> later add distributed keys. I think a hybrid system would be the ideal
> system, but realistically, bug #5902 has been around since March 2003
> and no real progress has been made.
That bug appears quite unrelated to me ... how does FEATURES="userpriv"
relate to signing?

>  The main sticking point seems to
> be disagreements over key management and policies. I would hope that
> most people could agree that a single key with a post-commit signing
> is better than what we have now, 
debatable
> and could be easily implemented,
yes
> whilst leaving open the option of a hybrid system implementation at a
> later date.
yes

but that's not a cure. You'd have to sign _each file_ to get a
reasonable tampering detection, or at least per-directory. You add a
single point of failure and give attackers a high-profile target.

It's like security checks at the airport: It gives you the illusion of
security, it inconveniences everybody ... and it's easier for me to
smuggle a bomb aboard because noone thinks it's possible. (It's easy,
use a sidechannel attack on the baggage transports, they have bad
security ...)

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

On Fri, 2006-05-19 at 22:03 -0400, Ned Ludd wrote:
> If there is anything you or genone need to make signing happening you
> have to the full support of the 

> council
That should not be difficult if the proposal is discussed and accepted
by all other groups

> infra
it should be non-invasive and well documented

> hardened/security.
... while offering good security

So I suggest that infra and hardened/security warn of any problems they
see, it would be silly to have a detailed battleplan only to have
someone kill it at the last minute ...

=

Some short comments on robbat2's proposal:
> > Summary:
> > ---
> > This is a brief summary of the suggestions and choices above.
> > This summary outline is assuming a model such as the hybrid or complex
> > models.
> > 
> > - Each developer shall have a GnuPG key.
> > - Each developer key shall contain at least one uid, with name and Gentoo 
> > email
> >   address of the developer.
> > - Each developer must create a secondary cryptokey with the following
> >   parameters (designated as their Gentoo signing cryptokey):
> >   Key Type: RSA
> >   Key Length: 2048 or 4096
> >   Expiry time: Set at 6 months out
> >   Usage: Marked as signing only.
I think these parameters are acceptable. I can't think of compelling
technical reasons to change them.

> > - Each developer shall regularly update the expiry time (GnuPG enforces
> >   this) of the cryptokey, keeping it no further than 6 months ahead of
> >   the present date, except where otherwise decided.
Enforcing this will be difficult, so I think it should be seen as a
strong guideline (we can't stop you, but please don't mess up)

> > - Each developer should have a revocation certificate for their key, and
> >   store two copies in a secure offline location (I suggest two CD-RWs,
> >   of different brands, stored in separate locations, refreshed every 6
> >   months, but floppy disks would work as well).
No way to enforce this

> > - Each developer will sign all of their commits with their Gentoo
> >   signing cryptokey only. They should not sign anything else, nor use
> >   other cryptokeys for signing Gentoo commits.
> > - (Optional, for those creating new keys only) a best practice would be
> >   to have a primary key that is marked as certifying only.
Sounds reasonable
 
> > (This part here needs more discussion, which may end up that N=1 is
> > valid).
> > - There will be N master keys. 
For N>1: who controls the master keys?

> > - A master key will have a secondary cryptokey conforming to the same
> >   requirements as the developer Gentoo signing cryptokey.
> > - A master key will certify all Gentoo developer keys on a regular
> >   basis. This can be done on 4 month intervals safely, with once-off
> >   events to sign keys of incoming developers, or other special cases.
Why not sync this to the 6 month expiry time?
Also you might want to add:
- All keys and the master key shall be made available on Gentoo media
(install-cd etc) and other ressources (ebuilds, download from known
locations, stored on public keyservers)

> > - When a developer leaves, the certification on their key shall be
> >   revoked.
> > - Both infra and the council should hold the revocation control for a
> >   master key in some way so that cooperation is needed to actually revoke
> >   a master key.
This will be very tricky to implement. 
> > (For future stuff:)
> > For performing releases of Gentoo (releng), a designated key be used,
> > and be certified by the master key.
This should be discussed with releng. While I don't see why they should
disagree I dislike forcing any policy on others.
 
> > Outstanding points:
> > ---
> > - Discussion of how the keymaster(s) should operate to maintain the
> >   keyring.
Plus, of course, what to sign, how to sign it, how to handle failures.

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Signing everything, for fun and for profit

[Patrick Lauer]

On Sat, 2006-05-20 at 10:13 +0200, Thierry Carrez wrote:
> Patrick Lauer wrote:
> 
> > Signing strategies
> > ==
> > 
> > Once there is an agreement on what files to sign with what kind of keys
> > there remains the question how to sign it. There are at least three
> > strategies:
> > [...]
> 
> I prefer a semi-secure solution appearing soon rather than waiting
> another three+ years for a potentially better solution.
A staged plan might be best then:
- implement a simple master-key signing
- discuss the more complex distributed models
- implement the distributed models if agreed upon

> Currently users only have two choices :
> 
> - masterkey-signed portage snapshots
> - unsigned (and so, insecure) rsync mirrors
> 
> This is obviously not satisfying.
Yes. It also gives us ~100 single points of attacks as every compromised rsync 
mirror could go undetected for a long time.

> It has taken years to try to get per-developer signing implemented,
> without success. We should try to do masterkey signing ("simple" method)
> and see if we go somewhere. It's is so much better than nothing.
There is no authority that "forces" signing.
Making signing mandatory should not cause big problems now ...

> So I would rather work on ensuring everything in portage gets properly
> signed rather than designing key policies, cross-signing strategies and
> ways to force developers to sign properly. Given the current state of
> Gentoo it is a much more reachable goal.
"properly signed" implies some standard or policy to measure it against.

So we need to have some agreement what is needed to assure "properly
signed everything" - it looks like the centralized masterkey model will
have the smallest impact on all involved. Then we look at all issues
this model has, try to fix all bugs - then we have a plan to implement,
and I hope that this will happen in a reasonable timeframe.

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Patrick Lauer]

On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote:
> > You don't need a subversion client, you perhaps notice the http in front
> > of the url.. just open it up in your browser and you get the source
> > immediately.
> 
> Umm... so now I need to go and instead of clicking a nice link in
> bugzilla, trawl through the subversion repository and find what I'm
> looking for?  How exactly is downloading things via http any different
> than downloading them from bugzilla, which is also http?
just my point of view - 

bugzilla sucks. Ever had to download 10 attachments for one ebuild?
It is a good tool for discussion, but I would prefer a simple tool (like
layman) that can automatically update things. You obviously don't like
overlays, but that shouldn't be a reason to stop us from using it. 

> > Or, if you want some history like sources.g.o, you can do so as well here:
> > http://overlays.gentoo.org/proj/sunrise/browser/
> 
> Excellent.  So we're moving the history from being in a single location
> (the bug) to being in multiple locations.  That will definitely improve
> the development process.  
Yes, now it is easier to check out the ebuilds. More users ==> better
testing.
;-)

>   No offense, but everything I have seen looks
> as if it will add even *more* overhead to actually getting packages into
> the tree.  The only thing this seems to provide is a half-baked
> repository for the users to get marginally-tested ebuilds for software
> that wasn't interesting enough for inclusion in the tree.
That differs from the 20 or so overlays maintained by users how?
Honestly I'd prefer an overlay where I can marginally trust the content
over a "foreign" repository maintained by people I don't know.
And the quality of some of the overlays ... better have that supervised
by devs, they should know how to handle b0rkage.

> > > Except that I can *look* at an ebuild without having to break out a
> > > subversion client currently.
> > See my answer in 3)
> See mine.  ;]
Hmmm ... bugzilla.
Instead of a simple cvs up; cd /usr/local/portage/category/package I
need to search for ALL bugs with $name in it, look which one it is,
curse bugzilla for falling asleep again, see which attachments are
relevant, download them, curse bugzilla for falling asleep again, copy
them to my overlay, read the bugcomments to see if any special renaming
or directory structure is needed ...

Hmmm. I think an overlay does have some advantages there ...

> 
> Again, read what I wrote.  I said that the developer would see "sunrise"
> in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated
> without considering.  This is a login bug.  At no point did they make
> mention of having installed pam_skey from this overlay.  This means that
> I, as the developer getting this bug, am now responsible for looking at
> *every package* in the sunrise overlay to determine if *any* of them
> could *possibly* be affecting this package or causing this bug, then
> asking the user if they have any of them installed.
This differs from a manually patched ebuild in /usr/portage by virtue of 
showing you that an overlay is used ...

> Wouldn't this process be *infinitely* easier if instead of "sunrise"
> there was a "pam" overlay with *only* the pam stuff?
Ooooh, cool. Now I need about 75 overlays to get things done, and of course 
there will be no bad interaction between them ;-)

Having one overlay with a focus on not-in-portage ebuilds should not
cause the scenario you described and will most likely cause less weird
bugs because of intra-overlay dependencies.


> That is *exactly* what we get with the other overlays like php and
> vmware.  I *know* that if I'm looking at a glibc bug and the user has
> "php" as an overlay, that it isn't going to be a concern.
... and if we control the overlay we can exclude things like system
packages easily.
Could be part of the policy to not touch existing ebuilds.

> This is a prime example of totally glossing over any discussion to make
> it sound promising for you. 
If bugzilla wasn't so sucky people wouldn't try to use other methods of
communication ;-)

And again, one svn repo vs. 113 hard-to-find bugs ...

>  Even better, if I am the proxy
> maintainer for a particular set of ebuilds for one or more
> user/maintainers, why do I need it in your big, bloated, and completely
> inappropriately-named "sunshine" overlay versus a developer overlay of
> my own?  
You don't. Please use your developer overlay. Please don't try to take
away our more open overlay.

> After all, I am the *only* proxy maintainer.  Why should there
> be the added *insecurity* of allowing any number of people that *I*
> might not trust complete access to the small number of packages where I
> am the proxy?
It's your choice. Either you get mailbombed with each minor version update or 
you trust them to not screw up with the sunrise overlay.

And the users could just create their own overlay, get it added to
layman and we'd have the same wit

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Patrick Lauer]

On Fri, 2006-06-09 at 12:20 -0400, Chris Gianelloni wrote:
> > bugzilla sucks. Ever had to download 10 attachments for one ebuild?
> > It is a good tool for discussion, but I would prefer a simple tool (like
> > layman) that can automatically update things. You obviously don't like
> > overlays, but that shouldn't be a reason to stop us from using it. 
> 
> Well, I thank you for your vast experience as an ebuild developer in
> this matter.

My pleasure. I'd rather see myself as poweruser in this regard since I
try not to break too many ebuilds ...

> You do realize that this isn't one of those things where you can say
> that if you don't like it you don't have to use it, right?
>
> This *will* affect *every* ebuild developer.
Maybe you don't realize that taking ebuilds for packages that are _not in 
portage_ and providing them in a nice bundle does not affect every developer?
Noone wants to push a new cvs-snapshot of glibc. That so not the point
here.

But having a controlled managed overlay with ebuilds that are now spread
all across bugzilla ... that would be a good service to our users.

> This means it *CANNOT* be left up to a small group of developers to
> decide without any discussion on the matter.
So now we're a democracy where everything needs to be voted upon?
*sigh*
Let's leave that debate for another day ...

> > Yes, now it is easier to check out the ebuilds. More users ==> better
> > testing.
> 
> Except that now the developer has to do much more work to get the same
> information, making it even less likely that he'll bother to pick up one
> of these maintainer-wanted bugs.  
s/the developer/I/
there are some devs that would prefer this overlay environment.
Please don't push your personal preferences as The Right Way (tm)

> You also completely gloss over the
> ability of a single rogue user to now compromise countless users with a
> single commit.
And an ebuild on bugzilla has more security?
We're just making it easier to use these ebuilds. Also I expect the
maintainers to keep a reasonable quality standard.  
>   Please come back once you've firmly grounded yourself in
> the reality that we're a pretty popular distribution, and that makes
> this project a prime target for malicious abuse.  Perhaps if you were
> responsible for some ebuilds, you've be more cognizant of the
> implications that a bad commit can cause our users.
I am not responsible for ebuilds because I don't trust myself enough :-)
That doesn't stop me from giving out access to my server to anyone who
has a good reason ... like the Gentoo/HURD repository or the Java
overlay. 

> > That differs from the 20 or so overlays maintained by users how?
> 
> Let's see.  They aren't on Gentoo infrastructure, which means they don't
> give off any immediate assumption of being "official" or "supported" in
> any way.  Hell, go back and look at Peter's response about how he would
> use an overlay such as this only *because* it is on Gentoo
> infrastructure.
> 
> So what exactly was your counter-point again?
We have control over sunrise. And hey, if it sucks kill the project with silver 
bullets, a stake to the heart and two pounds of garlic.
Just don't kill an idea before it is even tested ...

> Having an overlay such as this will tarnish Gentoo's reputation.
No :-)
What reputation are we talking about? The distro that lags in updates
behind others?
Where you see a problem I see potential: More well-tested ebuilds,
recruiting potential developers ... if you don't want that you're an
elitist bastard. ;-)

>   We
> should not be providing *anything* that is only half-supported or
> half-tested.  Anything less than being sully supported via the security
> team and QA is a failure on the part of Gentoo.  We have enough *crap*
> in the *tree* that is unsupported, which makes us look bad, yet you want
> to insist on supporting a project that affects all of the ebuild
> developers, which you have not mentioned is a group which you are not a
> part of, so can gladly speak of increasing their workload with no
> consequences to yourself, and provides an avenue for low-quality or
> possibly malicious ebuilds to be distributed to our users, all under a
> Gentoo banner?
No :-)
1) It doesn't increase your workload - these packages are things that
are _not_ in the main tree.
No overlap --> no stupid bugs with overwritten ebuilds etc.
2) low-quality? I might mention that I'm hosting some overlays that have
non-gentoo contributors (*gasp!*)
Why are they hosted on my server? Because the contributors are not (yet)
gentoo devs, but provide good to excellent input to the projects. So now
you tell me that I'm doing wrong in helping Gentoo development? These
people can't contribute to other gentoo-hosted projects, so it is easier
to move the repositories to a more liberal server. 

That tells me that Gentoo development is fundamentally buggy when we
complain about a lack of manpower and then say "yeah, but not _that_
kind of manpower" when users try to help.

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Patrick Lauer]

On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:
[snip]
> > If someone wanted to exploit boxen he'd use a much simpler attack
> > vector ... our rsync mirrors are wide open. No need to secure the little
> > window over there when the front door is open ...
> 
> Really?  I'd like you to give me root on rsync.gentoo.org, then.  What's
> that?  You can't?  What a wonder!

I don't need that ...
Look, three-step plan to hacking Gentoo boxen:

1) open a few rsync mirrors and get them into the official rotation
2) replace ebuilds on the server with your preferred rootkit installer
3) harvest all the zombies you just got 

Since not all ebuilds are signed and signing is not enforced portage
will not throw any errors if I take care  of a few things (fixing
manifests etc.). So any person running an rsync mirror has implicitly
the same level of trust as a dev.  

As for the rest of your email, I'd appreciate it if you didn't take this
so personal. There's no need to belittle or insult others to push your
agenda, it should stand on its own technical merits. 

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Project Sunrise thread -- a try of clarification

[Patrick Lauer]

On Fri, 2006-06-09 at 16:14 -0400, Chris Gianelloni wrote:

> Since when was overlays.gentoo.org supposed to even be a service to our
> users?  As I understand it, the goal was to ease development, not to
> provide an easy method for half-working ebuilds to make it to our user's
> machines.

What's the point of development if not to help users? 
Everything we do should be done to help users (and worst case we help
that small group of users that are devs). 

> > > This means it *CANNOT* be left up to a small group of developers to
> > > decide without any discussion on the matter.
> > So now we're a democracy where everything needs to be voted upon?
> 
> Anything this abhorrently stupid doesn't need a vote. 
Bullshit.
If you need to resort to insults you failed to show on a technical level
why it is bad.

>  It should be cast
> out on its complete lack of merit, alone.  Also, at no point did I ever
> ask for a vote.  Don't put words in my mouth and I'll try to pretend
> like I care what you say, OK?
So now you're El Cheffe? 

And please, stop sounding like my father. 


> > *sigh*
> > Let's leave that debate for another day ...
> 
> You brought it up, not I.  Feel free to debate it with yourself until
> you're blue in the face.
I debated it for about 27 seconds, seems quite obvious now. Thanks for
the hint.

> > > > Yes, now it is easier to check out the ebuilds. More users ==> better
> > > > testing.
> > > 
> > > Except that now the developer has to do much more work to get the same
> > > information, making it even less likely that he'll bother to pick up one
> > > of these maintainer-wanted bugs.  
> > s/the developer/I/
> 
> You're right... I had that wrong.
> 
> s/the developer/the developers/
> 
> After all, there have been quite a number of people agreeing with me.

That's a non sequitur.
There's also quite a number of people agreeing with me, but that doesn't
make any point of view better or more thruthful. So either we try to
discuss in the hope of finding a compromise or we do a headcount and do
something stupid. I'd prefer a discussion, but if you just want to HULK
SMASH SUNRISE I won't stop you.

> > there are some devs that would prefer this overlay environment.
> > Please don't push your personal preferences as The Right Way (tm)
> 
> Ehh.  Were you an ebuild developer, your opinion might actually count
> for something when it comes to an ebuild development discussion.  By the
> way, where's the GWN this week?
Ulrich is MIA, nothing I can change. He does that from time to time.

> I'm glad your faith in them is so high.  My faith in *any* group this
> small having the ability to watch over a large number of outside
> contributors simply isn't there.
Let it grow. Slowly. 
Either it stands on its own or it dies from lack of interest.

> > That doesn't stop me from giving out access to my server to anyone who
> > has a good reason ... like the Gentoo/HURD repository or the Java
> > overlay.
> Well, we thank you for your immense self-sacrifice.  What this has to do
> with the topic at hand, I have no idea.
Well ... think about it. It's kinda obvious once you grok it.


> > Just don't kill an idea before it is even tested ...
> Why not?  What reason is there to stop me from aborting this brain-dead
> monstrosity before it claims a single user casualty, let alone our
> reputation?  I would have thought that your involvement in "PR" would
> have you thinking better.  A reputation is something that takes years to
> establish, and seconds to demolish.  You, of all people, should know
> that.
Yes. But killing an idea like this seems almost as damaging to me.

There's a group of devs thinking "Hey, how can we make things better?".
They come up with a few ideas, throw away those that are just not
feasible. Then they have one idea that looks useful, they try to
implement it. So either you convince those people (with whom I am only
tangentially involved) that it is a bad idea or you let them do their
thing.

I think what is more damaging to the reputation of Gentoo is the
incessant discussion of ideas before they are even tried, killing many
good things before they even have a chance on a technical level. 

> Yes, we are *so* lagged behind everyone else.  Where do you come up with
> these "facts" anyway?  I'd like to visit this mythical land.
Like, gcc 4 ? Gentoo is lagging behind most others (because our QA has grown 
from non-existant to really really good)

Sidenote: I don't mind that at all. But I see a split here ... one group going 
the debian route of making everything really really stable.
And the other group that doesn't mind mild b0rkage, but wants to be on
the bleeding edge.

Those two populations will be hard to reconcile. Give the second group a
sandbox and the first group can do their thing much easier ...
 
> > Where you see a problem I see potential: More well-tested ebuilds,
> > recruiting potential developers ... if you don't want that you're an
> > elitist bastard. ;-)
> 
> Aww, how sweet

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Patrick Lauer]

On Sat, 2006-06-10 at 03:28 +0100, Christel Dahlskjaer wrote:
> I would like to ask that the Council discuss the current state and
> future of the GWN at their next meeting.
I don't think you have to escalate that far. We should be able to discuss 
things without the thermonuclear option ;-)

> 1. Reliability. The GWN claims to be a weekly publication, yet it
> frequently fails to publish without prior warning. There was no edition
> this week, and Patrick Lauer says that it is "unknown" whether there
> will be an edition next week as Ulrich Plate is AWOL.
We have tried to get a backup structure working, Halcy0n for example 
offered to help. Ulrich never responded to these offers. He usually has 
a good reason for not doing the GWN (like no Internet access, broken notebook 
etc), but I also find this quite unsatisfactory.

> 2. Permissions. Although it could be considered flattering that the GWN
> should choose a developer's blog as inspiration for an article, they
> should ensure that they have the developer / author's permission before
> quoting them (see previous complaints by brix, ciaranm and others).
As far as I'm aware this has been taken care of. But with the GWN quite 
understaffed it is not easy to get everything done well.
I'd appreciate some more support from others, but sadly my recruiting
experiments usually ended after one contribution (for example summary of
the -user ML).

> I also believe that when posting an article or interview, a copy should
> be sent to the relevant people to ensure that they are ok with what is
> being posted (my dev of the week interview, for example, was rather
> screwed up and misrepresentative).
My fault. 

>  When someone contacts GWN to have
> something corrected, it would be appreciated were the GWN staff to at
> least deign to acknowledge receipt, even if for some reason they choose
> not to honour the corrections or post a retraction (although refusing to
> publish corrections is extremely insulting to those wronged).
The reason for that is that the GWN is mostly sent out by mail. This 
makes corrections a bit more difficult, but I think having a sane policy 
for that would be helpful.

> 3. Misinformation, misquotations and outright fabrications. Sure,
> there's freedom of the press, but that shouldn't be used as an excuse
> for deliberately making up quotes and printing intentional
> misinformation.
I don't know what exactly you are talking about here. But it shouldn't happen.

> 4. Credit. Care should be taken to ensure that crrect credit is given.
Yes. 

> From a PR perspective, Gentoo could benefit greatly by better
> utilisation of the GWN. I believe that as it stands, however, the GWN is
> discouraging people from contributing and damaging Gentoo's credibility.
The problem with the GWN is the lack of reliable useful contributions.
There was a time when the GWN was ~80% written by me, but that took more
time than I could afford in the last weeks.

> Another thing that concerns me is the way the articles are written. It
> is blatanly obvious that the GWN writers are not native English speakers
> as both the grammar and the flow of the articles is far from attractive.
Help is appreciated :-)
The GWN has become a german thing, we have jokingly discussed writing it
in german and letting someone translate it to english.

> Having read through the archives, I notice that there was once a time
> when the GWN was a great publication, and I would like to think that it
> could become great yet again; in its current state, though, it is doing
> more harm than good.
Agreed.

> Lack of content and poorly written or incorrect articles are often
> justified by the GWN team on grounds of overwork and insufficient
> manpower. When I asked why they were not recruiting, I was informed that
> no-one has any interest in contributing.
There's a big difference between one-off articles and continuous
contribution. Also those that I found most willing to contribute had the
biggest language problems - what we need is support from the native
speakers.

>  Upon speaking with others,
> however, I find that this is not the case -- people are interested, but
> fear (and rightly so) that their work will be edited in such a way that
> it is no longer something with which they want to be associated.
> 
> Another complaint is that the GWN rejects any writing style which has
> any degree of character or levity. Any attempt at dececnt writing (the
> kind that would make it into publication in English newspapers or
> magazines, for example), is met with the claim that "the GWN is not a
> humorous publication".
Blame the flamefests of the past. Whenever attempts were made to give
the GWN more dynamic it was flamed down (because ze german humor is not
funny! Nein! ;-) )
So 

Re: [gentoo-dev] July Council Meeting: Requested Agenda Item

[Patrick Lauer]

On Sat, 2006-06-10 at 11:37 -0400, Alec Warner wrote:
> Have the GWN posted to -core in a sane time period prior to it's 
> release.  I seriously doubt anyone cares about whether the publication 
> is always "on time" (whatever that may be). 
So what would a sane time period be? 12h? 24h?
The problem with that is that you need an editor who is available during
this period to add corrections, but with the new influx of helpers I
think we can manage.

>  If it's a bi-weekly 
> publication it doesn't always have to go out on the same day, as long as 
> you get it out in the general time period.
Well ... it is easier when you work with a schedule. Missing a
"deadline" may happen, but that should not be the usual behaviour.
bi-weekly is "silly" because you forget which week it is and suddenly
you skip another week by accident ... I prefer to keep it weekly. And
looking at the flood of material we have for the next edition I think it
is sustainable.

>   I sometimes respond with 
> corrections/additions but they never make it because it is released 
> before my mail is sent.  Often when I see the core mail I don't even 
> bother reading it since by looking at the timestamp I can guess it's 
> already been mailed.
Hmmm. That looks like a timing problem - the GWN gets created on
european time!
I think we should try to have a bigger delay between draft and
publication, but I'm not sure how to do it best. Maybe shift the draft
to saturday  and push the final version on sunday?


Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] GWN Comments

[Patrick Lauer]

On Mon, 2006-06-19 at 07:37 -0400, Caleb Tennis wrote:
> I'd like to propose some form of ability to post user comments to GWN
> stories.  I suppose a full blown CMS system would work,
(Ab)using a blog for that might work

>  but for the ease
> of time I'm suggesting that perhaps we open up a GWN section on the forums
> and post the text of the GWN (or perhaps each section) in a new thread
> each week and allow users to write comments.
Sounds like a good idea. 

>   I think opening up this
> venue of feedback would let users more readily tell us what they're
> interested in, and it would allow GWN contributors/editors/etc to see some
> of the fruits of their labors.
> 
> Any comments?
+1 from me

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: OT: offensive (Re: [gentoo-dev] explicit -r0 in ebuild filename)

[Patrick Lauer]

Anders Ossowicki wrote:
On 31/03/2008, *Thilo Bangert* <[EMAIL PROTECTED] 
> wrote:


> Please think things through before asking to have pkgcore's bugs
> 'fixed' via specification next time...

maybe my english language skills or social interaction qualities are
failing me, but i find the above sentence highly offensive.


pkgcore crashes on ebuilds with explicit -r0 in the PV, which led to 
Brian Harring bringing this entire discussion up in the first place. 
Rather than getting pkgcore to handle -r0 correctly, he decided to try 
and get it banned through the specification.
That bug has been adressed, still leaves the underlying problem wether 
to allow this ambiguity or not. If you have the patience to read the 
pingpong between Harring and McCreesh the current discussion is wether 
that format even makes sense, not wether a fixed bug in a third-party 
app is relevant.


Please note, the above does not imply anything about my feelings 
towards the original proposal, so please don't take it as such. I 
really couldn't care less what you decide to do or not do.


am i too thin skinned for gentoo-dev?

In this particular case, I'd say yes :-)
I'd say no. There's no need for ad hominem attack in what is supposed to 
be a technical discussion.

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

[Patrick Lauer]

Ciaran McCreesh wrote:

On Thu, 03 Apr 2008 13:17:51 +0100
Mike Auty <[EMAIL PROTECTED]> wrote:
  

Ciaran McCreesh wrote:
| Signing offers no protection against a malicious developer.

I had envisaged a system whereby when the tree was synced, as was some
kind of master signed list of all acceptable dev-keys.  Every package
would also be signed, and would only be installed when signed.  As
soon as a dev becomes a liability their key is removed from the
list/revoked. ~ On next sync any packages or package upgrades signed
after the time of revocation would not be installed.  There would be
a window of vulnerability, but no bigger than with revoking a dev's
access to the tree.  Do you think this would offer suitable
protection for users from a malicious dev or not?



Nope. In fact, using such a system, there are ways of getting in code
that doesn't get triggered until someone's key gets invalidated.
  

By this reasoning you shouldn't use passwords ...

The idea is to limit the attack vectors and make simple attacks much 
harder. A sophisticated "hacker" could just rent a busload of angry 
serbians, kidnap 12 developers and force them to do some subtle changes 
in many places. But is that likely to happen?

And if you are worrying about malicious developers, you need to worry
about malicious infra people too. An infra member throwing his toys out
of the pram can do much more lasting damage than someone who can get
some global scope nastiness into an ebuild for an hour or two...
  
That has nothing to do with the discussion ... and I don't see how infra 
could manipulate the signatures in a useful way apart from adding keys 
or removing some from the official keyring ...
This they could do at the moment by manipulating the cvs to rsync copy 
process, but I'm not aware of something like that happening. So you 
might want to have a marginal trust in people and not accuse them of 
things they might do in the future ...



--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

[Patrick Lauer]

Mike Auty wrote:

Ciaran McCreesh wrote:
|
| Signing offers no protection against a malicious developer.
|

I had envisaged a system whereby when the tree was synced, as was some
kind of master signed list of all acceptable dev-keys.  Every package
would also be signed, and would only be installed when signed.  As soon
as a dev becomes a liability their key is removed from the list/revoked.
~ On next sync any packages or package upgrades signed after the time of
revocation would not be installed.  There would be a window of
vulnerability, but no bigger than with revoking a dev's access to the
tree.  Do you think this would offer suitable protection for users from
a malicious dev or not?
There has been some previous work which has never been finalized, for 
all interested parties:

http://viewcvs.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/

Getting this cleaned up and ready for discussion would be quite valuable.


I understand there are difficulties with eclasses, etc, which is why the
current implementation is still not widely used or mandated, but I'm
more interested in the feasibility of the idea.
It can be done if people can agree to a policy and allow the 
programmatic and infrastructural changes to happen.


Have fun,

Patrick
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

[Patrick Lauer]

Ciaran McCreesh wrote:

On Thu, 03 Apr 2008 14:29:10 +0200
Patrick Lauer <[EMAIL PROTECTED]> wrote:
  

Nope. In fact, using such a system, there are ways of getting in
code that doesn't get triggered until someone's key gets
invalidated. 
  

By this reasoning you shouldn't use passwords ...

The idea is to limit the attack vectors and make simple attacks much 
harder. A sophisticated "hacker" could just rent a busload of angry 
serbians, kidnap 12 developers and force them to do some subtle

changes in many places. But is that likely to happen?



No no. The point is, there's no effective technological way of
preventing malicious developers from using the tree to screw over end
users. Signing isn't designed to and can't prevent that class of
attack (and nor can it protect against compromised end user systems).
What it *can* do is reduce the amount of damage done by a compromised
rsync server.
  

So then we should at first focus the discussion on a few things:
- what classes of attackers are there
- what defense mechanisms we can use
- what the costs (complexity, time, extra code) of each defense is

and then, from that design space, select the option(s) that have the 
best behaviour. If you get bored you can read the not-yet-GLEPs robbat2 
has written with the help of a few others, which would cut out a large 
part of the discussion:

http://viewcvs.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/

That's exactly the thing under discussion -- the design of the system

necessitates trust in both the main repository and the end user system,
and signing does absolutely nothing to help there. No-one is suggesting
that anyone from infra is going to do anything to utterly screw over
Gentoo for petty personal reasons.
  
But if you don't trust anyone there is no reason why you would even try 
to interact with Gentoo. So at some point you will have to decide to 
arbitrarily trust a few entities, be it devs or servers or cryptographic 
keys ...




--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

[Patrick Lauer]

Ciaran McCreesh wrote:

On Thu, 03 Apr 2008 14:44:45 +0200
Patrick Lauer <[EMAIL PROTECTED]> wrote:
  
and then, from that design space, select the option(s) that have the 
best behaviour. If you get bored you can read the not-yet-GLEPs

robbat2 has written with the help of a few others, which would cut
out a large part of the discussion:
http://viewcvs.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/



Uh... Which signing system did you think we were discussing when we
started talking about signing the tree?
  
Well, now we agree that we talk about the same thing after only 4 email 
pingpongs. That is quite fast!

But if you don't trust anyone there is no reason why you would even
try to interact with Gentoo. So at some point you will have to decide
to arbitrarily trust a few entities, be it devs or servers or
cryptographic keys ...



Uh huh, which is what my original reply to Mike was all about.

We're way ahead of you here...
  

Or so you think.

So now that you've tried to label me as a dimwit we're past that stage 
and can now return to actually discussing the set of issues and how to 
handle them, ja?



--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Patrick Lauer]

Doug Goldstein wrote:
Let's try to aim to do an EAPI=2 sometime soonish since Portage now 
has USE flag depends in version 2.2 which is looming on the horizon. 
It'd be nice to hit the ground running with supporting these. I know 
it'll be trivial for the Paludis and pkgcore guys to make this work 
since they already support USE flag depends.


So... let's get the party started.

The question is then, what features do people want there?

I've seen a few things mentioned, but I presume there are two 
restrictions -

1) feature needs to be reasonably useful to enough people
2) feature needs to be implementable in a short enough timeframe

So EAPI 2 is not "everything shiny", but a small iterative improvement 
to EAPI 1.


Suggest features then and let's discuss!
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Patrick Lauer]

On Tuesday 10 June 2008 16:54:49 Richard Brown wrote:
> On Tue, Jun 10, 2008 at 17:39, Doug Goldstein <[EMAIL PROTECTED]> wrote:
> > At this point, we should really only discuss features that all 3 package
> > managers have implemented.
>
> I'm not sure that's a good idea, only two have implemented EAPI 1 so far.
>
Yes, but noone cares about Paludis.

Now could you please do the rest of us a favour and keep the discussion 
focussed on improving technical details instead of random insults at others?

Thanks ...
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Patrick Lauer]

Bernd Steinhauser wrote:

Luca Barbato schrieb:

Ciaran McCreesh wrote:

The point is to make pkgcore a better package manager by getting the
developers to do some basic testing. We're not talking some obscure,
weird bug here. We're talking a really obvious, major screwup that a
couple of quick unit tests would catch straight away.


No, you aren't talking, you are babbling about undefined flaws that 
nobody can evaluate, for which you aren't providing a way to 
reproduce it and possibly doesn't exist.


lu

So in your opinion, the pkgcore maintainers should just say "Screw it, 
it was just Ciaran who said that." and move on?
No, it's just unsubstantiated rumors. As such they are irrelevant until 
some kind of proof is shown.


Why is "Create tests for EAPI=1 stuff." not a way to describe how to 
reproduce a problem?
It is too generic and doesn't even describe the class of bug. By the 
same rationale portage and paludis have multiple bugs ...


Talking away problems, now that is a way to handle QA.
So, could anyone just actually mention what the problem is, or is the 
hivemind not able to express such a simple thing?


Just think of the thousands of emails, being read by hundreds of 
readers, that have cost so much time ... in that time you could have 
written a patch and a bugreport.

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] EAPI-2 - Let's get it started

[Patrick Lauer]

Ciaran McCreesh wrote:

On Wed, 11 Jun 2008 15:20:55 +0200
Luca Barbato <[EMAIL PROTECTED]> wrote:
  
because EAPI1 isn't specified completely so you don't have a large 
field to cover but you also do not know the bounds of it.


It really doesn't matter how it is specified. You have an
implementation of it and should make sure, that this implementation
works.
  

Seems to works well enough for people using it.



Presumably those people, if they exist, haven't tried to go through and
install every EAPI 1 package in the tree (excluding KDE, since that's
big and slow, and starting backwards since the x11- categories are nice
and pretty).

  

I did. Can't reproduce. Go away.

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

[Patrick Lauer]

Ciaran McCreesh wrote:

On Fri, 13 Jun 2008 09:30:54 +0530
"Arun Raghavan" <[EMAIL PROTECTED]> wrote:
  

And why do you have to be plain insulting about it? Nobody can
magically spot every single bug in any piece of code presented to
them. In fact it's why the "given enough eyes ..." adage is one of the
bases of open source development.



Which is why any responsible person ensures good test coverage.
  

Just to pour some oil on the flames -

Y'all are aware that paludis can't parse a valid make.conf and does 
ignore package.keywords at times, yes?


Test case is:

FEATURES="strict" # test and stricter fail

in make.conf ... if you had the tests you claim others lack that would 
have been fixed a long time ago.

So please stop trolling when you fail so badly at it.
  

I _honestly_ do not understand why there is so much trouble in simple
cooperation amongst adults.



I agree entirely. Why the pkgcore people refuse to do basic automated
tests is completely beyond me.
  

Mirror, mirror on the wall.

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

[Patrick Lauer]

Fernando J. Pereda wrote:



Just to pour some oil on the flames -


Then don't do it. You are doing a very bad marketing for the pkgcore 
guys with your whinnings.

Dude. Shut up.

I'm not a pkgcore guy. If anything I'm a portage supporter. That I 
accidentally host pkgcore.org doesn't mean I'm "one of them".



Y'all are aware that paludis can't parse a valid make.conf and does 
ignore package.keywords at times, yes?


Test case is:

FEATURES="strict" # test and stricter fail

in make.conf ... if you had the tests you claim others lack that 
would have been fixed a long time ago.


Yes, we are aware of that bug in a feature we consider highly 
experimental.
Hmm, I'd have guessed config files are moderately relevant. And why 
don't y'all fix a bug like that? First you insult others for not doing 
tests, then you show a lack of tests and are proud of it. Augh.


You are amusing... 

Hey, I gave you a testcase - now fix it, chop chop!

--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]

[Patrick Lauer]

Ciaran McCreesh wrote:

On Fri, 13 Jun 2008 11:16:31 +0200
Patrick Lauer <[EMAIL PROTECTED]> wrote:
  
Yes, we are aware of that bug in a feature we consider highly 
experimental.
  

Hmm, I'd have guessed config files are moderately relevant.



You didn't notice the large warning telling you not to use Portage
config files?
  
I did. But how else can I compare things or move back to portage if I 
don't like it?



And why don't y'all fix a bug like that?



We do what PMS requires regarding handling of inline comments (which is
the same as what some EAPI 0 accepting Portage versions do, so PMS
can't allow inline comments), and indicate an error (rather than
writing junk, as older Portage did) when inline comments are used.
  
So you say the thing you wrote excludes things you don't like so you can 
claim things by referencing it as authoritative.


Does anyone else think that maybe there's a slight conflict of interest 
there?


I hope that PMS, as it stands now, does not become a standard. It is 
obviously very leaky and ignores issues so that you can claim PMS 
compatibility without being compatible to each other.


--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Patrick Lauer]

On Saturday 14 June 2008 11:53:51 Jorge Manuel B. S. Vicetto wrote:
> What's the need for a GLEP covering "live" ebuilds and what's wrong with
> - ebuilds? I made myself that question when GLEP54 was submitted and
> during the initial discussion. At that time, I wasn't convinced of the
> need for such a GLEP. Now I think it can be very useful.
> Why did I change my mind? Let's have a concrete use case.
>
> Updating the live ebuilds for compiz, can be a mess. If the ebuilds
> aren't updated in the correct order, the process will fail and leave
> users wondering why it failed. What we need is a way to ask the PM to
> update compiz-fusion and or fusion-icon and all its "live" deps.

Ok, here's a silly idea - 

tag the ebuilds with metadata. We already have RESTRICT, why not add a "LIVE" 
variable. The package manager can then treat all ebuilds with that tag 
differently. Scripts can find them easily. It is forwards and backwards 
compatible and doesn't cause any user-visible changes.

Portage 2.2 and others support sets, portage 2.2 even supports dynamic sets 
like the "@preserved-rebuild". Shouldn't be that hard to add a "live-ebuilds" 
dynamic set.
(Comments on the feasibility of my idea from portage people appreciated)

> Currently, users with Portage have to run something like:
> ~  emerge -av1 compiz compiz-bcop compiz-fusion-plugins-main \
> ~compiz-fusion-plugins-extra compiz-fusion-plugins-unsupported \
> ~emerald emerald-themes libcompizconfig compizconfig-python \
> ~ccsm compizconfig-backend-gconf compizconfig-backend-kconfig \
> ~compiz-fusion fusion-icon

That is the situation where you really love the sets in portage 2.2 - by 
default portage will re-merge every ebuild from a set when run as "emerge 
@your-custom-set". Now the overlay maintainer just has to provide the sets 
with the overlay and users are happy.

> The problem with the - ebuilds is that we need to force manually the
> reinstalls and that the PM isn't able to determine if a dep needs to be
> updated or not from the ebuild revision.

If you use sets the updating part is easy, and in situations like emerge -e 
world you want to update them anyway.

> So, running a reinstall with a world update is not desirable and having
> to manually mask/unmask live ebuilds can also be a mess.

I don't follow - if you want to update everything everything gets upgraded.

What you seem to want is a way to make certain revisions "sticky" so that they 
don't get updated, that would need something like a "package.revisions" file 
like package.keywords containing "category/package revision" lines.

> Having a method that lets the user choose to reinstall all the live
> ebuilds every N days is an interesting option. Having a method that lets
> the user choose that the PM should check the scm tree and update the
> package if there's a new revision would be even better.

I think that can be easily done if there's an easy way to pull the installed 
revision and currently available. The last discussions about that stalled 
without reaching agreement.

> But for most cases, if we define a method to identify "live" ebuilds so
> that the PM can implement a "--dl-reinstall-scm" like option, would be
> "good enough" or at least a "very good start".

I agree

> Another case where having a method to let PMs identify "live" ebuilds is
> important is for running QA scripts like repoman or pcheck.
> Instead of having pcheck complain about dropped keywords for version
> , I would like to have pcheck complain about "live" ebuilds with
> keywords. Not all "live" trees are unstable and thus some might not like
> this change. However, if a PM is able to determine "live" ebuilds, it
> might be easier to have alternative tests that allow testing for dropped
> keywords or for the existence of keywords just for "live" ebuilds.

That's what metadata is there for. And ebuilds don't mind carrying a bit 
more ... after all it's just one line of text.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Re: A few questions to our nominees

[Patrick Lauer]

On Saturday 14 June 2008 14:11:12 Bernd Steinhauser wrote:
> > That's what metadata is there for. And ebuilds don't mind carrying a bit
> > more ... after all it's just one line of text.
>
> So, what you want to do is to read every ebuild, if you want to find all
> live ebuilds?

Metadata cache. It's there for a reason.


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: A few questions to our nominees

[Patrick Lauer]

> > emerge -C @kde-svn
> >
> > emerge @kde-svn
> >
> > that should suffice.
>
> I don't see that working for something like, say, python or glibc.

No need, emerge @kde-svn will re-merge all packages in the set by default. So 
unmerging isn't needed and it just works.

-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Retirement

[Patrick Lauer]

Ciaran McCreesh wrote:

On Sun, 10 Aug 2008 21:51:11 -0700
"Alec Warner" <[EMAIL PROTECTED]> wrote:
  

Despite our best efforts Gentoo is not a fun-loving community where
everyone gets along.



Actually, I'd say that's a fairly accurate description of the problem.
Some people think Gentoo should primarily be a fun-loving community
where everyone gets along, whilst others think Gentoo should primarily
be a first-rate distribution delivering a quality product.
  
You say that as if it is mutually exclusive. I claim that having fun 
leads to quality products because of motivation and the feedback between 
people where one challenges the other to do better - I've seen quite a 
few examples of such interactions in the past, but thanks to depressing 
monologues by people with too much ego that is becoming more and more rare.


Gentoo is supposed to be fun.

If it stops being fun only grumpy old men will do the bare minimum to 
keep things from breaking too badly instead of improving things. Meh. I 
demand mandatory fun hours twice a week! And a coffee machine. And a 
pony. Yes! A pony!

[gentoo-dev] RFC: Deprecating EAPI0

[Patrick Lauer]

Hi all,

with the discussion about EAPI3 we have now 4 (or 7, depending on how you 
count them ;) ) EAPIs available or almost available. This is getting quite 
confusing.
To make our lives easier I would suggest deprecating EAPI0 and migrating 
existing ebuilds over some time to EAPI1 or higher until EAPI0 can be 
obsoleted at some point in the future.
I would set the start of deprecation warnings about 3 months from now and the 
obsoletion quite a time later, maybe 12 months from now, when a sufficient 
amount of ebuilds has been migrated.

Deprecating EAPI1 at the same time would reduce the amount of EAPIs we have to 
think about, but since it has some changes like adding src_prepare migration 
would not be as trivial. So I'd prefer keeping it around a bit longer.

Comments?


Patrick 

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Patrick Lauer]

On Saturday 21 March 2009 21:21:47 Ciaran McCreesh wrote:
> On Sat, 21 Mar 2009 18:37:12 +0100
>
> Patrick Lauer  wrote:
> > To make our lives easier I would suggest deprecating EAPI0 and
> > migrating existing ebuilds over some time to EAPI1 or higher until
> > EAPI0 can be obsoleted at some point in the future.
>
> Uh. Why?
Because, as you have noticed before, developers get confused which eapi has 
which features available. And eapi1 is a superset of eapi0, so we don't have 
to rewrite tons of things. 

> Introducing a policy encouraging moving things that definitely aren't
> in the least bit likely to be a system dep on a bump, sure. Making 1 or
> 2 the default for new packages, sure. But rewriting existing things?
> That's just an accident waiting to happen.
What kind of accident do you expect to happen?

Patrick

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Patrick Lauer]

On Saturday 21 March 2009 21:55:20 Ciaran McCreesh wrote:
> On Sat, 21 Mar 2009 21:53:16 +0100
>
> Patrick Lauer  wrote:
> > Because, as you have noticed before, developers get confused which
> > eapi has which features available. And eapi1 is a superset of eapi0,
> > so we don't have to rewrite tons of things.
>
> So? When people do new things, they can move the EAPI forward. That's
> not a reason to modify existing things.

The added complexity of having a dozen eapis does not offer any benefits to 
the average developer. Limiting the amount of complexity tends to reduce the 
amount of errors, be it simple developer mistakes or unexpected interaction 
errors between different EAPIs in the package manager.

> > > Introducing a policy encouraging moving things that definitely
> > > aren't in the least bit likely to be a system dep on a bump, sure.
> > > Making 1 or 2 the default for new packages, sure. But rewriting
> > > existing things? That's just an accident waiting to happen.
> >
> > What kind of accident do you expect to happen?
>
> The same kind that always happens when lots of ebuilds get changed.

... lots of new features and a few bugs that get fixed the next day? Hey, that 
sounds quite bad. And maybe some new herd testers? How rude!

So what technical reason(s) do we have to keep archaic EAPIs around forever?

Patrick

Re: [gentoo-dev] RFC: Deprecating EAPI0

[Patrick Lauer]

On Saturday 21 March 2009 22:26:41 Alec Warner wrote:
> >> > > Introducing a policy encouraging moving things that definitely
> >> > > aren't in the least bit likely to be a system dep on a bump, sure.
> >> > > Making 1 or 2 the default for new packages, sure. But rewriting
> >> > > existing things? That's just an accident waiting to happen.
> >> >
> >> > What kind of accident do you expect to happen?
> >>
> >> The same kind that always happens when lots of ebuilds get changed.
> >
> > ... lots of new features and a few bugs that get fixed the next day? Hey,
> > that sounds quite bad. And maybe some new herd testers? How rude!
>
> I don't see the correlation between EAPI bumps and new herd testers.

Well, ciaran said that the same thing happens that always happens when lots of 
ebuilds get changed. Last time I saw that happen (think KDE4) we got some nice 
herd testers plus a new dev or two, so I am confused too. Maybe ciaran can 
explain what he meant to say so we don't have to come to unexpected 
conclusions (that would actually be a quite nice change to the average 
discussion - saying what you mean instead of hinting at star constellations 
and the importance of meat loaf)

> > So what technical reason(s) do we have to keep archaic EAPIs around
> > forever?
> None, luckily this is more than a technical project ;)

Stop confusing me, antarus, I thought you were against removing eapi0 and now 
you support the removal? ;)

Anyway. Most of the "porting" effort (assuming no other issues sneaking in) 
would be adding a "EAPI=1" line to ebuilds, which could be done "lazily" on 
version bumps. There's no rush to get it killed now now now, but in a year we 
might be at EAPI 5, and then I don't want to be the one writing the docs that 
split apart what features are where and what syntax is valid and all that.

So phasing out eapi0 would be an obvious step towards making things simpler 
for those of us that don't enjoy studying lists and tables ...


Patrick

Re: [gentoo-dev] EAPI 3 PMS Draft

[Patrick Lauer]

On Thursday 09 April 2009 16:37:55 Ciaran McCreesh wrote:
> On Thu, 09 Apr 2009 04:12:02 +0300
>
> Mart Raudsepp  wrote:
> > It is quite irresponsible to enable that by default for the FULL user
> > base, given the state of the tree in regards to it
>
> Which is why we are not talking about enabling it for the tree. We are
> talking about enabling it for a subset of the tree that's guaranteed to
> have been tested by it.

So you propose to make a new EAPI that about 2.5% of the tree can use?

> > and the (very) considerable extra time it takes to run them while
> > it's already slower in relation to binary distributions.
>
> PROPERTIES="slow-tests" then.
>
> We've been over all of this several times previously.

And it is still the same stupid idea. We have FEATURES="test" for those who 
care, and if you look at the amount of bugs that causes already I see no sane 
way to make it default.
Why would you enable it by default just to disable it by default in those 
packages where it is the most important?

Tell you what. Provide patches for all open test failure bugs and provide a 
list of all packages where tests are slow (for certain values of slow we'd 
have to agree on) and you can resume pushing your toy ideas. 

Have fun,

Patrick

Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development

[Patrick Lauer]

On Tuesday 12 May 2009 00:31:36 Ciaran McCreesh wrote:
> On Mon, 11 May 2009 23:17:32 +0100
>
> George Prowse  wrote:
> > An equilibrium seems to have been reached which currently works.
>
> An equilibrium has been reached, agreed, but that it works is up for
> debate. There is a strong argument to be made that preserving the
> equilibrium will keep Gentoo the way it is now -- delivering at best the
> same user experience now that it was several years ago, in an
> increasingly difficult and more competitive environment.

At times I do wonder ... 

[long-winded rant following]

I've been using a few different distros over the last years. Mostly because 
people claimed that Gentoo is too hard (hey, it has a Big Friendly Manual and 
Ubuntu has a GUI installer! Ubuntu must be easier!) or didn't want to change 
their ways ("I've always used Debian Lenny. Why should I change now!")

What I realized after some time is that we're ahead of the curve. Baselayout 1 
is neat, but OpenRC is awesome. Machines rebooting in the time it takes some 
other init systems to not properly restart a service and such funny things. 
Service dependencies. A proper network config that doesn't make you bite the 
edge of the table in frustration.

Then there's package management. (Your favourite topic, I guess, because you 
want to keep complexifying it until one needs a PhD to write an ebuild [which, 
in a way, would be quite ironic])
Ever tried getting a newer version of PHP with _that_ feature enabled that the 
distro maintainer didn't like and thus disabled? Whee. Fun.
And on larger installations you usually need slightly customized packages, so 
these jokers build things from source. Manually. 
Makes it easy not to get updates too ...

Then you get the bonus features - you can have multiple versions of KDE 
installed at the same time. There's quite a lot of packages (some not that 
well maintained, but that's hard to avoid) and lots of unofficial and semi-
official overlays that have most things you need. 

So I'd say we're in a rather good position.

And now you say "delivering the same user experience" ... 
... ignoring the tons of new features and things that have happened. You're 
being dishonest again in an attempt to make us look like baboons. Two thirds 
of the new features grew on your compost heap (and half of these features we 
didn't even want, but after about three years of you pushing them at every 
opportunity people are getting so demotivated that they are willing to let you 
have one feature if you just STOP WHINING for more than 10 minutes)[GLEP55, 
for example - there's about 8 people that want it, but those keep bringing it 
up at EVERY opportunity. It's still a fundamentally stupid idea that doesn't 
solve any problems, and the claim that it might solve problems we have in the 
future is quite asinine because we can do the changes then, _if_ the 
theoretical problems actually become an issue, without messing up most 
everything now for some hypothetical gain that has not even conclusively shown 
...]

People have forked Gentoo with the goal of "making things better", and look 
where it leads them - most of them turn into a passive downstream of gentoo, 
absorbing bugfixes with a day to a month delay until bugfixes make it in. And 
those that don't stay passive slowly collapse until they are nothing more than 
a shiny webpage. 

People refuse to learn from that, but the "lessons" are quite obvious:

- We're not in a bad shape, dying or dead. We don't intend to. 

- Progress doesn't have to be disruptive features. Use-deps are a behind-the-
scenes improvement that few users hit directly, so most aren't even aware of 
the improvements happening

- More complex doesn't mean better.
"Perfection isn't when you cannot add more things but when there are none left 
to remove" or how that quote went. You know what I mean. Rewriting the init 
scripts in XML might be what some call progress (now you can verify 'em!), but 
it doesn't actually add any value and complexifies things in a bad way

- Repeating a lie can make it true, if you repeat it long enough. Worst case 
you just have to wait until everyone who disagrees dies of old age.

So anyways, just felt the need to rant a bit too. Can't let you keep a 
monopoly on that, eh?

Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted

[Patrick Lauer]

[Snip]
> Maybe you just want Sunrise in the main tree instead of as a dedicated,
> supervised overlay.  There were people with VERY strong feelings against
> Sunrise, to the point I believe at least one dev opposing it resigned
> over it 
Yes, one did. Some people just need a good excuse to leave :)

> and other boosting it were disciplined. 
Not that I remember.

> Are you ready to take on
> that sort of opposition to get it in-tree?  Maybe it's time to have that
> debate.

Oh be quiet. Sunrise is a quite convenient testing ground, and I've borrowed 
quite a few ebuilds from there for the main tree. I haven't seen any issues in 
the last few months, those opposed seem to have finally accepted that users 
collaborating is not a stupid idea. And you get a nice recruiting area for 
free ...

[Snip]

> If there's a place for the new project and maybe there is, the
> differences from and relationship with the Sunrise and proxy-maint
> projects, and the method of bringing in or justification for ignoring the
> hundreds of existing m-needed packages while arguably creating more,
> needs mapped out.  Alternatively, bend the proposal into a status change
> for one or all of the above, and call a debate on that.

I'd be for a discussion of "all of the above" since they are quite strongly 
linked.

[gentoo-dev] The fallacies of GLEP55

[Patrick Lauer]

For quite some time (over a year, actually) we've been discussing the
mysterious and often misunderstood GLEP55. 
[http://www.gentoo.org/proj/en/glep/glep-0055.html]

The proposed solution to a problem that is never refined, in short, is to add
the EAPI into the ebuild filename "to make things easier". Which is a rather
unsubstantiated idea that doesn't really add up if you look at it ... and it 
adds some artifacts that we've been laughing about for a decade because 
microsoft did the exact same thing (binding the executable-ness of a file to 
the filename).

Here's just some of the theories in support of GLEP55 that have been thrown at
me, and a few words to show how they are not really issues:

"You need to know the EAPI to parse the ebuild to find the EAPI"
Obviously that's not true, because somehow we manage at the moment.
And if one does a small restriction (which doesn't restrict current behaviour
because all in-tree ebuilds currently fit within this limitation) it becomes
trivial again:

Let EAPI be defined as (the part behind the = of) the first line of the ebuild
starting with EAPI=

As long as ebuilds remain shell-like this is not much of a restriction, and 
any format that diverges enough to make this inconvenient shouldn't be called 
an ebuild anyway. Finding the EAPI is then quite unsurprisingly trivial.

"You need to parse the ebuild and its eclasses to find the EAPI!"
See above, and eclasses shouldn't change EAPI anyway. It leads to lots of
strange effects and is implicitly impossible with GLEP55 anyway, so it might 
be easier to just declare it invalid. 

"It's slower!"
The theory here being that a stat() is needed if it is encoded in the 
filename, but a stat() followed by an open() to parse it from the file.
Well then, just cache it! You can use the mtime to check the cache validity 
(which means you do a stat() anyway, so with glep55 caching it is actually 
slower!), and then you have to parse the ebuild anyway for the other metadata. 
So the "extra" cost of finding the EAPI is ... what extra cost?
The only case when it is actually slower is when there is no cache because 
then you have to parse the ebuild. But that "degenerate" case will only hit 
some overlay users and people like developers that can wait .3 seconds longer. 
And ... uhm ... to extract other metadata like DEPENDS you'll have to parse it
anyway.

"But we need to be able to change things in the future!"
Well then. Once we have identified such an issue we can do the changes. Until
then it's not even clear if there are such changes, so why should we break
current known and predictable behaviour to satisfy a need we don't even have?
Make a structured proposal defining a concrete problem in unambiguous terms,
list all the ways to solve this issue, including advantages and disadvantages,
and we can get it voted on and ratified within a month.

"We want to change the versioning rules!"
Why do you want that, and what do we gain from it? 

"Having GLEP55 allows us to add GLEP54 without issues!"
Yeah, uhm, the live-ness of an ebuild is an attribute. How about we add it to
metadata, as we should for all metadata? Define a key, I don't know ... LIVE ? 
LIVE="true". There. No need to fix the filename. And now stop mixing up issues
because it is highly confusing!

"Obviously you don't understand the issue, because if you did you'd support 
it!"
Uhm, obviously you have no idea what you are saying. But  just to play along
... if it were that obvious we wouldn't have had to discuss it for so long.
Maybe understanding the issue forces one to support the current behaviour!


A few words in closing - 

We can encode all the relevant info in "the first line of the ebuild starting
with EAPI="
The overhead of parsing out this value for all ebuilds in the tree has been
timed at ~2 CPU-seconds by solar. It's negligible.
The changes are none at the moment, all that changes is the specification. And
if we ever have the need to change things around we can still look at the
expected costs and benefits and decide to implement something almost, but not
completely unlike GLEP55. And maybe we can now spend the same amount of
council-time (it has been eating time for over a year!) to get important 
things done ...

hth,

Patrick the bonsaikitten


P.S. http://dev.gentooexperimental.org/~dreeevil/whargarbl.jpg

Re: [gentoo-dev] The fallacies of GLEP55

[Patrick Lauer]

On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 20:06:51 +0200
>
> Patrick Lauer  wrote:
> > "You need to know the EAPI to parse the ebuild to find the EAPI"
> > Obviously that's not true, because somehow we manage at the moment.
> > And if one does a small restriction (which doesn't restrict current
> > behaviour because all in-tree ebuilds currently fit within this
> > limitation) it becomes trivial again:
> >
> > Let EAPI be defined as (the part behind the = of) the first line of
> > the ebuild starting with EAPI=
>
> Uh, so horribly utterly and obviously wrong.
>
> inherit foo
> EAPI=4
>
> where foo is both a global and a non-global eclass that sets metadata.
Interesting, but quite subtly wrong. I'm surprised that you try to slip such 
an obvious logical mistake in in an attempt to save your arguments.

> If you're looking for a formally correct alternative that works in the
> way you suggest, I already provided one, and you already read about it
> -- and it still doesn't solve the problems that 55 does.
And glep55 doesn't solve the problem either. It's neither formal nor correct, 
plus in this case ... what on earth are you trying to communicate?

> > "It's slower!"
> > The theory here being that a stat() is needed if it is encoded in the
> > filename, but a stat() followed by an open() to parse it from the
> > file. Well then, just cache it! You can use the mtime to check the
> > cache validity (which means you do a stat() anyway, so with glep55
> > caching it is actually slower!), and then you have to parse the
> > ebuild anyway for the other metadata. So the "extra" cost of finding
> > the EAPI is ... what extra cost? The only case when it is actually
> > slower is when there is no cache because then you have to parse the
> > ebuild. But that "degenerate" case will only hit some overlay users
> > and people like developers that can wait .3 seconds longer. And ...
> > uhm ... to extract other metadata like DEPENDS you'll have to parse
> > it anyway.
> Where on earth are you getting the idea that GLEP 55 makes things
> slower? The only difference to the code with GLEP 55 is in checking
> file extensions against a slightly larger set of strings, which is
> nowhere near a measurable increase in anything. You're claiming that
> checking for a suffix of either ".ebuild-4" or ".ebuild" against a
> fixed string is in any way relevant, which is obviously trolling.
That is quite definitely not my point. I mean, hombre, did you even READ my 
email, or do you just apply prewritten text blocks in the hope of solving 
issues like most "technical" "support" does? 

> There is no existing version ordering solution that accurately
> represents upstream scm branches.
Ah. Thanks. At last you say in clear words that GLEP54 doesn't actually solve 
the problem either. So we can safely keep it buried ...

> > A few words in closing -
> >
> > We can encode all the relevant info in "the first line of the ebuild
> > starting with EAPI="
>
> No we can't. That's *obviously* completely wrong.
>
It's obviously quite specifically not. Can you show any case where that fails 
or where adding this restriction removes relevant functionality?

> > The overhead of parsing out this value for all ebuilds in the tree
> > has been timed at ~2 CPU-seconds by solar. It's negligible.
>
> Those of us who have been measuring this have been discarding CPU time
> entirely, since it's utterly irrelevant. That you bring CPU time into
> this shows you've been deliberately ignoring everything we've said.
Eh, I already smashed the disk seek time argument somewhere up there. It 
amortizes quite nicely. And you are ignoring everything I say just to make a 
point that is not even wrong anymore. 

> We all know you're not stupid enough to believe what you've been
> posting or ignorant enough to miss the point so badly. So please stop
> pretending -- this issue would have gone through a long time ago were
> it not for you and your ilk deliberately pretending to be retarded so
> you can raise straw man arguments against it rather than addressing the
> issues at hand. You're doing both yourself and everyone else a huge
> disfavour by acting dumb and assuming everyone else is going to play
> along with that.
Hey. Wow. I'll keep that to post it whenever you try to insult, confuse or 
obfuscate issues to get your ideas pushed in. It describes you so wonderfully 
precise how only your own words can do.

Now, thanks for the logical fallacies (I think you've missed at least one, but 
I haven't been looking carefully) and the attempt at a personal attack. It's 
quite great, but this mailing list is definitely not the place for it. 

Now can we please get back to _debating_ things instead of wargharbling?

Thanks,

el meow

Re: [gentoo-dev] The fallacies of GLEP55

[Patrick Lauer]

On Thursday 14 May 2009 21:20:18 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 13:17:24 -0600
>
> RB  wrote:
> > On Thu, May 14, 2009 at 13:11, Ciaran McCreesh
> >
> >  wrote:
> > > Please explain why you claimed GLEP 55 makes things slower. Until
> > > you answer that, it's hard to take you for anything other than a
> > > troll.
> >
> > Hell, I'll explain.  Read paragraph 8 again.  Slowly.  Read it a
> > second time, since you obviously didn't read the first time.  The
> > paragraph makes the point that the pro-GLEP55 stance says that
> > encoding EAPI inside the file is slower.  It is not saying GLEP55 is
> > slower, it is attempting to debunk the theory that it is faster.
>
> "so with glep55 caching it is actually slower!"
>
> There's no possible way that can make sense. Whatever he's claiming by
> that is obviously nonsense.


Ah. I was not precise enough.

Let me rephrase it in less ambiguous terms then - 


"Having EAPI in the ebuild is slower than having it encoded in the filename"

Counterpoint: No, you use caching if it is that darn slow
Bonus: GLEP55 makes caching that slower than accessing it directly
Extra bonus: about a dozen emails going around in circles over a careless 
formulation that gets misinterpreted into "The iraqis have weapons of mass 
destruction!"

Re: [gentoo-dev] The fallacies of GLEP55

[Patrick Lauer]

On Thursday 14 May 2009 23:53:37 Ciaran McCreesh wrote:
> On Thu, 14 May 2009 16:49:09 -0500
>
> William Hubbs  wrote:
> > The second solution seems to be the better one because it does not go
> > against standards.  For example, we see extentions like .c, .py and
> > .pl, instead of .c-43, .py-25 and .pl-58.  There are ways within the
> > languages to tell which version of the compiler is compiling them as
> > needed.  So, If we say that, EAPI 4, for example, requires bash-4.0,
> > Isn't there a way the PM could find out which version of bash is being
> > run, compare that to the EAPI, then take appropriate action?
>
> It can't, because it doesn't know the EAPI until it's sourced the thing
> using bash. Using things like += in global scope will break older bash
> versions to the point that they can't reliably extract EAPI.

Trying to pull a Goebbels, eh?

As I've said a few times you don't have to do something as complex as sourcing 
it. In most cases you might get lucky and have some form of caching or pre-
parsed data available, so you don't even have to care. And in the other cases, 
assuming that we're talking about current ebuilds which are shell-ish and 
either define EAPI explicitly or can be assumed to be EAPI0 you can search 
with a simple regexp. That's so funky that it even works!

So if you were a lazy Unix coder you'd just restrict the current rules a bit 
so that there's only one line starting with EAPI= allowed (or maybe you just 
take the first or last one, but that's annoying) and if no such line matches 
you can safely assume EAPI0

Maybe you're very lazy, so you explicitly forbid eclasses from setting or 
changing EAPI. That also avoids weird effects that make you lose lots of time 
for debugging because you didn't think about what would happen if foo.eclass 
set EAPI="3.14" and bar.eclass inherited later set EAPI="1" ...

And magically you haven't really changed current behaviour, can get the EAPI 
without sourcing it and you can be lazy once more. Isn't it great?

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Patrick Lauer]

On Sunday 17 May 2009 06:43:50 Richard Freeman wrote:
> Duncan wrote:
> > So I believe the cost to be quite reasonably managed, after all.
> > Benchmarks would of course be needed to demonstrate that, but I believe
> > it worth pursuing.
I thought we had agreed that (1) with GLEP55 you have to source the ebuild 
anyway (whereas the other proposal allows to just parse it to get at the EAPI 
value) and (2) you can cache it sanely so that performance isn't the issue?

> Agreed.  Perhaps I'm just spoiled by RDBMS's at work or something, but
> it seems like we're trying to squeeze every ounce of speed out of a
> non-indexed flat file database and do everything we can to avoid
> actually putting all that metadata in something that actually is
> queryable no matter how lousy the final design ends up being.

The performance is really not an issue - the current design is quite limited 
and would need some interesting tweaks to go a lot faster.  In terms of 
opening-and-looking-at files GLEP55 doesn't really offer a benefit, either you 
have a metadata cache which includes it (stat for existence of cache, stat for 
mtime of ebuild, open either ebuild or cache, source ebuild if cache is stale) 
or you have it in the filename (either the same sequence of operations if you 
cache it, or you source it because of the current restrictions in glep55)

In other words, looking at performance in this case is just a distraction.

> Expressing the package database as a set of flat files works nicely -
> especially with cvs/git/etc.  Actually working with that data directly
> on a real system doesn't make sense at all.  Index it once and then only
> open the flat files on the rare occasion that you actually need to
> install one of them.  Such an index can be centrally distributed, or it
> could be maintained as packages are rsynced (and of course users should
> be able to update it on demand as well).
That sounds like a funny idea. I propose putting such a cache into 
/usr/portage/metadata/cache and have it contain pregenerated metadata keys, 
like DEPEND, HOMEPAGE and EAPI.

> When the speed of your package management system depends on the
> performance of find vs grep -r, you are doing something wrong.  Neither
> works all that well.
And when the difference is 0.03s out of 0.5s in the hot-cache and 4 seconds 
out of 75 in the cold-cache case you can't really "optimize" anything without 
considering more powerful options to increase performance ...

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Patrick Lauer]

On Sunday 17 May 2009 09:40:14 Tiziano Müller wrote:
> Am Sonntag, den 17.05.2009, 01:50 +0100 schrieb Ciaran McCreesh:
> > On Sun, 17 May 2009 00:35:45 + (UTC)
> >
> > Duncan <1i5t5.dun...@cox.net> wrote:
> > > As for ciaranm's argument that you're restricting changes to the
> > > version string, say allowing -rc where _rc is now required, one-time
> > > restriction of a year or two, yes.  However, if the spec is crafted
> > > such that the EAPI must be checked FIRST
> >
> > ...then the package manager has to inspect the metadata for every
> > version of a package before it can do anything, rather than just
> > starting at the best version and working downwards until it finds
> > something usable, which is a pretty hefty price to pay.
>
> ... if the cache can be parsed at all. With GLEP-55 we might even choose
> to change the cache format.

We might actually decide to change the cache format with or without GLEP55. 
It's trivial to think of a situation where the cache location is changed so 
that older package managers don't see it at all, thus falling back to the slow 
but reliable sourcing strategy, whereas newer versions are aware of that 
format and will be able to use it.

Please stop mixing issues, it makes it hard to discuss things.

Re: [gentoo-dev] Re: The fallacies of GLEP55

[Patrick Lauer]

On Sunday 17 May 2009 18:35:29 Ciaran McCreesh wrote:
> Please stop wasting everyone's time.

Yes, please do. Your replies are full of emotional arguments and ad hominem 
attacks. If you are unable to keep to the technical aspects of a discussion 
you should reconsider answering to every email (which is also extremely 
tiresome by volume alone).

Now if we can please keep this a discussion (which means tolerating other 
peoples opinions) we might be able to reach some results. That also means that 
we do not know a priori how to solve the problem and that there may be more 
than one solution, kay?

Re: [gentoo-dev] blocking mixed versions of split QT libraries

[Patrick Lauer]

On Monday 18 May 2009 20:19:24 Ciaran McCreesh wrote:
> On Mon, 18 May 2009 20:05:51 +0200
>
> Maciej Mrozowski  wrote:
> > > That's not in the least bit well defined, and it's also extremely
> > > dangerous.
> >
> > Please elaborate on that.
>
> With Portage's soft blocks, there's no guarantee that your blocks will
> do anything at all. Soft blocks are ignored if "they'll be fixed
> later", but then there's no guarantee that later will be reached.

In terms of the on-disk result it's invariant, the result is what you'd 
expect. There are intermediate stages that are "inconsistent" / "unclean", but 
as these are known and temporary they are an acceptable solution.

> > Everything else like things installed temporarily, no longer pulled
> > packages, are subject of 'depclean'. I don't see why pruning those
> > you consider extremely dangerous - especially when there are
> > parameters like --pretend or --ask.
>
> It's unrealistic to assume that depclean's going to be accurate at
> every given moment, especially given Portage's massively overoptimistic
> treatment of slots. It's also a very bad idea to remove packages
> without the user explicitly giving permission to do so.
Which either means that the deps are wrong/incomplete or that portage has 
algorithmic flaws which should be corrected. 
I'd expect you to at least point to the relevant bugs and not just state some 
emotional mumbo-jumbo.

Plus the packages that are removed were not installed explicitly, and to 
satisfy the needs of the user they are removed. This reflects the demands of 
the user ("Give me this app!" or "Update this pile of apps!") quite well.

> Blocks are supposed to be an absolute last resort, not something you
> throw around willy-nilly to try to get Portage to do what you're after.

No, blocks are what you need to keep the set of installed packages consistent. 
They need to be used as much as the flaws and conflicts of software packaging 
require.
Any emotional statement like "last resort", "obviously", "willy-nilly" or 
"cute" has no place in a discussion about needed technical features.


> > - that being said, I'm surprised you're looking for cheap excuse for
> > providing no working block auto-resolution mechanism (or maybe there
> > is some I'm not aware of) - it does not need to be in any Gentoo
> > specification after all - just to make things easier for users.
>
> Bah. I'm looking for a way of doing this properly, as I was before Zac
> went and broke blockers in Portage.
s/broke/fixed/

> Such a way would:
>
> * work by explaining the reason for the blocker, rather than sort-of
>   stating the expected resolution.
That's dumb ;) (Sorry, emotional statement)
I mean, it does not help to solve the issue and requires user interaction 
where an automated solution has been working reliably for quite some time.

Providing extra information would be nice, but causes more work for the 
package maintainer and the user for little benefit.

> * provide mechanisms for explaining the block in detail to the user,
>   along with instructions on how to resolve it.
User interaction where automated resolution works sounds like a step backwards 
to me. Maybe refining the rules for automated resolution would be a more 
appropriate solution?

> * be based around tree requirements, not some side effects of some code
>   someone happened to write without considering the implications.
What is a tree requirement? (Nice buzzword btw)

And as many devs and users benefit quite a lot from the portage solution, 
which zmedico did not dream up without thinking about the impact on users, I 
find it very rude and condescending of you to disrespect the solution without 
offering an alternative.

As you seem to understand the problem domain I'd expect a coherent unambiguous 
proposal instead of vague accusations and emotional terms that do not help in 
any way to improve the situation.

Re: [gentoo-dev] blocking mixed versions of split QT libraries

[Patrick Lauer]

On Monday 18 May 2009 21:20:10 Ciaran McCreesh wrote:
> On Mon, 18 May 2009 21:08:25 +0200
>
> Patrick Lauer  wrote:
> > In terms of the on-disk result it's invariant, the result is what
> > you'd expect. There are intermediate stages that are "inconsistent" /
> > "unclean", but as these are known and temporary they are an
> > acceptable solution.
>
> No, they're temporary except when things go wrong, at which point
> there's no indication that they'll be fixed.
>
When things go wrong they go wrong. Indeed.
At the moment I can't think of an obvious failure mode, so I guess I'll have 
to wait for you to refresh my memory. Until then I'll just be happy that KDE, 
poppler, e2fsprogs and a few other apps refused to fail and saved me lots of 
time and trouble (and some failure modes that are really frustrating) by just 
magically upgrading in the right sequence, avoiding error-prone user 
interaction (e2fsprogs had one funny bug that a few hundred users found) and 
allowing me to be a lazy cat.

> > > It's unrealistic to assume that depclean's going to be accurate at
> > > every given moment, especially given Portage's massively
> > > overoptimistic treatment of slots. It's also a very bad idea to
> > > remove packages without the user explicitly giving permission to do
> > > so.
> >
> > Which either means that the deps are wrong/incomplete or that portage
> > has algorithmic flaws which should be corrected.
> > I'd expect you to at least point to the relevant bugs and not just
> > state some emotional mumbo-jumbo.
> Look at the new slot deps in EAPI 3.
So the deps were not precise enough, and now we improve that. Which means that 
portage will only get more precise in the future. Awesome!

> No, broke. What he did was in direct violation of PMS and in direct
> violation of assumptions made by many packages.
So PMS did once again not reflect reality, and there were some buggy packages. 
Maybe we should spend more time on making PMS a standard that documents 
current and past behavior instead of omitting things (mtime, bash 3.1) or 
keeping it ambiguous so that two implementations can be compliant while 
delivering incompatible results?
And then ... well ... bugs are there to be fixed.

> > > * work by explaining the reason for the blocker, rather than sort-of
> > >   stating the expected resolution.
> >
> > That's dumb ;) (Sorry, emotional statement)
> > I mean, it does not help to solve the issue and requires user
> > interaction where an automated solution has been working reliably for
> > quite some time.
>
> Uhm. Knowing the reason for the block lets the package manager solve
> the problem in the most intelligent available way. Merely being sort-of
> told the expected resolution does not.
You're contradicting yourself there - until now you only mentioned user-
visible messages, which now suddenly become hints for the package manager. 

Don't try to confuse issues like that.

Now I do wonder what you can "explain" about a block - "some files collide" ? 
How does that help the package manager decide what to do? What can it do, 
except unmerging one package or refusing to merge another one? How does that 
differ from the portage solution to the blocker situation?

> Automated resolution is not always possible 
Indeed, in such cases you can let the package manager abort

> or a good idea. 
Again a subjective thing. This bacon here, buying that was a good idea. I 
should give you some, it's totally awesome!


> Also,
> having more information available for the user and being able to
> suggest an automated resolution are not in the least bit contradictory.
... which means that we can let the package manager handle all the "obvious" 
cases and try to give the user more information in the rare cases where it 
cannot find a valid solution on its own. Cool.

> > > * be based around tree requirements, not some side effects of some
> > > code someone happened to write without considering the implications.
> >
> > What is a tree requirement? (Nice buzzword btw)
>
> A tree requirement is one that comes about as a result of studying what
> ebuilds do now and what they'd like to do in the future, rather than
> one that comes around based upon what someone happens to code.
I am confused. I did not think that ebuilds have desires, so I have no idea 
what they'd like to do in the future. And it does in no way tell me what a 
tree requirement is (unless you mean happy photons, which are emitted by free-
range ebuilds when you try to source them in the kitchen)

Incidentally most of our ebuilds are based upon what someone happened to code. 

Re: [gentoo-dev] Re: [RFC] Allow bash-4.0 features in EAPI="3" ebuilds

[Patrick Lauer]

On Sunday 24 May 2009 22:43:52 Ciaran McCreesh wrote:

> > Here, this sums up what's wrong with most of your cockamamy ideas (as
> > attractive, and oh so right, as they may seem to you now):
> >
> > http://www.catb.org/~esr/writings/taoup/html/ch01s07.html
> >
> > To paraphrase you: Go and read it and don't come back til you've
> > actually understood the concepts.
>
> Sorry, you don't get to post that kind of response until you start
> being right. In light of you being wrong (see above), please apologise
> and retract your remarks.

Ciaran,

this mailinglist is not your personal playground. As you obviously can't even 
be bothered to reflect on other peoples statements without reflex-posting 
something unrelated I must ask you to stop spamming us. It's just not funny 
anymore.

Okay, yes, Mr. Long was quite rude there (trying to fight fire with fire I 
guess). But in this case you're discussing rather subjective things again (how 
often is it the case that you don't have a cache?) that might not even be a 
problem. And, as you consistently don't read any arguments that might 
interfere with how you want reality to be, sometimes people use harsher 
language in the hope of making you read (and maybe even understand) their 
argument.

Now please stop playing the drama queen, stop spamming (yes, replying to every 
mail is spamming) and maybe we can return to a technical discussion, as this 
mailinglist was originally intended (or so I hope).

Thanks in advance,

your friendly neighborhood kitten.

Re: [gentoo-dev] Re: [RFC] Allow bash-4.0 features in EAPI="3" ebuilds

[Patrick Lauer]

On Sunday 24 May 2009 23:22:21 Ciaran McCreesh wrote:
> On Sun, 24 May 2009 23:16:13 +0200
>
> Patrick Lauer  wrote:
> > Okay, yes, Mr. Long was quite rude there (trying to fight fire with
> > fire I guess). But in this case you're discussing rather subjective
> > things again (how often is it the case that you don't have a cache?)
> > that might not even be a problem.
>
> This is not in the least bit subjective. You don't have cache:
>
> * for any overlays you use
Only partially correct (but you knew that already, so I won't bother repeating 
it)
And with overlays you have _no_ guarantees anyway. Plus portage spews a nice 
warning if you play around with eclasses, which many users parse as an error. 
So that's not an issue anyway ... overlays are unsupported territory where the 
only assumption you can make is that things might not work (but surprisingly 
often they do)

> * often enough for the main tree that we get people asking about it in
>   #paludis, since Paludis warns if it encounters stale cache files.
Haven't seen that with portage (well duh), and if it really is a problem maybe 
we should ask grobian how he made the prefix rsync checkout consistent. 
Y'know, if it is a problem fix the problem.

> We know full well that this is a real problem. Stop pretending that it
> isn't.
Well, we don't. Hmm, who is we in this context? Would be much nicer if we 
stopped using the pluralis majestatis to make us look more important. Anyways, 
if it is a problem it's mostly an issue of the cache generation, which is 
trivially fixed, or it's not a problem, in which case it is fixed already. Or 
it is an issue for everyone doing unsupported things, in which case ... it is 
not an issue. Because it's unsupported. 

So what was our point again? 

Anyways, this is going round and round in circles until someone gets dizzy and 
throws up. Not the best way to "discuss", and I'm getting really bored with 
it. 

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Patrick Lauer]

On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote:

> > Gentoo should not repeat the VHS vs Betamax war. For those who do not
> > remember, VHS was the better marketed but inferior technical solution
> > that won the standards war for domestic Video recorders.
> >
> :)  Yep.  And bad design decisions can haunt is for a long time. 

Actually, once we add the current-glep55 changes we have no way of sanely 
undoing them if we should realize that they don't work out for us ...

... unless we do horrible things like forbidding it, which would cause the 
same errors we are trying to hide now.

So unless we have a plan for mid-term future changes I don't see why we would 
want the current GLEP55 - it's a one-way change in the current state.


> My preference is the one-time .ebuild->.eb change, and putting the EAPI on
> the first line, like a #!shebang.  Very easy to extract, and good design.

My preference is freezing the rsync tree, storing all referenced distfiles on 
at least one mirror, then change the rsync path.
That way all "old" users get the last sane upgrade position and all newer 
changes only hit users that upgraded far enough. Means you can slip in any 
ebuild format changes without needing to do any changes to the current file 
and directory layout. 

Do that every EAPI bump and worst case you have 200M per switch on the rsync 
mirrors and 15G extra storage on a mirror (which is a tolerable expense for 
infra if it saves us hacking things up backwards to hide errors that shouldn't 
be there)

wkr,

Patrick

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Patrick Lauer]

On Thursday 28 May 2009 00:12:56 Piotr Jaroszyński wrote:
> 2009/5/27 Patrick Lauer :
> > On Wednesday 27 May 2009 22:57:25 Joe Peterson wrote:
> >> > Gentoo should not repeat the VHS vs Betamax war. For those who do not
> >> > remember, VHS was the better marketed but inferior technical solution
> >> > that won the standards war for domestic Video recorders.
> >> >
> >> :)  Yep.  And bad design decisions can haunt is for a long time.
> >
> > Actually, once we add the current-glep55 changes we have no way of sanely
> > undoing them if we should realize that they don't work out for us ...
> >
> > ... unless we do horrible things like forbidding it, which would cause
> > the same errors we are trying to hide now.
> >
> > So unless we have a plan for mid-term future changes I don't see why we
> > would want the current GLEP55 - it's a one-way change in the current
> > state.
>
> How is it one-way exactly? You can do pretty much anything you want in
> a new EAPI (that's the point).

You cannot undo it.

In other words, you'll have to allow stupid filenames until the end of times 
even if you are quite positively sure that it is, right now, a bad idea.
>
> >> My preference is the one-time .ebuild->.eb change, and putting the EAPI
> >> on the first line, like a #!shebang.  Very easy to extract, and good
> >> design.
> >
> > My preference is freezing the rsync tree, storing all referenced
> > distfiles on at least one mirror, then change the rsync path.
> > That way all "old" users get the last sane upgrade position (...)
>
> And bugs and security vulnerabilities too. Or do you propose
> maintaining multiple trees at the same time? I think one of the main
> points of EAPI was to avoid doing exactly that.

Not at all. Just an upgrade snapshot so you can get "old" users into a known 
state, then let them upgrade at least the package manager to a point where 
they can use the rest. That snapshot should be seen as a transient helper, not 
as a "release" ...

Re: [gentoo-dev] How not to discuss

[Patrick Lauer]

This is becoming a rather lengthy email ping pong, but as people seem to be 
unable to discuss things I had to highlight a few issues there. 

Short version:

- Try to avoid subjective statements. Statements like "C++ feels better" don't 
add anything to the discussion and are objectively wrong for me, so they have 
no place in a technical discussion

- Repeating things doesn't make them more true. If someone disagrees use 
technical arguments, microbenchmarks or whatever else is needed to show that 
the argument is wrong (or at least severely flawed) instead of ignoring it.

- Start with the problem, not the solution. If you cannot define the problem 
then there's a good chance your solution isn't. Don't ignore facts if they'd 
show that your solution is a sad puppy that should get euthanised.

- Keep your cool. If you are right there's no need to immediately fire back an 
email. Take your time, disassemble the arguments (or lack thereof) the other 
side provides instead of playing semantic game or trying to use logical 
fallacies to make you sound more better.

Posting on this mailinglist is a privilege, not a right. Be careful not to 
lose it.




On Thursday 28 May 2009 01:45:18 Ciaran McCreesh wrote:
> On Wed, 27 May 2009 23:26:25 + (UTC)
>
> Mark Bateman  wrote:
> > NOT once within GLEP55 or in all the ml posts over all the *MONTHS*
> > has there been unequivocal proof that encoding metadata into the
> > filename of an ebuild is a necessity, so please stop playing that
> > tune it is getting boring
>
> Not once has there been an equally good alternative proposed.

That's subjective, and let me be the first one to disagree. GLEP55 in its 
current form (rev. 1.5 at the moment, we need to state the revision so we know 
what we are actually talking about because it mutates ...) is definitely not 
the best solution if you  (even momentarily) allow other solutions to exist.


> > > GLEP titles are required to be short.
Yes, that is a reasonable demand. It is completely independent of the demand 
that the title describes the _problem_ and not your solution. Please try to 
improve your reading comprehension to the point where we can discuss instead 
of having several independent monologues.

> > Even with title length restrictions the title can easily be improved.
> > At present it tells the skim reader NOTHING except it is todo with
> > encoding EAPI into the filename.
> >
> > "Means to determine EAPI of ebuild"
> > 7 less characters AND actually provides some description of what this
> > GLEP is going to cover not some BS "WTF" title.
>
> Doesn't cover the intent of the enhancement. The intent of the
> enhancement is to use EAPI suffixed ebuilds.

No, the intent is to find a better way to determine the EAPI. One proposed 
solution is the use of a suffix. Please stop trying to distract people in 
semantic games, it is dishonest.

>
> > > Because that's down in the 'Problem' section. Your argument appears
> > > to be that no individual paragraph covers every last bit of
> > > material in the GLEP.
> >
> > No it is not. That is not an abstract, that is jumping straight in
> > with the proposed solution. That is not what an abstraction/summary
> > is for. There is no (formal) length restriction on the abstraction
> > section so it should be taken advantage of.

This is an important point - define the problem first, then discuss solutions. 
Otherwise you end up in circular reasoning that we need to do something so 
that something is done (which is quite fun and maybe even a tautology, but has 
no information content and can thus be classified as "white noise")
> >
> > The abstract/summary is to allow those that have a quick look into
> > the paper (after looking at a relevant title...) to tell if it
> > relevant to their interest and whether they should read any further.
> > OR in a big discussion, where a paper is referred to as a logging
> > number, people can quickly ascertain what it is discussing - very
> > important ifmany papers are referenced in a discussion
>
> Yes, and the quick summary of the GLEP is that EAPI suffixed file
> extensions should be used for ebuilds.

No, that is the solution favoured by one group of people. All other solutions 
are ignored by rephrasing the problem to be the solution and the solution to 
be the obvious solution to itself.

> You're being overly harsh on Piotr there. GLEPs aren't supposed to be
> written to peer review journal standards -- they're supposed to be
> technical material that can be understood by the appropriate audience
> and used to propose an enhancement, not something that has to stand in
> archives for a thousand years.
And still one would expect a minimal coherence - stating the problem (not 
there), discussing alternatives (incomplete and phrased in a way to make them 
look extra bad) and maybe a comparison (mostly missing).

Maybe even the impact of the solution, possible issues etc. 
You know, what we have been discussing on this mailinglist ...

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Patrick Lauer]

On Thursday 28 May 2009 01:10:50 Piotr Jaroszyński wrote:

> >>
> >> How is it one-way exactly? You can do pretty much anything you want in
> >> a new EAPI (that's the point).
> >
> > You cannot undo it.
> >
> > In other words, you'll have to allow stupid filenames until the end of
> > times even if you are quite positively sure that it is, right now, a bad
> > idea.
>
> What do you mean by "allow" exactly? You can put whatever filenames in
> the tree currently and package managers ignore them, just as they
> would ignore *.ebuild-$eapi where $eapi is unsupported. So should g55
> be accepted, implemented and then undone you would "lose" only
> *.ebuild-{EAPIs introduced before undoing}.

If you add an unsupported filetype randomly you'll find a few very unhappy 
people reverting your commit and suggesting that you never do it again. And 
repoman will tell you not to do such things (assuming that you do use it)

Once you GLEP55 it is very difficult to get rid of any problems it might cause 
without triggering the kind of apocalyptic breakage that it is supposed to 
avoid. So we should be reasonably certain that it is in fact the best solution 
and we want to live with it for a long time.

But, as people are discussing some interesting new (and some old) concepts 
that might change things around quite a bit maybe we should wait until we know 
where we are going before we start changing things we'd revert immediately.

> > Not at all. Just an upgrade snapshot so you can get "old" users into a
> > known state, then let them upgrade at least the package manager to a
> > point where they can use the rest. That snapshot should be seen as a
> > transient helper, not as a "release" ...
>
> So a user n snapshots behind would have to go through various upgrade
> paths n times. And if she failed to do it all at once her system would
> be left with known bugs and vulnerabilities. Sounds a bit messy to me,
> especially as it can be easily avoided (with improved EAPIs - i.e.
> g55).
It's actually less messy than the current breakage. Just spend a few days in 
#gentoo and watch people try to upgrade after >1y ... glep55 does nothing at 
all to help with that, snapshots at least give a consistent state to converge 
to. E.g. the bash-portage blocker (easily avoided with a snapshot), the "EAPI1 
unsupported" blocker (same) etc. etc.

Most issues happen because we do not provide an upgrade path, and GLEP55-style 
changes only motivate more rapid changes that will not make it easier for 
users to upgrade. It only has the potential to make life easier for those of 
use living on the bleeding edge and allows to add package formats to the tree 
that no official package manager supports (do we want that? I vote for no)

Added bonus - as soon as you have a snapshot supporting EAPI="wintermute" you 
can migrate _all_ packages to it without having to keep Python and gcc and 
stuff as eapi0. Which means we lose some rather naughty restrictions that are 
in place now (and can easily deprecate older EAPIs too, which is good in terms 
of complexity)
Oh, and you can change the defaults around too because you _know_ that this 
snapshot and higher can handle this change. 

I could go on pointing out nice features, but since this isn't a sales 
brochure I'll just leave it at that and hope someone actually reads this mail 
before instareplying.

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Patrick Lauer]

On Thursday 28 May 2009 07:46:36 Tiziano Müller wrote:

> And here is why (I'm only looking at the non-degenerated case with valid
> metadata, ignoring overlays which some consider a corner case (I don't
> understand that argument, but that's another thing)):

overlays tend to come without metadata. Just enabling the KDE overlay changed 
the time for "emerge -upNDv world" from ~30 seconds cold cache to ~120 
seconds. Running emerge --metadata gets the performance back to pretty much 
the old levels.

> When the package manager looks at a package, it first reads the
> package's ebuild directory and gets the mtimes. It does the same for the
> cache entries and validates the caches (there is more stuff in here,
> like checking eclasses and so on).
Eclasses are negligible because you only have to look at them once for the 
whole caclulation. You can cache the mtime for the duration of your operation.

> Then the following happens based on the "solution" we choose:
> eapi-in-filename: the package manager starts from the highest version
> with a supported eapi (the others are inexistant with the used glob).
> For that ebuild it reads the cache entry and decides whether or not it
> can be used. 
In this case you amusingly do NOT want to cache the eapi in the cache, so you 
can even defer sourcing the ebuild until you actually need the metadata.
(You don't want to cache it because you need to check the file mtime anyway, 
and then you read the filename anyway. No need to look for it in another place 
then :) )

> If not, it proceeds to the next version, if yes, it's done.
> eapi-in-ebuild: the package manager reads all cache entries and sorts
> out those with an EAPI it doesn't support. The rest gets ordered and the
> same procedure as above applies.
>
> So, one of the main differences is: "reading one cache file" (if running
> unstable you can asssume you support the highest version, thus reading
> only one cache file) vs. "reading all cache files".
That assumes a dumb cache format. 
Why don't we make the cache more efficient so you read one file per package / 
category / ... ?

>
> I did some performance measurements based on that. I have 1507 installed
> packages with 5541 different versions/revisions.
>
> Reading from hot cache:
> 1507 files: ~50ms
> 5541 files: ~170ms
>
> Reading from cold cache:
> 1507 files: ~2.8s
> 5541 files: ~6s
And now you need to pull metadata for dependency calculation. How big is the 
impact of that?

>
> I made a lot of assumptions here (neglecting seek between ebuild-dir and
> metadata-dir, other processes using the drive, 80 ebuilds from overlays
> where the ebuild would have to be read, etc.). But estimating from the
> numbers above I'd say that a "emerge -uD world"/"paludis -i world" will
> be at least twice as slow, which I think is not acceptable.
I find that quite acceptable. As long as we're using such a bad layout the 
performance is secondary.

To fix the performance you'd "only" have to guarantee that the repo is 
unchanged (readonly), so you can add lots of simple caches/indexes - no need 
to source any ebuild for metadata again, one cachefile for eapi if you want 
... I bet you find lots of small improvements that that would yield. Much more 
impressive than managing to avoid a few open() here and there ...


> And I also don't understand your point of stating it's "bad design".
Bad design is like smelly feet. It's hard not to notice ...

> I mean: when coding you should "not optimize prematurely", but with
> eapi-in-ebuild it is against the other principle of "not pessimize
> prematurely" (Sutter/Alexandrescu: C++ Coding Standards).
If you quote that try the full quote:

"We should forget about small efficiencies, say about 97% of the time: 
premature optimization is the root of all evil."

In other words, we should not try to make that path faster when we can avoid 
hitting it at all with a small design revision.

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Patrick Lauer]

On Thursday 28 May 2009 20:04:18 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 18:56:00 +0100
>
> Roy Bamford  wrote:
> > As I understand this, it may add six seconds to an emerge world while
> > the dep tree is calculated. Lets say it takes an hour to do emerge
> > world, the time has increased from 3600 seconds to 3606 seconds or a
> > trivial 0.167%
>
> Interactive time is important. If it were adding those extra seconds to
> the build, no-one would care. But it's not. It's adding them to when
> the user's sitting at the screen waiting for results.

So how about we improve the structure instead of trying to patch up some 
hotspots?
For example a readonly repository would guarantee that the cache is always 
consistent. Then you can add some smart indexes, and suddenly you're no longer 
limited by IO but by CPU. Last time I saw someone try the raw metadata for all 
ebuilds was smaller than 5MB, which can be read by a modern harddisk in under 
half a second - doesn't that sound quite motivating?

> > You mean 0.3% (or less) of the emerge world time?
>
> No, he means 50% of pretend time when you're sitting there waiting to
> see what's going to happen.

So fix the diseases instead of doctoring around some symptoms ...

> > I am against *all* and any metadata in the filename. Today, GLEP 55
> > proposes the add the EAIP, tomorrow, there will be something else,
> > the day after another thing ... and all because allowing EAPI set the
> > precedent.
>
> No there won't be. There is no slippery slope.
And there's no intention of building a wall ;)

> Also, PV and PN are already in the filename.
That is needed to keep the filename reasonably unique. If you know of a nicer 
way to uniqueify it feel free to tell us ... 
>
> > You also make the error of assuming that with eapi-in-ebuild the
> > currently suggested approaches to extracting the EAPI from the ebuild
> > are the best and remain unchanged. Thats unlikely, as not a lot of
> > work has been done it yet.
>
> It is the best. If we're requiring EAPI before trying to parse PV, all
> the EAPIs have to be known to do any ordering.

... and why the [censored] would we want that then?

I mean, seriously. That is a circular argument. 
It also ignores everything said by Roy, denying even the possibility of an 
alternative. Last time I saw that style of argumentation was in a documentary 
that showed how darwinism couldn't be right (and still those people believe in 
the flu. Ha.)

It would help if you would tolerate other opinions (or even the possibility 
that other people may have opinions that do not agree with you). Roy, as an 
experienced engineer and as far as I know project manager,  might have a good 
idea or two about how to make things not blow up, and it might be in our best 
interest to listen to him for a minute or two.

Re: [gentoo-dev] How not to discuss

[Patrick Lauer]

On Thursday 28 May 2009 20:14:57 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 08:28:12 +0200
>
> Patrick Lauer  wrote:
> > - Try to avoid subjective statements. Statements like "C++ feels
> > better" don't add anything to the discussion and are objectively
> > wrong for me, so they have no place in a technical discussion
>
> You mean like "EAPI in the filename feels bad"? I agree, that has no
> place in a technical discussion.
>
> > > Not once has there been an equally good alternative proposed.
> >
> > That's subjective, and let me be the first one to disagree.
>
> No, it's entirely objective. GLEP 55 clearly shows how the filename
> based options are objectively better than anything else.
>
Ciaran ... you're obviously trying to bait people here.

Please don't do that. Trolling is not something you should do on public 
mailing lists.

I could spend lots of time trying to dissect your monologue, but if you are 
unwilling to accept that your opinion is subjective and that my opinion may 
differ from yours any further communication would be futile.

Now you may still think (subjective thing, that) that glep55 is the best 
solution. And I, with the same subjectivity, think it isn't. Trying to weasel 
your way around that with semantic games is not going to change the objective 
reality we both share. Get used to it.

And once you get used to that we can start a dialogue. Imagine that.

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Patrick Lauer]

You know, usually snipping away everything else is a bit evil because it 
removes context, but in this case I just want to point out one or two little 
pieces ...

I almost feel bad for writing so many emails to this list.

On Thursday 28 May 2009 20:48:45 Ciaran McCreesh wrote:
> > For example a readonly repository would guarantee that the cache is
> > always consistent.
>
> Until someone modifies it, yes.
>
Well. DUH. That's why it is readonly. Otherwise it wouldn't be readonly.

> > > It is the best. If we're requiring EAPI before trying to parse PV,
> > > all the EAPIs have to be known to do any ordering.
> >
> > ... and why the [censored] would we want that then?
>
> Because without that, we can't make changes to the version format.

... why?

I mean, you're turning in a tight little circle. We need to change the version 
format ... because ... we ... need to change it.

But WHY do we want it? 

> > It would help if you would tolerate other opinions (or even the
> > possibility that other people may have opinions that do not agree
> > with you).
>
> The only issue of opinion is whether or not .ebuild-X and .eapi-X.eb
> look pretty. The rest is purely technical and entirely objective.

I think I have pointed you a few times at objective statements disagreeing 
with your subjective opinion. I hate repeating myself.

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Patrick Lauer]

On Thursday 28 May 2009 21:26:43 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 21:19:35 +0200
>
> Patrick Lauer  wrote:
> > You know, usually snipping away everything else is a bit evil because
> > it removes context, but in this case I just want to point out one or
> > two little pieces ...
>
> Because you know fine well I'm right, but want to carry on trying to
> derail progress?

That's an interesting concept. But you know as well as I do that it isn't so, 
thus we have to classify your statement as a mediocre trolling attempt. Bonus 
for the anticipated emotional response, but I hope you're not too upset when I 
don't satisfy you with some mindless flaming. This mailinglist just isn't the 
right place for it ...


> > > > For example a readonly repository would guarantee that the cache
> > > > is always consistent.
> > >
> > > Until someone modifies it, yes.
> >
> > Well. DUH. That's why it is readonly. Otherwise it wouldn't be
> > readonly.
>
> And just how do you plan to enforce that? What measures will you take
> to ensure that there's no way for developers or users to modify the
> repository?
I can think of many simple methods. Like a tarball with a checksum. Or a 
zipfile. Or a git repository. That's all implementation details. But I think 
we can agree without too much pain that it is possible to have a reasonably 
tamper-proof format that we can consider readonly for these purposes.
And automatically creating it is not much different from generating rsync 
snapshots now. I guess, smart as you are, you knew that already.

> We can't make changes because the package manager needs to know the
> EAPI in order to parse versions, since once we make changes versions
> will be defined in terms of EAPI.
... why? You're stating one possible scenario as the only potential solution 
again. That ignores the other methods that were mentioned on this mailinglist 
and in other places where you lurk. Please stop being so dishonest.


> We want to make changes because, as has been stated several times
> previously, allowing 1.1_rc1 but forbidding 1.1-rc1 is entirely silly
> and arbitrary.
See Intercal versioning. Also silly and arbitrary to avoid it, but noone has 
provided a proposal to accomodate nonincreasing and nonmonotonic versioning 
systems. I doubt you would want those allowed.

> > > > It would help if you would tolerate other opinions (or even the
> > > > possibility that other people may have opinions that do not agree
> > > > with you).
> > >
> > > The only issue of opinion is whether or not .ebuild-X and .eapi-X.eb
> > > look pretty. The rest is purely technical and entirely objective.
> >
> > I think I have pointed you a few times at objective statements
> > disagreeing with your subjective opinion. I hate repeating myself.
>
> And yet you keep ignoring the part where GLEP 55 demonstrates
> objectively that the extension solution is better than the alternatives.

I really. Really. Hate repeating myself. 
It's so redundantly superfluously redundant. And it wastes people's time. Did 
I mention it is redundant?

Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Patrick Lauer]

On Thursday 28 May 2009 21:52:49 Ciaran McCreesh wrote:
> On Thu, 28 May 2009 21:46:48 +0200
>
> Patrick Lauer  wrote:
> > > And just how do you plan to enforce that? What measures will you
> > > take to ensure that there's no way for developers or users to
> > > modify the repository?
> >
> > I can think of many simple methods. Like a tarball with a checksum.
>
> ...which a user can modify once it's been extracted.
>
> > Or a zipfile.
>
> ...which a user can modify once it's been extracted.
>
> > Or a git repository.
>
> ...which a user can commit to without telling the package manager that
> the cache is now invalid.

So, basically, we can't do anything, because the universe might spontaneously 
decide to cease to exist. Quite scary, that. 

Oh, and if you break stuff it is broken. Splendid!

Your random distraction at least made me giggle, but it is not relevant to the 
discussion of a readonly repository. 

>
> > That's all implementation details. But I think we can agree without
> > too much pain that it is possible to have a reasonably tamper-proof
> > format that we can consider readonly for these purposes.
>
> No, I do not in the slightest bit agree that there is an easy way of
> ensuring that what the package manager sees hasn't been tinkered with
> by a user or developer who "just wants to try a quick change out".

So things blow up. Sometimes Darwin has to do his work, especially when you 
climb over two fences, break open a locked metal door and discover that the 
Ursus arctos is, in fact, a very antisocial carnivore and not as cuddly as you 
thought.

You cannot stop a determined user from painting himself in a corner, but you 
can avoid most cases of accidental damage. 

>
> > > We can't make changes because the package manager needs to know the
> > > EAPI in order to parse versions, since once we make changes versions
> > > will be defined in terms of EAPI.
> >
> > ... why? You're stating one possible scenario as the only potential
> > solution again. That ignores the other methods that were mentioned on
> > this mailinglist and in other places where you lurk. Please stop
> > being so dishonest.
>
> No-one has provided a viable way of extending the version format that
> doesn't require EAPI changes. So unless you're talking about your
> "start a whole new tree" idea,
Wait, I thought noone had provided a way ... except that one ... argh, 
cognitive dissonance detected. 

I'm sorry, you contradicted yourself. Please choose one option only.

> which has already been debunked to
> death...
Weird, that didn't happen in this universe. 

> > > We want to make changes because, as has been stated several times
> > > previously, allowing 1.1_rc1 but forbidding 1.1-rc1 is entirely
> > > silly and arbitrary.
> >
> > See Intercal versioning. Also silly and arbitrary to avoid it, but
> > noone has provided a proposal to accomodate nonincreasing and
> > nonmonotonic versioning systems. I doubt you would want those allowed.
>
> No-one is suggesting making changes to match silly upstream versions.
But I thought you just said that silly and arbitrary restrictions ... I am 
confused. You are in a quantum superposition state where you support both 
sides of an argument and only collapse your brainwave functions whenever 
someone tries to observe you or something ... 

> What we are suggesting is making changes to match sensible and
> reasonable upstream versions.
Which we already have. Excellent, so you agree that we don't need to change 
versioning. Sometimes I really like discussing with you, because after a long 
time you suddenly accept reason :)

Re: [gentoo-dev] Re: How not to discuss

[Patrick Lauer]

On Friday 29 May 2009 04:12:04 Ryan Hill wrote:
> On Thu, 28 May 2009 08:28:12 +0200
>
> Patrick Lauer  wrote:
> > This is becoming a rather lengthy email ping pong, but as people seem to
> > be unable to discuss things I had to highlight a few issues there.
>
> I'm sorry to be rude,
Don't be, most other posters on this list have no guilt either ...

> but ever consider that the reason people keep
> repeating things to you is that you continually misunderstand what they're
> saying?
I'd say it is more the refusal of certain people to discuss at all.
The constant attempts to shove a rational discussion into emotional pockets 
makes it quite hard to get any information out of it, statements like:

> No, it's entirely objective. GLEP 55 clearly shows how the filename
> based options are objectively better than anything else.

are just wrong. It ignores one side of the conversation completely, not even 
accepting any potential value in their contribution. It's not a way to lead a 
technical discussion, and I'll do what I can to reduce such sophistry so we 
can _discuss_ things rationally.

If anyone needs help - there's a few experienced engineers on this list that 
can help you get your ideas into a form that can be presented, discussed and 
improved without having to repeatedly ask for clarification what the actual 
problem is. Don't be afraid to learn from them.

> I think that by now we've exhausted everything that can possibly be said
> about GLEP 55.  Nothing in this discussion is new, nor has it been for some
> time.  Can we please just stop now and trust the representatives that we've
> elected to make their decision?  Or should we go around the ring one more
> time?
Looking at how it went last time ... prepare for at least two further rounds 
of trying to convince people that their feelings are wrong. That, of course, 
is doomed to failure because our subjective reality cannot be falsified, but 
facts (and their darn liberal bias!) or logic are usually only accidentally 
involved.