Re: [gentoo-dev] [RFC] Solving the problem of huge number of wrong LICENSES=*GPL-[23]

[Michael Mol]

On Sunday, August 26, 2018 7:09:41 AM EDT Paweł Hajdan, Jr. wrote:
> On 26/08/2018 12:53, Mart Raudsepp wrote:
> > The common issue here is that upstream COPYING files really do only
> > talk about one of the versions. And then you get to validate or source
> > files to be sure that they do have a "or later" clause in them. And
> > then on each bump you ideally should validate it again, etc, that no
> > sources without "or later" allowance are in there...
> 
> Yup, precise tracking of license metadata can be a pain.
> 
> I'm not really sure if that level of it is worth for us as a distro. For
> _importing_ other project's source code directly into one's project
> precise license compatibility matters a lot. That's not the scenario
> we're in. I see LICENSES as mostly a mechanism for end users to accept
> or reject EULAs etc, and I'm curious what are other common scenarios.
> 
> Michał, could you elaborate on why not distinguishing more precisely
> between these GPL variants in LICENSES is a _problem_ ? I can certainly
> see the information is not always accurate, but it's not obvious to me
> how severe is the downside, what are the consequences in practice.

I can say that if the licenses are habitually misidentified, I could not use 
Gentoo's portage tree in my job without extensive and ongoing revalidation of 
the license metadata.

There are, in fact, automated tools for advising about the license disposition 
of these types of things, examining source files for unfortunate edits and 
variants and flagging them, etc. It might be an interesting task at some point 
to point some of these tools at portage, look for incorrect metadata and file 
bug reports.

Not suggesting this is a worthwhile approach up front, but it might be a 
useful tool in the future for dealing with license metadata quality as a 
chronic issue. (Which, in turn, is useful for commercial consumption and 
participation.)

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Michael Mol]

On Friday, January 6, 2017 5:27:24 PM EST Kent Fredric wrote:
> On Tue, 3 Jan 2017 10:23:02 -0500
> 
> Rich Freeman  wrote:
> > I tend to be firmly in the camp that a package shouldn't be removed
> > unless there is evidence of a serious bug (and that includes things
> > blocking other Gentoo packages).
> 
> I would probably go further and extend that argument to older versions
> of packages, for similar reasons, at least in regards to older versions
> with specific and exclusive APIs.
> 
> Our duty as maintainers is to protect our users from the mistakes
> upstream make as much as possible, not to protect ourselves as
> maintainers from having difficult challenges.
> 
> But our duty here doesn't extend to protecting users from problems the
> user knows don't affect them.
> 
> If for example, a media playback suite has a memory corruption bug when
> playing media of a certain type, making it unusable when playing that
> media, it does seem reasonable for us at first to kill that suite.
> 
> However, if the user in question knows they're never going to play
> that certain type of media, and only uses that media suite for a narrow
> and specific kind of problem, then we're not serving them much utility,
> or much freedom of choice by ripping this tool out of their hands for a
> problem they'll never have.
> 
> Maybe we need an intermediate option, where the sensible default when
> we discover this kind of error is to remove it, but provide a way to
> easily restore that package if the users are ok with it.
> 
> Like, this is not my proposal, just an idea so you can see where I'm
> headed with thoughts:
> 
> If packages had a field called "BUGS=" it could contain an array of
> bugs a package is known to contain, but can be conditionally avoided if
> you're careful.
> 
> Packages with non-empty BUGS= fields would be treated as hard-masked
> for the purpose of repoman checks, and so packages that depend on
> specific version ranges of packages with BUGS= fields are invalid,
> and need their own BUGS= fields.
> 
> Users get portage by default telling them "X package has to go away,
> because it has bug #145 , #1286234, and #123756"
> 
> And if this is not satisfactory, they can override portage with
> 
> ACCEPT_BUGS="145 1286234 123756"
> 
> You could even have
> 
> BUGS=" x86? ( 112345 )"
> 
> This to me sounds like a more user-empowering approach.

I really like where this is going.

> 
> The only questions to me are:
> 
> - Do we have the resources to support this kind of strategy?

How much of the work can be automated? I.e. can bugs on bgo be tagged such 
that a maintainer's script can scoop up the bugs and apply them, at least 
naively? Being able to express something like "x86? (!mmx)" clearly in a bgo 
ticket's metadata could well be useful, and would lend itself to something 
like this.

The bigger resource drain, I suspect, will come from maintaining new ebuilds 
of old packages; as eclass development and maintenance seeks to eliminate old 
and buggy code, old ebuilds will need to be dragged along for the ride.

> - How much additional complexity and confusion will this introduce for
>   users?

I think you'd want autounmask to not support applying changes for 
automatically unmasking bugs. Apart from that, it shouldn't result in any 
additional complexity or confusion for users who aren't deliberately holding 
on to package versions that have known bugs. Most of the users I've seen who 
would be faced with this functionality are the users who will run a gymnastics 
course just to use a browser version that has an old, familiar interface.

> - Is that additional complexity and confusion something users want to
>   indulge, or is our current feature set already too complex.

So long as it stays out of a user's way until the user needs it, I wouldn't 
say it adds needless complexity from a user's perspective.

> 
> That last one is pretty much the one that weighs most on my mind
> lately, with users frequently stumped by handling subslot upgrades
> and required-use conflicts.

Choosing to engage with this functionality sounds like very much an opt-in 
experience for the user; the path of least resistance is to go ahead and 
update (and that will generally provide the best-tested global configuration), 
but if they wish to hold on to difficult configurations, they can at least do 
that.

There is one other advantage to a system like this; it permits for a larger, 
deeper tree, with old versions more frequently available. That'll significantly 
assist the upgrade efforts of people who go ridiculous amounts of time between 
@world updates, people who are dusting off stowed systems, etc.

> 
> Granted, this is just yet-another alternative flavour of hard-masking
> things, so I'd rather we stick with careful use of hardmasks to inform
> users of problems they might face, allowing them to contravene the hard
> masks if they're feeling like they want to be adults.



signature.asc

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Michael Mol]

On Tuesday, January 3, 2017 10:23:02 AM EST Rich Freeman wrote:
> On Tue, Jan 3, 2017 at 9:57 AM, Michael Mol <mike...@gmail.com> wrote:
> > For security's sake, even mature software needs, at minimum, routine
> > auditing. Unless someone's doing that work, the package should be
> > considered for removal. (Call that reason #π, in honor of TeX.)
> 
> Are you suggesting that we should ban any package from the tree if we
> don't have evidence of it having recently being subjected to a
> security audit? 

Of course not. Full security audits are stupid expensive, be it in terms of 
money, time or labor. It Would Be Nice if they at least periodically got 
subjected to -Werror -Wall from time to time, or at least a linter check, or 
some tie-in to Coverity, with the results considered, but even that's going to 
be too much to ask an upstream to accept patches for.

Besides, there are going to be vulnerabilities that come from combinations of 
packages and their environments; something that's fine on x86 might have a 
critical vulnerability on arm. Something that's fine on x86_64 might have a bug 
that only presents itself in a constrained address space like x86. Something 
that's generally fine on its own might have a subtle bug that only manifests 
when a particular version of another package's headers are present at build 
time.

It's ludicrous to be absolutist about security. As I remarked to someone the 
other day, there are always more things to fix or secure than you'll have 
resources to follow though on. If someone one think a system is as secure as 
it can possibly be, then they're not as clever as they think they are.

> We might literally have 3 packages left in the tree
> in that case, probably not including the kernel (forget the GNU/Linux
> debate, we might be neither).
> 
> The fact that a project gets 47 commits and 100 list posts a week
> doesn't mean that it is being security audited, or that security is
> any kind of serious consideration in how their workflow operates.

I'm sure we all remember Heartbleed.

> 
> I tend to be firmly in the camp that a package shouldn't be removed
> unless there is evidence of a serious bug (and that includes things
> blocking other Gentoo packages).  If somebody wants to come up with a
> "curated" overlay or some way of tagging packages that are considered
> extra-secure that would be a nice value-add,

Ideas like this is one reason I'm looking for a corpus of pros and cons for 
treecleaning. I don't see it as black and white. But having ideas like these 
brought up is at least useful.

> but routine auditing is
> not a guarantee we provide to our users.  The lack of such an audit
> should not be a reason to treeclean.

I'm not trying to drive a "clean all the things" campaign. Rather, I'm 
principally interested in having a list of the standard arguments one way or 
another, for reference in the inevitable "why should this get cleaned up? It 
works." threads.

There's an old joke that goes something like this:

> Joe is going to his first comedian's convention. He's excited to see all 
> these funny people in person.

> The opening session begins with Robert, who gets up and says, "42!" Everyone 
> busts a gut laughing. Then Susan gets up and says, "73!" Again, everyone 
> laughs.

> Joe asks the guy next to him, "What's going on? I don't get it."

> "Oh, you see, everyone's heard all the same jokes over and over, so to save 
time, they reference them by number."

> "Ah! Let me give it a try."

> Joe stands up and says, "3!" Nobody laughs. Embarassed, Joe sits back down.

> "I don't understand," Joe says to the guy next to him. Why didn't anyone 
> laugh? Was 3 a poor joke?

> "Oh, no, 3 is fine, but the key is in the timing!"

Essentially, I'm looking for the joke book. Because these recurring threads 
would be a lot more interesting and less time-consuming and frictive if 
recurring material could be quickly identified and referenced. And then someone 
who still has a point to make can say, "Well, 3 is more important than 7, and 
here's why." And then have less spilling of words and boiling of blood 
irritating everyone and hardening positions before we get to consider 
something new.

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

Re: Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Michael Mol]

On Tuesday, January 3, 2017 9:24:19 AM EST Damien LEVAC wrote:
> On 01/03/2017 09:14 AM, Michael Mol wrote:
> > On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
> >> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> >> 
> >> gro...@gentoo.org wrote:
> >>> On Mon, 2 Jan 2017, Brian Evans wrote:
> >>>> IMO, this one should be given last-rites as upstream is dead and it
> >>>> heavily depends on wireless-tools and WEXT.
> >>> 
> >>> I use it on 2 notebooks. It works fine, and is (from my point of view)
> >>> the
> >>> most convenient tool to control ethernet and wifi connections on a
> >>> notebook. Why lastrite it when it works?
> >> 
> >> This is the Gentoo Way™. Having a working software is not a goal.
> >> Gentoo focuses on the best bleeding edge experience and therefore
> >> highly relies on software packages that are under active development
> >> and require active maintenance. The packages in early stages of
> >> development are especially interesting since they can supply users
> >> and developers with variety of interesting bugs and unpredictable
> >> issues.
> > 
> > Do we have detailed treatise documenting the points and counterpoints to
> > "Why lastrite it when it works?" It's a question that comes up every
> > month or two, and the reasons, for and against, are probably mature
> > enough to get numbers, now.
> > 
> > Reason #3 in favor: "It works for me" may only be valid from a particular
> > perspective. Without active maintenance, there may be subtle bugs that
> > aren't immediately obvious. Bugs that aren't immediately obvious aren't
> > always innocuous; sometimes they're insidious background data loss. Other
> > times, they might be security vulnerabilities no good guy has yet
> > noticed.
> 
> ...and sometimes a package just stop being "actively" maintained because
> it is feature-complete (as far as the goals of the project were
> concerned) and just works.
> 
> The minimum conditions to lastrite something should be not actively
> maintained _and_ with open bugs

What happens when the bugs exist, but nobody knows they're there? Let's say 
someone got a copy of Coverity and ran it on long-stable, ridiculously mature 
packages. They get a bunch of hits, but they keep it to themselves and instead 
develop exploits for the bugs they found.

For security's sake, even mature software needs, at minimum, routine auditing. 
Unless someone's doing that work, the package should be considered for 
removal. (Call that reason #π, in honor of TeX.)

(I'm really not trying to start yet another massive thread on the subject, 
hence my original question: Do we have a documented treatise on the question? 
Not "Gentoo's Official Policy", but rather the rationales and counterpoints?) 

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

Why lastrite when it works? (Was: Re: [gentoo-dev] Packages up for grabs due to retirement)

[Michael Mol]

On Tuesday, January 3, 2017 12:05:10 PM EST Michał Górny wrote:
> On Tue, 3 Jan 2017 16:00:52 +0700 (+07)
> 
> gro...@gentoo.org wrote:
> > On Mon, 2 Jan 2017, Brian Evans wrote:
> > > IMO, this one should be given last-rites as upstream is dead and it
> > > heavily depends on wireless-tools and WEXT.
> > 
> > I use it on 2 notebooks. It works fine, and is (from my point of view) the
> > most convenient tool to control ethernet and wifi connections on a
> > notebook. Why lastrite it when it works?
> 
> This is the Gentoo Way™. Having a working software is not a goal.
> Gentoo focuses on the best bleeding edge experience and therefore
> highly relies on software packages that are under active development
> and require active maintenance. The packages in early stages of
> development are especially interesting since they can supply users
> and developers with variety of interesting bugs and unpredictable
> issues.

Do we have detailed treatise documenting the points and counterpoints to "Why 
lastrite it when it works?" It's a question that comes up every month or two, 
and the reasons, for and against, are probably mature enough to get numbers, 
now.

Reason #3 in favor: "It works for me" may only be valid from a particular 
perspective. Without active maintenance, there may be subtle bugs that aren't 
immediately obvious. Bugs that aren't immediately obvious aren't always 
innocuous; sometimes they're insidious background data loss. Other times, they 
might be security vulnerabilities no good guy has yet noticed.

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

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Michael Mol]

On Friday, December 02, 2016 02:10:27 PM Michał Górny wrote:
> Hi, everyone.
> 
> I've heard multiple times about various tinderbox projects being
> started by individuals in Gentoo. In fact, so many different projects
> that I've forgotten who was working on most of them.
> 
> I know that Toralf is doing tinderboxing for most of the stuff.
> What other projects do we have there? What is their status?
> 
> Is there anything we could try to integrate with pull requests to get
> a better testing?

If there's a mostly-turnkey VM I can run to contribute to Tinderboxing, I have 
one or two systems I could benefit from some heat from over the winter. It's 
that or bring out the electric space heater. Was talking with my wife about 
mining Doge on one of them last night...

-- 
:wq

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

Re: [gentoo-dev] Please retain authorship of contributed patches

[Michael Mol]

On Thursday, December 01, 2016 10:13:17 PM Andrey Utkin wrote:
> On Thu, Dec 01, 2016 at 12:50:42PM -0800, Daniel Campbell wrote:

[snip]

> > Thanks for bringing this to attention. It's somewhat related to another
> > discussion we've been having about copyright, and it may be worth
> > considering protocol for situations like the one you've outlined.
> 
> Could you  please give a link to archives of that discussion?

It looks like there's two of them. Daniel's probably thinking of this one:

https://archives.gentoo.org/gentoo-dev/message/d58dd815aa48df69afb9d096754c0d04


But this one is also relevant:

https://archives.gentoo.org/gentoo-dev/message/63dcd62b33080a2e29f1ec4f3b484b51

(Deep linking in the second thread, as that's when copyright was first brought 
up in it, dealing with DCOs.)

-- 
:wq

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

Re: [gentoo-dev] RFC: Userkit.eclass

[Michael Mol]

On Wednesday, November 30, 2016 03:25:21 PM William L. Thomson Jr. wrote:
> On Wednesday, November 30, 2016 3:08:30 PM EST Michael Mol wrote:
> > > IMHO it is something that should be  a part of LSB. If not POSIX in
> > > general. One cannot really change the past or current state of things.
> > > But can make
> > 
> > the future better.
> > 
> > > For now who cares about other OS or distros. If Gentoo gets its house in
> > > order
> > > others may follow.
> > 
> > I will note that it's this point when I first replied; that was the point
> > when you chose to expand the scope outside Gentoo.
> 
> Stop making things into something they are not. Re-read the above I said it
> should be part of official standards. I also said others MAY follow...

Honestly, that sounded to me like advocacy; "a benefit of doing this is that 
others may follow." If that's not the spirit in which it was intended, I 
apologize.

> 
> > > Gentoo cannot force others to do anything.
> > 
> > I didn't say force. I said invite.
> 
> I never typed the word invite. I never mentioned Gentoo being proactive
> about pushing its specific things on others. Please stop making stuff up
> and going way off topic.

As I note above, I interpreted what you said as advocacy.

> 
> > As you noted, Arch appeared to attempt this, and others did not follow.
> 
> Arch themselves never got it squared away. It was just a concept. If Arch
> does not implement it how can others? I hardly consider Arch a leading
> distro like RHEL or Debian, which both have derivatives in wide use,
> Fedora, CentOS and Ubuntu.
> 
> That right there likely covers over 50% of all Linux installs.
> 
> > That's fine. As I pointed out, I only started chiming in when you began
> > advocating exporting Gentoo's list to a broader ecosystem.
> 
> You are reading things I never typed, and coming up with some far fetched
> scenarios. Nothing you are saying is anywhere near what I wrote.

Again, read above. If that's not how it was intended, I apologize.

> 
> > If RHEL and Debian are consistent from one system to the next, obviously
> > it's sensical to use their list. But why don't they use each others? Or am
> > I missing something, and that's exactly what they're doing?
> 
> Going back to my first point about this being part of LSB or POSIX. Because
> it is part of neither RedHat and Debian do things differently.


You're asserting that Red Hat and Debian do things differently because there's 
nobody to force them to do things the same way. It can't be because there's no 
reference for them to look at; for sure, the second into market could simply 
have looked at the first. It's probable they did.

I know Debian starts their non-system UIDs at 1000, while RH, once upon a 
time, started theirs at 500. Why the difference? Dunno. RH came before Debian, 
so I imagine Debian wanted a bit more headroom to work with. Are there static 
UIDs in the 500-999 range on Debian? That would be why RH doesn't use Debian's 
set; they'd have a UID conflict on their hands.

Staring at a CentOS7 live environment in front of me, it looks like RH now 
starts at 1000.

It's probable they could settle on a common spec now, but there would still be 
a great number of legacy systems out there to support., and you've still got a 
very limited namespace to work with.

> 
> Why does RedHat not use deb format over rpm. Why does Debian use deb instead
> of RPM. 

Well, RPM was developed to be a better alternative to the tarball. Debian 
thought the RPM format was lacking, and developed their own spec. For sure, 
nobody likes to do work for no reason. Even hugely disruptive changes have 
motivations behind them.

I'm sorry, was that a rhetorical question? I just realized...

> These are different distros with different approaches. If their
> UID/ GID are the same, its likely per legacy reasons. Though they may be
> looking at each other.
> 
> Debian at this time does not produce a list. The only I found were RedHat
> and Arch, with Archs' being unofficial and never adopted.

I'll note I'm treating the concept of a list as very abstract; if things are 
consistent, then there's de facto a consistent state that could be distilled 
deterministically into a listing.

> 
> > Sure. But if you clone a seed node, does it matter that a second
> > from-scratch install may not have the same mapping?
> 
> Yes if they are to be added to the same fleet or cluster of systems. In that
> event it would likely start a new from scratch base image. But that is
> pretty rare. I do update base images, though rarely do system UID/GID
> change from initial install.

You know, I would expect for a system of that scale, that you'd have 
standardized and pre

Re: [gentoo-dev] RFC: Userkit.eclass

[Michael Mol]

On Wednesday, November 30, 2016 01:41:24 PM William L. Thomson Jr. wrote:
> On Wednesday, November 30, 2016 1:22:07 PM EST Michael Mol wrote:
> > If Gentoo wants to do it internally, that's one thing.
> 
> This list is about Gentoo internal things

Here, let me bring up a bit of recent history from your Message-ID 
<assp.0140865882.25530652.rRlbQJgv4Y@wlt>, which had a signature of 
iEYEABECAAYFAlg8iAQACgkQTXGypIOqM1A2EgCglmZkNYaJ16qQkSxezTqCtI4/
PwoAnR2dW0XUFZk8QUmgrVwu+3OpRxS+
=tuat, which my client indicated matched the key 
0xC47A576A663995BADF1B54724D71B2A483AA3350, but I don't have your key trusted, 
so whatever:

> I believe the main reason such is the case is a lack of any such list or 
> database for others to adhere to. Once again an area Gentoo could be
> leading. 
> Had Gentoo done this years ago others might have adopted.

> IMHO it is something that should be  a part of LSB. If not POSIX in general. 
> One cannot really change the past or current state of things. But can make 
the future better.

> For now who cares about other OS or distros. If Gentoo gets its house in
> order 
> others may follow.

I will note that it's this point when I first replied; that was the point when 
you chose to expand the scope outside Gentoo.

> 
> > But I would recommend
> > against inviting other distributions to use Gentoo's list, which was
> > something you seemed to be suggesting. Doing so asks that Gentoo shoulder
> > the bureaucratic load from other distributions that want things added to
> > Gentoo's list.
> 
> Gentoo cannot force others to do anything.

I didn't say force. I said invite.

> If Gentoo is leading in a
> direction, others choose to follow or not. Gentoo does not set standards
> that would be up to LSB and/or POSIX.
> 
> My point is Gentoo should do its own thing, lead the way. Ideally others
> follow and it becomes a standard either in LSB or POSIX. Hopefully that will
> clarify my position.

As you noted, Arch appeared to attempt this, and others did not follow.

> 
> > If you want to tie this specifically to Gentoo packaging, that's fine.
> 
> Which is why it is being discussed on a Gentoo development list and not
> others.

That's fine. As I pointed out, I only started chiming in when you began 
advocating exporting Gentoo's list to a broader ecosystem.

[snip]

> > > This is not needless bureaucracy , this is necessary.
> > 
> > Opinion. Why is it necessary? What is it necessary for?
> 
> It is necessary so Gentoo base system installs are consistent from one
> system to the next, Just as RHEL and Debian, and likely others. When
> working with large amounts of installs, You want them all to be the same or
> as close to identical as possible. Thus the rise of Docker, CoreOS, etc.

If RHEL and Debian are consistent from one system to the next, obviously it's 
sensical to use their list. But why don't they use each others? Or am I 
missing something, and that's exactly what they're doing?

> 
> > Oh, I understand the problem, but you haven't explained why your solution
> > is the necessary solution to it, or how you would cope with the plethora
> > of edge cases I brought up. It would seem there are already many
> > established workarounds for the status quo, unstable-UID/GID in a
> > cross-system context.
> My solution is to avoid such issues. I start with a common base image. I try
> to ensure anything else installed beyond that, which adds new users/groups
> is the same. At times I will re-image and use that as well for other
> similar systems. Rather than mess with doing the same install to many and
> trying to sync UID/GID.
> 
> Think cloning rather than installing.

Sure. But if you clone a seed node, does it matter that a second from-scratch 
install may not have the same mapping?

[snip]

> > Less bad if you intend to keep it unique to
> > Gentoo, but the broader you make the scope, the more strain you'll put on
> > the ecosystem as a whole.
> 
> Standards need to exist so there is consistency. In the absence of said
> standard, next best thing you can do is look to what others are doing and do
> the same. Thus I tend to say go with RedHat UID/GID over say Arch, maybe
> even Debian.   But those two likely have larger install bases than most any
> other distro. If the UID/GID are the same between RedHat and Debian, that
> already makes a good deal of systems consistent now.

If UID/GID are consistent between RH and Debian, then yeah, what you have is a 
de facto standard, and it would be reasonable to conform, if there are people 
who actually have a need for that cross-system mirroring.

> 
> > More daemons will be build that are intended to
> > run as local users. More software will be pushed into opaque blobs 

Re: [gentoo-dev] RFC: Userkit.eclass

[Michael Mol]

On Tuesday, November 29, 2016 04:49:24 PM William L. Thomson Jr. wrote:
> On Tuesday, November 29, 2016 10:40:20 AM EST Michael Mol wrote:
> > Highly detailed lists like that--used as a broad standard--are a bad idea.
> > They represent a single synchronization point that everyone must adhere
> > to.
> 
> That is a statement based on opinion.

Of course. And then I gave examples as to why.

> You say it is a bad idea. I say it is
> necessary and needed. Otherwise wrt to Gentoo ebuilds can stomp on each
> other. Using same GID or UID in more than one ebuild causing problems.
> There has to be something know so others do not use ones others are
> already.

If Gentoo wants to do it internally, that's one thing. But I would recommend 
against inviting other distributions to use Gentoo's list, which was something 
you seemed to be suggesting. Doing so asks that Gentoo shoulder the 
bureaucratic load from other distributions that want things added to Gentoo's 
list.

> 
> > That means that every prospective adjustment to the list requires active
> > maintenance. That means that for every new daemon someone writes, they
> > have
> > to go through an admissions process. For every contentious fork of a
> > project, you risk conflict over who the designated contact for the
> > assignment should be.
> 
> If they package such in Gentoo someone is making a call as to what UID and
> GID should be used. If you think about it from packaging said new daemon in
> Gentoo, it is a MUST.
> 
> If it does not exist, should it be entirely random from the packager
> perspective? What if they use a GID/UID specific to them and not others.
> 
> There has to be some standard some consistency in Gentoo.

If you want to tie this specifically to Gentoo packaging, that's fine. Though 
I'd recommend you put the user and group allocation in the ebuild. Then your 
"list" is trivially generable by parsing portage. Further, you can *enforce* 
these allocations when calculating the dependency tree. If you're not 
enforcing them, what's the point? Is there a benefit without said enforcement?

> 
> > It adds a large bureaucratic load on everyone. Every itch some developer
> > thinks about scratching has to be weighed against engaging with some
> > process- laden entity. Maybe they'll participate, but they likely won't.
> 
> Gentoo shines at bureaucratic load. That may be one of the only things
> Gentoo is really good at, needless bureaucratic loads that just slow things
> down and fracture the community, exherbo, funtoo, and likely others...

I was under the impression that Gentoo was chronically undermanned for even 
the workload it has.

> 
> This is not needless bureaucracy , this is necessary.

Opinion. Why is it necessary? What is it necessary for?

> 
> > Have you watched the IANA ports assignment registry over the years?
> > Consider how many services and tools you've seen that *don't* respect it.
> 
> Yes, how often to ports < 1024 change? Hardly ever Proving the exact
> point why this is needed. People can change them themselves but 99% of the
> time its to some other port > 1024.
> 
> Why is there IANA port assignment registry in the first place? Likely for a
> similar reason.

How relevant even *is* the <1024 distinction any longer? Once upon a time, the 
idea was you had to have special privileges to open those ports. Now, there is 
really no reason for anyone to care; capabilities-oriented permissions 
completely obviated the need, and I can only think of ssh, telnet and ftp and 
as server services that should require special host privileges to 
operate...and that's only because they may need to be able to call setuid().

And because the <1024 port privilege distinction has been so restrictive and 
bureaucratically sloggish, applications adapted to use ports above 1024. 
Games? Sync utilities? Proxy servers? Far more commonly-observed ports are 
above 1024 than below it, and many (most?) don't even get added to IANA's 
list. *That's* why the <1024 ports don't change much; the feature is obsolete, 
and users don't bother.

As an example, I just checked on Syncthing, to see if its three ports were on 
IANA's list. They're not, and I stumbled across a Github issue where the devs 
flatly stated they didn't care.

The IANA ports list is, by and large, obsolete. It became obsolete because it 
was too much a hassle for people to participate in.

> 
> > All of this is why we use identity management tools like LDAP in the first
> > place. Heck, it's why we have passwd and group files for mapping names to
> > ids and didn't simply hardcode system IDs decades ago.
> 
> LDAP typical manages user accounts not system. If the LDAP server is not
> reachable you would make a system completely nonfunctional if 

Re: [gentoo-dev] RFC: Userkit.eclass

[Michael Mol]

On Monday, November 28, 2016 02:39:48 PM William L. Thomson Jr. wrote:
> On Monday, November 28, 2016 10:42:54 AM EST Alec Warner wrote:
> > Generally speaking as a fellow who maintained thousands of systems (many
> > of
> > which ran various operating systems.)
> > 
> > You cannot rely on all OS vendors to synchronize uid / gid. You cannot
> > even
> > rely on some single vendors to synchronize uid / gids between releases of
> > their own products.
> 
> I believe the main reason such is the case is a lack of any such list or
> database for others to adhere to. Once again an area Gentoo could be
> leading. Had Gentoo done this years ago others might have adopted.
> 
> IMHO it is something that should be  a part of LSB. If not POSIX in general.
> One cannot really change the past or current state of things. But can make
> the future better.

Highly detailed lists like that--used as a broad standard--are a bad idea. 
They represent a single synchronization point that everyone must adhere to. 

That means that every prospective adjustment to the list requires active 
maintenance. That means that for every new daemon someone writes, they have to 
go through an admissions process. For every contentious fork of a project, you 
risk conflict over who the designated contact for the assignment should be.

It adds a large bureaucratic load on everyone. Every itch some developer 
thinks about scratching has to be weighed against engaging with some process-
laden entity. Maybe they'll participate, but they likely won't.

Have you watched the IANA ports assignment registry over the years? Consider 
how many services and tools you've seen that *don't* respect it.

And what is the list managing? A limited namespace, currently only 32 bits, 
but with tools like, say, Samba and sssd reserving large chunks for stable UID 
and GID mapping. One could argue that a stable list could obviate the need for 
some of that mapping, but you've got decades-old existing networks that aren't 
going anywhere, and you'll still need to interface with systems run by people 
who will deliberately run counter to such lists as a security layer, just as 
you interface with systems that run SSH or HTTP on nonstandard ports.

You'll still run into all of these issues and more if you try generalize the 
list to region allocation:

Say you try to assign regions for system daemons vs users, and you're on a 
host that interacts with two other hosts without full mutual trust. You're 
serving up a shared filesystem, and all three involved hosts each have a system 
daemon user and a system normal user with an object on that shared filesystem.

Presented with a directory listing showing the UIDs and GIDs for each object, 
how do you distinguish between the system user from each host? The two hosts 
shouldn't have access to each others' files, even if they use the same UID 
locally, because the two hosts don't trust each other.

That considered, how, then, how do you identify between another host's system 
user and its normal user, inasmuch as you can't let them collide with IDs on 
your own system, but are trying to ensure that their IDs get mapped into the 
correct local range?

That considered, what do you do when the Big List Maintainers add another 
region? How do you cope with another host that uses a newer version of that 
list? An older version? And now that you've upgraded, and the new version of 
the list says you should have mapped something somewhere else, what do you do 
with it? Do you even have enough information to know that an ID you mapped 
last year should have been in that other category?

And while we're talking about allocating ranges, we can start talking about 
limited address space. 32 bits seems like a lot of individual identities, but 
when you're carving it up into multiple masses of identities, you'll find it 
gets very small, very quickly. That's why IPv6 went with 128 bits instead of a 
64 bit address space.

All of this is why we use identity management tools like LDAP in the first 
place. Heck, it's why we have passwd and group files for mapping names to ids 
and didn't simply hardcode system IDs decades ago.

-- 
:wq

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

Re: [gentoo-dev] rsync.gentoo.org rsync modules: ChangeLogs dropped from gentoo-portage

[Michael Mol]

On Wednesday, November 16, 2016 05:59:50 AM Doug Freed wrote:
> On Wed, Nov 16, 2016 at 3:26 AM, Kent Fredric  wrote:
> > On Tue, 15 Nov 2016 01:11:48 +
> > 
> > So are we going to have a broken rsync tree for 4 days due to the manifest
> > validation failing on every package, resulting in no working upgrades for
> > 4 days?
> > 
> > Or has that problem been fixed?
> 
> Portage does not care if ChangeLog is missing on disk during Manifest
> checking, because its existence is completely irrelevant to the
> functioning of the package.

Kent was likely referencing this:


On 10/30/2016, in message <3d0d574c-63b1-cf2d-633f-d18495202...@gentoo.org>, 
Brian Evans wrote:

> We just had a user in #gentoo report that app-dicts/myspell-en had a
> mismatched ChangeLog size in Manifest that blocked him from installing
> software.

> So this does not seem to be treated as a warning for a MISC type.

-- 
:wq

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

Re: [gentoo-dev] Commented packages in the @system set

[Michael Mol]

On Thursday, October 27, 2016 09:21:06 AM Rich Freeman wrote:
> On Thu, Oct 27, 2016 at 9:07 AM, Michael Mol <mike...@gmail.com> wrote:
> > I want to +1 this, but I do see one problem: If all dependencies are
> > defined, how does "emerge --with-bdeps=y --emptytree @world" work?
> > Defining all dependencies means the graph is completely cyclic.
> 
> Well, we'll need to define some kind of stage1 set no matter what we
> do because of the bootstrapping problem.  Perhaps this can be
> leveraged when breaking cyclical dependencies (optimize as much as you
> can, allow parallel builds, but do the stuff in the stage1 set first
> and don't treat circular deps as show-stoppers).
> 
> And I don't think portage actually breaks today with circular deps as
> long as some start out satisfied.  If a depends on b and b depends on
> a, and both have an upgrade, but the dependencies are unversioned,
> then I think portage just does them in arbitrary order.  Now, if both
> have circular versioned dependencies and you don't have at least one
> installed, you're stuck (maybe a really clever portage might find
> earlier intermediate versions with relaxed dependencies that break
> this cycle, but I'd be surprised if that works today).
> 
> > Perhaps the answer is that it doesn't; you have to run 'emerge --emptytree
> > @world twice' if you want to ensure every package is rebuilt with its
> > newest available build dependencies.
> 
> Well, if your goal is completely consistent rebuilds you can't avoid
> the need to rebuild the stage1 set twice because of the bootstrapping
> problem (which I believe is why we have stage2).  A solution would be
> to first emerge the stage1 set, then do the emerge @world.  However,
> in practice I don't think there are many situations where you really
> need to do a rebuild of this scale.
> 
> I'm not saying you can completely avoid the need for having some kind
> of bootstrapping stage1.  I'm just saying we should separate that need
> from the issue of fully specifying dependencies, at least in an ideal
> world where we're unconcerned with the effort of specifying
> dependencies.

So, what goes in @stage1? What's the bare minimum needed for a Gentoo package 
kernel?

-- 
:wq

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

Re: [gentoo-dev] Commented packages in the @system set

[Michael Mol]

On Wednesday, October 26, 2016 11:14:53 PM Rich Freeman wrote:
> On Wed, Oct 26, 2016 at 10:54 PM, Walter Dnes  wrote:
> > On Thu, Oct 27, 2016 at 01:10:10AM +, Peter Stuge wrote
> > 
> >> waltd...@waltdnes.org wrote:
> >> > For a build-from-source distro like Gentoo, gcc and associated
> >> > tools are a vital part of the distro.
> >> 
> >> A stage4 created (and updated) on a catalyst build farm doesn't need
> >> to have gcc, but may still need libstdc++.
> >> 
> >   That just moves the requirement for gcc+tools to the catalyst build
> > 
> > farm.  OK, let's get specific... a *STANDALONE* Gentoo machine requires
> > gcc+tools.
> 
> This is why I think "@system" oversimplifies all of this.  IMO we
> should just specify all dependencies for everything (and those could
> include some virtuals for convenience, like the C toolchain), and then
> have different sets or virtuals for convenience.  By all means give a
> user with a default install that sticks virtual/common-packages or
> something in their @world.  Nobody is arguing that the typical Gentoo
> user doesn't want gcc, or that we should force people to explicitly
> install it.
> 
> Fixing the dependencies means that system packages can take advantage
> of parallel builds, which means faster updates for everybody.  We can
> still have sets for bootstraping (and I suspect that having more
> virtuals or sets would allow stage1/2 definition to be simplified).
> 
> It is a bit like license groups.  We give everybody a default set of
> license groups that generally makes sense.  But, if you want you can
> easily edit your make.conf to exclude anything that is copyleft from
> your system.
> 
> The main downside to this is it is a bit more of a hassle for
> developers to maintain the dependency lists, since invariably you end
> up with a lot of mundane stuff in there.  And of course it is a lot of
> change to implement, though it could be done gradually.  And of course
> the upside for the typcal user is somewhat limited, since most people
> aren't dying to uninstall openssh or gcc.

I want to +1 this, but I do see one problem: If all dependencies are defined, 
how does "emerge --with-bdeps=y --emptytree @world" work? Defining all 
dependencies means the graph is completely cyclic.

Perhaps the answer is that it doesn't; you have to run 'emerge --emptytree 
@world twice' if you want to ensure every package is rebuilt with its newest 
available build dependencies.

I'll sometimes do an "emerge -e @world" twice following a compiler upgrade or 
CFLAGS or LDFLAGS change.

-- 
:wq

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

Re: [gentoo-dev] Package file name requirement for binary ebuilds

[Michael Mol]

On Monday, October 17, 2016 03:37:28 AM William L. Thomson Jr. wrote:
> On Monday, October 17, 2016 8:57:30 AM EDT Michał Górny wrote:
> > On Sun, 16 Oct 2016 18:30:44 -0400
> > 
> > "William L. Thomson Jr."  wrote:
> > > Part of the idea is to help differentiate the types of binaries in tree
> > > to
> > > hopefully get less binaries that are from source.
> > > 
> > > To start I just wanted to see about a policy for -bin, the other stuff
> > > was
> > > just extra after -bin itself was a policy. Unless it made sense to
> > > develop
> > > it in full,
> > > 
> > > -bin - Closed source binary ebuild
> > > -ebin - Self made binary from source
> > > -sbin - Binary ebuild of an open source package
> > 
> > Let's also add -c for C programs, and -cxx for C++ programs. -py for
> > pure Python stuff, -cpy when stuff includes extensions compiled in C,
> > -cxxpy extensions in C++. We should also have special -x86asm suffix
> > for packages that rely on non-portable x86 assembly, or maybe even
> > -x86asm-sse when they use some fancy instruction sets. And then don't
> > forget to add a suffix for license, for GUI library (because obviously
> > nobody wants GTK+ software on KDE systems, nor GTK+3 software on GTK+
> > systems).
> 
> Clearly being sarcastic as a binary is a binary. It doesn't matter what
> language, toolkit etc.

And what about when a package is mixed? When it has a closed firmware blob, or 
a statically-linked helper utility? Often, you'll see that stuff get unbundled, 
but does that even make sense when the blob or helper utility is only used by 
that package?

-- 
:wq

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

Re: [gentoo-dev] Package file name requirement for binary ebuilds

[Michael Mol]

On Monday, October 17, 2016 03:52:52 PM Kristian Fiskerstrand wrote:
> On 10/17/2016 03:47 PM, M. J. Everitt wrote:
> > On 17/10/16 14:44, William L. Thomson Jr. wrote:
> >>> If a binary package is provided in addition to its source-based
> >>> equivalent, the name of the former should be suffixed with '-bin'
> >>> for distinction."
> >> 
> >> Essentially what I would like to see in policy yes. Though it does not
> >> address the problem of identifying packages that can be built from
> >> source, that get put in tree as binary, for what ever reason.
> > 
> > Perhaps you can compile a list of such packages, as I would imagine QA
> > would be interested as to how 'widespread' this problem really is?
> 
> Off the top of my head I'm only aware of libreoffice-bin myself (and
> then it is a clear alternative to libreoffice if wanting the source),
> providing this as a binary is a convenience to end-users not wanting to
> spend 50 minutes on the compile.

There's also firefox-bin, which gets built upstream with profile-guided 
optimizations enabled. PGO is unsupported outside of upstream's build process, 
last I checked...but that was a few years ago.

-- 
:wq

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

Re: [gentoo-dev] Re: Package up for grabs: skencil

[Michael Mol]

On Friday, September 16, 2016 09:54:42 PM Duncan wrote:
> Kristian Fiskerstrand posted on Fri, 16 Sep 2016 14:58:22 +0200 as
> 
> excerpted:
> > On 09/16/2016 02:31 PM, Hanno Böck wrote:
> >> media-gfx/skencil is a python-written vector graphics tool. It was once
> >> popular before inkscape became the de-facto-standard. It hasn't seen
> >> any upstream activity for a decade(!), but surprisingly it still seems
> >> to work.
> >> 
> >> I haven't used it for many years myself.
> >> 
> >> There are 4 open bugs in bugzilla.
> >> 
> >> Anyone interested in taking it? (else the usual: will be reassigned to
> >> maintainer-needed)
> > 
> > Also sounds like a candidate for treecleaning / moving to an overlay and
> > not keeping non-upstream maintained things in tree if nobody want to
> > take the maintainer burden of it.
> 
> Why treeclean it, if it still works and can still be built against in-
> tree python?
> 
> Sometimes mature packages don't get further maintenance because they
> "just work" as they are, and don't _need_ to eventually be bloated to
> include email and browsing functionality or whatever.
> 
> Of course if it requires old python and eventually the last supported in-
> tree python is being removed, and nobody steps up to update it then,
> /then/ it should be removed from the tree as it'll be broken /then/, but
> that's not the case now, as Hanno explicitly said it still seems to work.

It needs a maintainer. Are you offering?

Packages without maintainers anywhere along the line (either local or 
upstream) risk having security vulnerabilities go unfixed (or even 
unacknowledged) simply from having nobody who actually cares about the 
package. Very little "just works", even if it appears to, after a decade or 
two of little to no modifications or maintenance, if only because hidden 
assumptions the software makes about its environment cease to hold true.

So long as it continues to "just work", the work involved in being a proxy 
maintainer should be next to nil. If it doesn't continue to just work, then at 
least you have a better idea about what's going on...you might even find 
effective ways to deal with the problem, either by fixing the package yourself 
or providing backpressure on the environment changes that have broken (or 
threaten to break) it.

-- 
:wq

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

[gentoo-dev] Duplicate bug reports, resolution status and Bug 426262

[Michael Mol]

(First, I don't care how the autoconf.in-autoconf.ac migration is
handled at a code level. This isn't about that. I'd appreciate if that
were largely handled in a separate thread. This (I think) is about
policy around bug reporting.)

Timeline:

1) *Bug 426262* https://bugs.gentoo.org/show_bug.cgi?id=426262 was filed
2) SpanKY mailto:vap...@gentoo.org
committedhttp://sources.gentoo.org/eclass/autotools.eclass?r1=1.165r2=1.166
, and marked #426262 RESOLVED/FIXED, with the intent of flushing out
configure.in use cases.
http://sources.gentoo.org/eclass/autotools.eclass?r1=1.165r2=1.166
3) I hit SpanKY's eqawarn, and filed #530478.
4) Jer marked #530478 as a dupe of #426262, which was still marked #426262.
5) Being the only one who's apparently filed anything following this
eqawarn, I kicked off an emerge -e @world to trawl for more use cases on
my system. (I'd rather not have my system break when autotools is
eventually upgraded.)

(then there's a spat between Justin Lecher and Jer, but that's not
relevant yet.)

I'm confused about two things.

First, if something is supposed to have attention paid to it (which I
take to be the purpose of the eqawarn), I don't see how it makes sense
for bug reports responding to the eqawarn to be marked as duplicate of a
bug that's in the RESOLVED/FIXED state; who's going to pay attention to
that, in the general case? (In this case, Justin saw it, unmarked the
dupe, set up a tracker for the issue and marked my bug as a blocker for
that.)

Second, having my bug report marked as a dupe of one already in the
RESOLVED/FIXED state tells me that my bug report was a waste of time.
Reading the content of #426262 suggests to me that any further filings
will also be marked as duplicates of the RESOLVED/FIXED bug, and thus
also wastes of time. I don't mind burning a few CPU cycles if it's
useful, but if it's just going to waste time, there's obviously no
point, and I should kill the emerge I started.

So...could I get some clarification here? I don't get the dupe-marking
pattern, and I don't know whether or not I should kill off my emerge -e.
http://sources.gentoo.org/eclass/autotools.eclass?r1=1.165r2=1.166

Re: [gentoo-dev] robo-stable bugs

[Michael Mol]

On 05/22/2013 08:53 AM, Ian Stakenvicius wrote:
 On 21/05/13 07:43 PM, Thomas Sachau wrote:
  [ Snip reasons for why opt-out is bad ]

 So why don't we add something to package metadata, to indicate that a
 package is OK to be considered for auto-stabilization??  It lets
 everyone opt-in, and we still have the opportunity to opt-out if we
 want to at stable-bug-request time (or better, the dev can file their
 own bug to indicate stabilization will not occur or will occur later
 once XYZ are met or w/e)..

 We include it in the default metadata.xml template going forward, and
 request all dev's add it to their packages if they want to contribute.

 Thoughts?

 (Note:  I also recall there being some sort of blacklist mentioned,
 where is the info for that stored? IE, how could I put a package in
 that blacklist?)



I was thinking something similar yesterday, except I'd rather it be seen
as opt-out rather than opt-in.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] robo-stable bugs

[Michael Mol]

On 05/22/2013 11:00 AM, Jeroen Roovers wrote:
 On Wed, 22 May 2013 08:53:06 -0400
 Ian Stakenvicius a...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 21/05/13 07:43 PM, Thomas Sachau wrote:
 [ Snip reasons for why opt-out is bad ]
 So why don't we add something to package metadata, to indicate that a
 package is OK to be considered for auto-stabilization?
 Package or ebuild or SLOT or what? Please explain what these
 metadata.xml entries should look like. Also, since we're working per
 ebuild, and not per package, why couldn't we include this in each
 individual ebuild? What happens when you've set the variable, tag or
 whatever, and then an obscure bug pops up (and you're not CC'd because
 the bug appears in a dependent package three branches removed) and
 then your robo-call comes in for that ebuild?

 It's a neat idea, but the red tape would stretch to Alpha Centauri and
 back. IOW, it's hardly maintainable unless you can afford the espresso
 machine and all of your spare time. Common sense and proper research
 usually cuts that short. Automating CC'ing arch teams would probably
 only catch this in a very late stage, if at all in time before an
 ebuild is deemed stable.


  jer


My expectation is that something in metadata.xml would operate
*per-package* to allow the maintainer of that package to say hey, let
me do my own thing here. Trying to set those values per-ebuild sounds
like a bug farm as those values are accidentally set wrong from time to
time. Then you try writing something to automate the maintainer side of
things, and you've got more lines of (theoretically possibly buggy) code
to worry about.

let me do my own thing here would start off as don't touch my
packages. Trying to plan more granularity than that at the outset seems
a lot like trying to tell the future.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Making systemd more accessible to normal users

[Michael Mol]

On 05/20/2013 11:34 PM, Canek Peláez Valdés wrote:
 On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell dlcampb...@gmx.com
 wrote:

[snip]

 That's missing the point. If you don't run systemd, having unit 
 files is pointless. Thankfully there's INSTALL_MASK and whatnot, 
 but that seems like a hack instead of something more robust. Why 
 include systemd unit files (by default, with no systemd USE flag, 
 thanks to the council...) on a system that's not using it? 154 
 files isn't negligible unless you're flippant with your system and
  don't care about bloat. Unused software sitting around *is* a 
 waste of disk-space.
 
 Unit files are not software; they are data.

That's like saying shell scripts are not software, they are data. Unit
files, semantically and collectively, are a system-behavior-defining set
of interpreted modules written in a declarative language. In fact,
that's what makes them even remotely appealing, on comparison to
shell-based init scripts; they make declarations of requirements, the
what, and leave it to the system resolver to work out the how.

(It's from this perspective that I like the idea of using unit files as
a point of origin for *generating* init configurations like systemv,
openrc or runit scripts. You'd be compiling the init script for the
target init system, and your result should be more robust for it.)

 
 And I believe you are the one missing the point. I don't run OpenRC;
  I don't need no files in /etc/init.d. But you don't see me (nor any
  other systemd user) complaining about pointless scripts in 
 /etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with
 my life.
 
 Non-systemd users should do the same for files under 
 /usr/lib/systemd, if they really are that worried about systemd 
 infecting their systems. Complaining about a council-decided policy
 (and, I believe, backed up by the developers that matter, including
 the OpenRC maintainers) is just beating on a dead horse.

The push to keep USE flags specific to enabling and disabling program
features seems weird to me; the semantics of USE flags seem valuable for
a great deal more than that.

 
 Get over it.
 
 Some people (like myself) came to Gentoo to avoid putting systemd 
 on their systems and to make use of the great choice that Gentoo 
 allows. This push to make systemd a first level citizen or 
 whatever reeks of marketing.
 
 If Gentoo is about choice, then systemd is one of those choices.

This I take no issue with.

 And systemd will become a first class citizen inside Gentoo, like it
  or not.

...

 Support for it has been getting better and better, and more and more 
 Gentoo users are running with systemd.

And users are switching to eudev and mdev as well. Personally, I think
heterogeneity is a good thing...That's a huge part of why I like Gentoo;
it's a crucible for open-source software that tends to bring breakages
in edge-case (but theoretically supported) configurations to upstream
attention.

 
 If  some fundamentalists

...

 users don't want even one file in their systems with systemd on
 their paths, they can install eudev/mdev, put the necessary
 directories in INSTALL_MASK, and do the extra work. If some other
 fundamentalists users (like myself) don't want even one OpenRC
 related file on our systems, we can create an overlay to remove the
 dependency of baselayout on OpenRC, put /etc/init.d in INSTALL_MASK,
 and do the extra work.
 
 Neither case covers the average systemd/OpenRC user, who doesn't
 care about a few scattered files in /etc/init.d nor /usr/lib/systemd,
 and just want to run her machine with the init system of her choice.
 If Gentoo is really about choice.

It is, and it should be.

 
 If there is desire among users for unit files, they can contact 
 upstream or maintain their own set of unit files. It's not like 
 they're hard to write.
 
 So, Gentoo is about choice, but only for the choices you agree with.
  Great.

Nobody says the devs must do whatever the users demand of them; the devs
are unpaid.

The best arguments in this thread, to my eye, have been to encourage
devs to accept user-contributed unit files.

As users, you and I can't force devs to do anything. But we can always
pull up our sleeves and dig in ourselves.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Making systemd more accessible to normal users

[Michael Mol]

On 05/21/2013 09:50 AM, Ciaran McCreesh wrote:
 On Tue, 21 May 2013 04:45:12 + (UTC)
 Duncan 1i5t5.dun...@cox.net wrote:
 But the point you're missing is that INSTALL_MASK is NOT a hack.
 
 Sure it is. It's a hack and remains a hack until there's a way of using
 it without risk of breakage.
 

That's a silly requirement. Every time I sit down with one of my systems
and start playing/exploring (If I've gone a month without getting
somewhat competent with something completely new to me, it's been a bad
month) with USE flags, I break my system with within hours. USE flags
are awesome at what they do, and they're incredibly robust, but that
doesn't mean that toggling features on and off isn't dangerous.

On a working system, *anything* you might touch in
/etc/portage/make.conf carries with it the risk of breakage. This is
what makes Gentoo a place for people who are willing to get their hands
dirty understanding how their system works.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Making systemd more accessible to normal users

[Michael Mol]

On 05/21/2013 10:02 AM, Ciaran McCreesh wrote:
 On Tue, 21 May 2013 09:57:53 -0400
 Michael Mol mike...@gmail.com wrote:
 On 05/21/2013 09:50 AM, Ciaran McCreesh wrote:
 On Tue, 21 May 2013 04:45:12 + (UTC)
 Duncan 1i5t5.dun...@cox.net wrote:
 But the point you're missing is that INSTALL_MASK is NOT a hack.

 Sure it is. It's a hack and remains a hack until there's a way of
 using it without risk of breakage.

 That's a silly requirement. Every time I sit down with one of my
 systems and start playing/exploring (If I've gone a month without
 getting somewhat competent with something completely new to me, it's
 been a bad month) with USE flags, I break my system with within
 hours. USE flags are awesome at what they do, and they're incredibly
 robust, but that doesn't mean that toggling features on and off isn't
 dangerous.
 
 And you're reporting bugs for all these missing or automagic
 dependencies, right?
 

Actually, yes.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Making systemd more accessible to normal users

[Michael Mol]

On 05/18/2013 03:23 PM, Carlos Silva wrote:
 Is the real problem just the god damn unit/init files?! Damn, who cares
 about 2KiB files in the age of GiBs?! You can install 1000 of them that
 it will only take 2MiB of storage, so please, quit complaining about this.

Practically speaking, I think the problem is likely more about the inode
usage than the physical size of the files. With today's huge disks, the
problem does seem to be becoming the cost of metadata over the cost of
the data itself. (Why else would we need sectors larger than 512 bytes?)

 
 One thing dev's should take care is (not that affects me, 'cause I
 really don't care) is mentions to rc-update on einfo's. Again, I really
 don't care, but, for the sake of making them (openrc, systemd, etc)
 equal, that really shouldn't be mentioned.

[snip]




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Making systemd more accessible to normal users

[Michael Mol]

On 05/08/2013 11:39 AM, Chí-Thanh Christopher Nguyễn wrote:
 Ben de Groot schrieb:
 On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote:
 It looks like there is some consensus on the effort of making systemd
 more accessible, while there are problems with submitting bugs about
 new systemd units of the sort that maintainers just_dont_answer(tm).
 In this case, I am just giving 3 weeks grace period for maintainers to
 answer and then I usually go ahead adding units (I'm in systemd@ after
 all).
 In my opinion you should not be asking maintainers to add systemd
 units to their packages. They most likely do not have systems on which
 they can test these, and very few users would need them anyway. I
 would think it is better to add them to a separate systemd-units
 package.
 
 Note that a similar thing is already done with the selinux policy packages.
 
 Mostly the complaints against adding systemd units are that it would
 unnecessarily clutter non-systemd installs. Users who complain are told
 to set INSTALL_MASK but that is somewhat unwieldy.
 
 A separate package for the unit file would solve this problem nicely.

Correct me if I'm wrong, but isn't your average ebuild file larger than
your average systemd unit file?

 Another option would be to add a dounit command to a future EAPI (like
 doinitd today) and make portage install them unless FEATURES=nounit
 (like nodoc/noinfo/noman today).

I'm beginning to warm up to the idea of replacing most init scripts with
systemd unit files and a unit-init converter. This is obviously
nonsense if upstream provides init scripts, but I'm unsure how common
that is. (or even could be)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Making systemd more accessible to normal users

[Michael Mol]

On 05/08/2013 01:08 PM, Michał Górny wrote:
 On Wed, 8 May 2013 23:26:57 +0800
 Ben de Groot yng...@gentoo.org wrote:
 
 On 1 May 2013 18:04, Fabio Erculiani lx...@gentoo.org wrote:
 It looks like there is some consensus on the effort of making systemd
 more accessible, while there are problems with submitting bugs about
 new systemd units of the sort that maintainers just_dont_answer(tm).
 In this case, I am just giving 3 weeks grace period for maintainers to
 answer and then I usually go ahead adding units (I'm in systemd@ after
 all).

 In my opinion you should not be asking maintainers to add systemd
 units to their packages. They most likely do not have systems on which
 they can test these, and very few users would need them anyway. I
 would think it is better to add them to a separate systemd-units
 package.
 
 How would that package handle unit files differing per package
 versions? For example, changed options, relocated executables...

It would effectively need to be bumped every time any package added,
removed or changed a unit file requirement. Also every time a unit
file-bearing package is added or removed from tree.

That would be one insanely hot package.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] OpenRC supporting systemd units

[Michael Mol]

On 05/08/2013 03:18 PM, Jeroen Roovers wrote:
 On Wed, 8 May 2013 20:55:35 +0200
 Ambroz Bizjak ambr...@gmail.com wrote:
 
 Init.d scripts are programs - they could probably do just about
 anything.

 They couldn't monitor a process and restart it when it crashes, as
 specified by the restart options in the unit file. That is, without
 significant modifications in the way OpenRC works, such as adding a
 monitoring process, or hacks such as launching a daemon that monitor
 that process specifically.
 
 Sounds like a great feature. A crashed process is a buggy one, and I
 would want to investigate said program before I relaunched it, and not
 have it automatically relaunched as if nothing had happened.

That's highly, highly, highly use-case dependent. If it's a non-critical
service, or in a non-critical environment, that's one thing. If it's a
service whose downtime can be measured in value lost, that's quite another.

I've had setups where, yes, I had it respawn. But I also wanted it to
send me a core dump so I could investigate. Were I in that circumstance
again, I'd automate collection and analysis of the dumps to produce heat
maps for me.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] OpenRC supporting systemd units

[Michael Mol]

On 05/08/2013 04:06 PM, Chí-Thanh Christopher Nguyễn wrote:
 Michael Mol schrieb:
 Sounds like a great feature. A crashed process is a buggy one, and I 
 would want to investigate said program before I relaunched it, and
 not have it automatically relaunched as if nothing had happened.

 That's highly, highly, highly use-case dependent. If it's a
 non-critical service, or in a non-critical environment, that's one
 thing. If it's a service whose downtime can be measured in value lost,
 that's quite another.
 
 You could be looking at someone trying to compromise your system through a
 buffer overflow or similar vulnerability. If you enable automatic respawn
 then congratulations, you just gave the attacker unlimited tries to guess
 the correct address/offset for his exploit.

Without respawn, you're already bending over and taking a DoS. And when
you're in a situation where service uptime is a cap on  revenue, uptime
is pretty darn important.

That's not to say analyzing the crash isn't important, but if I allowed
a prod service to remain down while I investigated a crash, studied the
problem, evaluated a fix for correctness and lack of regressions,
scrubbed the fix and tried again, I wouldn't have that job for very long!

Certainly there are environments where it's sensible to take things slow
while you investigate (OpenVPN crashed? ssh crashed?), but there are
environments where that's not the case, too. It depends on your threat
model and a variety of cost/analysis factors. That's why I said highly,
highly, highly use-case dependent.

If upstream provides a unit file, and that unit file specifies a
behavior, you should (by default) trust the upstream. If you don't like
what upstream does, convince them to change. If they won't, make your
changes locally. If it's _really_ bad, obviously you have an interesting
position as a dev in a distribution, and you might make your change
there, but that certainly shouldn't be your default course of action.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages using -Werror

[Michael Mol]

On 05/03/2013 09:46 AM, Jeroen Roovers wrote:
 On Fri, 3 May 2013 16:06:01 +0800
 Ben de Groot yng...@gentoo.org wrote:
 
 Personally I've always thought -Werror is a mistake in release code,
 but was accepted practice. I've almost never actively removed it from
 packages I maintain. That will change now, upon learning of this
 policy.
 
 Debian here and there actively fixes compiler warnings by enabling
 -Werror and then checking what fails to build. I even see revision
 bumps because of some of the milder compiler warnings. Maybe other
 distros do this as well. It's kind of a blunt instrument to perform QA
 with, but I guess it does get code cleaned up slightly better than with
 no checks at all or by merely depending on runtime failures to be
 reported.

I'm sure it's intended by upstreams as a blunt QA instrument. I know at
least one project that operates in that way.

For Gentoo, this sounds like something that could be relegated to a
testing stage, but not enabled by default for end users.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Establishing Gentoo patch policy to keep our patches consistent and clean

[Michael Mol]

On Apr 6, 2013 2:36 PM, Alexandre Rostovtsev tetrom...@gentoo.org wrote:

 On Sat, 2013-04-06 at 20:08 +0200, Michał Górny wrote:
  2. Patches have to apply to the top directory of the source tree with
  'patch -p1'. If patches are applied to sub-directories, necessary '-p'
  argument shall be passed to 'epatch' explicitly. Developers are
  encouraged to create patches which are compatible with 'git am'.

 Please don't make -p1 into a hard requirement :/

 There are upstreams who have different directory layouts in their scm
 tree and in their source tarballs. If I clone an upstream git repository
 to obtain a patch or to write a new patch that I will submit upstream, I
 want to be able to apply that patch in an ebuild without having to
 manually sed it to change the -p level.

 Specific examples of this among packages that I maintain: app-cdr/cdemu,
 app-cdr/cdemu-daemon, sys-fs/vhba. These all use the same git tree, and
 source tarballs for individual packages are created from different
 subdirectories of that git tree.



It wouldn't be; you pass the p level in as an argument, if necessary.

Re: [gentoo-dev] libpng 1.6 upgrade and subslotting (and misuse of subslotting when there is also normal slotting)

[Michael Mol]

On 04/05/2013 04:44 PM, Samuli Suominen wrote:
 libpng 1.6 is in portage, but temporarily without KEYWORDS, pending on
 testign and this conversion, help would be much appericiated with
 converting the tree to use automatic rebuilds for the upgrade
 
 Because there is binary-only SLOT=1.2 of libpng, none of these are
 correct:
 
 $ grep -r 'media-libs/libpng.*:=' */*/*.ebuild
 app-misc/tracker/tracker-0.14.4.ebuild:=media-libs/libpng-1.2:=
 app-misc/tracker/tracker-0.14.5.ebuild:=media-libs/libpng-1.2:=
 app-misc/tracker/tracker-0.16.0.ebuild:=media-libs/libpng-1.2:=
 app-misc/tracker/tracker-.ebuild:=media-libs/libpng-1.2:=
 media-gfx/digikam/digikam-3.0.0.ebuild:media-libs/libpng:=
 media-gfx/digikam/digikam-3.1.0.ebuild:media-libs/libpng:=
 media-plugins/gst-plugins-gl/gst-plugins-gl-0.10.3.ebuild:
=media-libs/libpng-1.4:=
 media-plugins/gst-plugins-libpng/gst-plugins-libpng-1.0.5.ebuild:RDEPEND==media-libs/libpng-1.4:=
 
 media-plugins/gst-plugins-libpng/gst-plugins-libpng-1.0.6.ebuild:RDEPEND==media-libs/libpng-1.4:=
 
 www-client/chromium/chromium-27.0.1453.12.ebuild:media-libs/libpng:=
 www-client/chromium/chromium-27.0.1453.3.ebuild:media-libs/libpng:=
 www-client/chromium/chromium--r1.ebuild:media-libs/libpng:=
 
 They should all be :0= to avoid matching the :1.2 SLOT.
 
 Plus some hundreds are completely without subslotting:
 
 $ grep -r 'media-libs/libpng' */*/*.ebuild |grep -v ':.*='
 output - http://bpaste.net/show/89268/
 
 Thanks,
 Samuli
 

I'd love to help, but I haven't done much at all with ebuild munging. If
there's a list of basic translation instructions that would work for
most ebuilds, I could certainly knock off a few.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt : SOLVED

[Michael Mol]

On 04/01/2013 01:06 PM, Markos Chandras wrote:
 On 1 April 2013 16:32, Philip Webb purs...@ca.inter.net wrote:
 130401 Markos Chandras wrote:
 On 1 April 2013 02:56, Philip Webb purs...@ca.inter.net wrote:
 I have sent a msg to gentoo-user describing how to solve this problem.
 Perhaps it needs to be mentioned in the news item or wiki entry.
 So you broke the threading on the original email,
 you deleted all the previous content,
 you did not write an appropriate title for your e-mail
 and then you claim you solved a problem
 without mentioning what the problem was.

 Your response is completely out of place  very impolite.
 I am trying to help improve Gentoo documentation
  help other users who may face the same problem,
 but without taking unnecessary space on the dev-list.
 I am not happy with the way the Udev-200 update has been documented,
 but I haven't criticised the developer responsible.

 Please take the trouble to read what I sent to the user-list :

 
 Oh but of course. This was more than obvious. Posting something to
 gentoo-dev just to
 inform us that you posted something to gentoo-user without even
 mentioning the title.
 And then you claim that my reply is out of place. Ok

Is this a good time to point out that list archival is still broken? And
has been for almost a year?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Global useflags zeroconf and avahi

[Michael Mol]

On 04/01/2013 10:47 PM, Alex Xu wrote:
 Kill zeroconf and use dnssd, upnp, ssdp. Problem solved?

I very much like the approach in principle, though. Digging briefly into
Wikipedia[1], UPnP has several components:

* AutoIP (IPv4LL)
* SSDP (So, a separate ssdp USE flag may not be necessary)
* SOAP (If I read this correctly, this is the encoding of its RPC
  mechanism)
* GENA (A pub/sup architecture)

(For those that read the link, I'm obviously leaving out the
'Description' section...I don't know what that would be called, really.)

I don't know enough about real-world use of UPnP to say which of these
components are most fruitfully separated out of UPnP, USE-wise. If I had
to guess, I'd probably suggest:

* Break out SSDP and AutoIP,
* Have UPnP imply SOAP and GENA
* Have UPnP depend on the enabling of SSDP and AutoIP.

Or tie all of it into a single USE flag and be left with 'upnp' and 'ssdp'.



[1]
https://en.wikipedia.org/w/index.php?title=Universal_Plug_and_Playoldid=543684744#Protocol



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: sys-apps/texinfo vs @system

[Michael Mol]

On 03/31/2013 06:19 AM, Ulrich Mueller wrote:
 On Sun, 31 Mar 2013, Duncan  wrote:
 
 Or maybe your intent was to either kill these deps or put them
 behind USE=doc as well?
 
 USE=doc doesn't look right for this, as it's normally used for large
 sized documentation. Something like USE=info might be better.
 
 Ulrich
 

I would second USE=info. I use info pages not infrequently, and it's
irritating when I'm on an unfamiliar system or distro, discover manpages
are present (but info pages aren't), and can't find the easy path
forward to get them installed.

USE=info would be superb, in that sense. USE=doc would be fine, too, IMHO.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt

[Michael Mol]

On 03/29/2013 08:20 AM, Samuli Suominen wrote:
 On 29/03/13 13:38, Diego Elio Pettenò wrote:
 On 29/03/2013 12:29, Samuli Suominen wrote:
 One you can control, the another you can't. So still not FUD.

 You do not really control it any more than the kernel. The fact that me
 and you can edit an udev ruleset to control it, does not mean that
 most users see it as a black box.
 
 I don't agree with that, /etc/udev/rules.d and overriding udev rules is
 very basic administration, very basic...

I'd love to believe that, but do you have any idea how many people
aren't familiar with it? It took a long time before the default response
to help, I've replaced my NIC or motherboard, and eth0 is gone! became
find and remove this line from
/etc/udev/rules.d/70-persistent-net.rules instead of remove
/etc/udev/rules.d/70-persistent-net.rules

Something else...I've not encountered *one* other person to use anything
other than the system-default names for NICs...except myself. And when
I've done it, and despite giving them descriptive names, other people
are completely flummoxed when they see my configurations. What's this
'wan', 'lan' and 'wifilan'? Where are eth0, eth1 and eth2?

And of those I've found who knew of the feature and knew how to use it,
none have ever felt motivated to use it except when hardware was replaced.

(Personally, I find the feature underused; I could easily see networks
benefiting from rules like any interface prefixed with 'p' is public
facing without the benefit of a firewall, any interface prefixed with
's' points to a SAN or any interface prefixed with a 'c' is touches a
network region where PCI-compliance rules are in effect.)

 I'll put a bit more trust on our users.
 
 The news item reads better. I would still either avoid showing the
 NET_PATH example or describe that that is not the final result because
 on a laptop, NET_PATH almost certainly will *not* match the final
 interface name:

 flame@saladin~ % udevadm test-builtin net_id /sys/class/net/eno1
 2/dev/null
 ID_NET_NAME_MAC=enx0026b9d7bf1f
 ID_OUI_FROM_DATABASE=Dell Inc
 ID_NET_NAME_ONBOARD=eno1
 ID_NET_LABEL_ONBOARD=en Onboard LAN
 ID_NET_NAME_PATH=enp0s25

 And I would not expect users to all go read the wiki and try to figure
 out why you said it would be named enp0s25 when it gets the name eno1.

 
 Nod.
 Attached new version again, more generic than before.
 Hope it'll do what it's meant to do... push users into right direction...
 It's not meant to be a complete documentation or rewrite of the upstream
 wiki page :-p
 Just a push...

I would probably replace this:

If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
a symlink to /dev/null, the new names will be disabled and kernel will
do all the interface naming, which will be random.

With something like this:

If /etc/udev/rules.d/80-net-name-slot.rules is a empty file, or if it's
a symlink to /dev/null, the new names will be disabled and kernel will
do all the interface naming, and the resulting names will vary by kernel
and hardware configuration, and may vary by kernel version.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Michael Mol]

On 03/14/2013 09:01 PM, Robin H. Johnson wrote:
 On Thu, Mar 14, 2013 at 05:14:15PM +0100, Michał Górny wrote:
 If that means doing an additional signature every time something is
 going to be committed, that sounds like an overkill. If we were to do
 something radical, I'd rather be in favor of disabling keyword
 expansion completely and finally being able to do sane commits.
 I foresee it as more of:
 IFF this commit will call GPG later, ensure the agent can access the
 secret key BEFORE trying to sign at the end.
 
 As to how to accomplish this, it's either a throwaway sig, or poking the
 agent protocol directly.
 

The only trouble with that is if the agent is configured to only unlock
keys for limited periods of time, then your initial check might catch
the agent when the key is still unlocked, but your subsequent call to
GPG comes after the timeout. I ran into this while trying to set up
automated signing of debian packages I was building.

All it really means, in a practical procedural sense, is that you need
to allow yourself a way to roll back anything you've been doing if that
later check fails.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Gentoo GPG key policies

[Michael Mol]

On 03/14/2013 11:18 PM, Robin H. Johnson wrote:
 On Thu, Mar 14, 2013 at 10:32:30PM -0400, Michael Mol wrote:
 As to how to accomplish this, it's either a throwaway sig, or poking the
 agent protocol directly.
 The only trouble with that is if the agent is configured to only unlock
 keys for limited periods of time, then your initial check might catch
 the agent when the key is still unlocked, but your subsequent call to
 GPG comes after the timeout. I ran into this while trying to set up
 automated signing of debian packages I was building.
 So Debian has a test-gpg function already? Do you know where in their
 codebase it is?

No idea; a build system I'd cobbled together at the time prodded
gpg-agent to get an interactive auth. The build-and-package step took
too long, leading to the timeout. And I apologize; I don't remember
exactly what I was doing to prod gpg-agent, and since it was for a prior
job, I did not retain any copies of any of the materials.

 
 All it really means, in a practical procedural sense, is that you need
 to allow yourself a way to roll back anything you've been doing if that
 later check fails.
 I think we'd do:
 - All repoman checks
 - initial file editing
 if two-phase commit:
 - test gpg
 - commit1
 - gpg sign
 - commit2
 if one-phase commit:
 - gpg test
 - gpg sign
 - commit1
 
 Unless commit1 took a really long time, the interval between the gpg
 calls should be very small.
 

Murphy's going to call in a long I/O hang somewhere. Race conditions are
hell manifest in systems.

Since I haven't been paying close attention to this thread, I'm missing
some context, but if you're commit1 and commit2 apply to a DVCS, you're
probably fine so long as you don't do a push between commit1 and
commit2, don't do a push if any earlier step failed, and do all this in
a temporary branch that never (as a branch) gets pushed upstream.

If you're not applying to a DVCS, then you risk interleaving commit1 and
commit2 with others' work anyway.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] kerberos, virtuals, rattling cages

[Michael Mol]

On Mon, Feb 25, 2013 at 2:21 AM, Matthew Thode
prometheanf...@gentoo.org wrote:
 On 02/24/13 20:25, Michael Mol wrote:
 (I really don't have time to actively participate on this list right
 now, but I believe that if I bring it up on b.g.o, I'll be directed
 here, so...)

 So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to
 enable kerberos system-wide on my server.

 No joy, as net-fs/nfs-utils has an explicit dependency on
 app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on
 app-crypt/heimdal (for reasons noted in bug 195703, comment 25).

 Questions:

 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3
 and kerberos demands that things with explicit dependencies on mit-krb5
 either be fixed or not used at all.

 I'm the first activity on bug 231936 in two years...could someone please
 look into that one?

 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them
 through a virtual? My suspicion is no, but I don't know enough about
 kerberos to say whether or not it would work, even as a hack.

 I'm sure explicit dependencies on mit-krb5 and heimdal will continue to
 crop up, so (and forgive the nausea this might cause) it might help to
 slot mit and heimdal, and have virtual/krb5 depend on the presence of at
 least one.

 so, read the thread so far, and I think you are over-complicating things
 with slotting.  I use kerberos at home (more or less just to learn it,
 worksforme, etc).  I chose MIT.  From what I understand MIT and heimdal
 are mutually exclusive (can not operate with eachother) and that heimdal
 is what windows uses.

I think they're effectively the same on the wire, but I'm not sure.
I'm studying the issue.


 What this seems to be is a simple case of blockers.  So, the quesiton
 is, are you going to be using kerberos in nfs? if not, masking the flag
 may be what works for you (in the short term at least).  Longer term it
 sounds like maybe seperate use flags are in order (or something, dunno).

It's the longer-term thing is what I'm interested in solving...and
smoothness of kerberos in Gentoo in general. SSO for a family network
would be very, very nice.


 I don't think samba will support MIT, since it's kinda windows focused.

 On another note, I can't find bug 231936.

Typo. Or dyslexia. Who know...

https://bugs.gentoo.org/show_bug.cgi?id=231396

--
:wq

Re: [gentoo-dev] Re: kerberos, virtuals, rattling cages

[Michael Mol]

On 02/25/2013 06:03 AM, Duncan wrote:
 Eray Aslan posted on Mon, 25 Feb 2013 10:02:49 +0200 as excerpted:
 
 I don't think samba will support MIT, since it's kinda windows
 focused.

 Ugh, no.  MIT is not windows focused
 
 ... But samba is...

Actually, no. That's why I've been so excited about Samba 4, and why I'm
setting it up at home. AD is actually a very powerful network
administration tool, and it's not necessary to think of it as a Windows
thing. Think of it more like a sane replacement of NIS, tying in NTP
and DNS management as well.

 
 
 As far as the thread in general goes, the question arises, if you're 
 running both samba and nfs, why?  They're both network-based-filesystems 
 that in theory at least should have reasonably similar functionality, so 
 an admittedly not particularly clueful reaction is if it hurts when you 
 do that, stop doing it.

It's incredibly rare to see a uniform enterprise network. Every one I've
witnessed is heterogenous. The reasons usually come in a mix of these
flavors:

1) There's no policy for homogeneity.
2) Department A does it one way, department B does it another way, and
both departments are largely autonomous.
3) There needs to be integration between system A and system B, and
neither of those systems can reasonably be expected to change from their
current state.
4) Someone mandated a solution that only supports X and Y, and it's
not worth the resources and risk of revamping the entire rest of the
network to meet that spec natively.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] kerberos, virtuals, rattling cages

[Michael Mol]

On 02/25/2013 12:48 PM, Michael Mol wrote:
 On Mon, Feb 25, 2013 at 2:21 AM, Matthew Thode
 prometheanf...@gentoo.org wrote:
 On 02/24/13 20:25, Michael Mol wrote:
 (I really don't have time to actively participate on this list right
 now, but I believe that if I bring it up on b.g.o, I'll be directed
 here, so...)

 So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to
 enable kerberos system-wide on my server.

 No joy, as net-fs/nfs-utils has an explicit dependency on
 app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on
 app-crypt/heimdal (for reasons noted in bug 195703, comment 25).

 Questions:

 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3
 and kerberos demands that things with explicit dependencies on mit-krb5
 either be fixed or not used at all.

 I'm the first activity on bug 231936 in two years...could someone please
 look into that one?

 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them
 through a virtual? My suspicion is no, but I don't know enough about
 kerberos to say whether or not it would work, even as a hack.

 I'm sure explicit dependencies on mit-krb5 and heimdal will continue to
 crop up, so (and forgive the nausea this might cause) it might help to
 slot mit and heimdal, and have virtual/krb5 depend on the presence of at
 least one.

 so, read the thread so far, and I think you are over-complicating things
 with slotting.  I use kerberos at home (more or less just to learn it,
 worksforme, etc).  I chose MIT.  From what I understand MIT and heimdal
 are mutually exclusive (can not operate with eachother) and that heimdal
 is what windows uses.
 
 I think they're effectively the same on the wire, but I'm not sure.
 I'm studying the issue.

For the record: On my system, the only two changes I had to make to
enable kerberos (largely) system-wide were:

1) mask net-fs/nfs-utils (it was only being brought in by the kerberos
flag, anyway)
2) mask dev-libs/openssl[kerberos]. See
https://bugs.gentoo.org/show_bug.cgi?id=459220

Both of those had explicit dependencies on app-crypt/mit-krb5. After
that, everything built fine for app-crypt/heimdal. (No idea how well it
works; I've still got a ways to go to prove/disprove any of that.)

My purpose in originating this thread isn't (and hasn't been) all about
getting AD operating correctly and pervasively. My purpose is in getting
the package dependencies for kerberos sanified and cleaned up. If that
means there are upstream issues, I can prod them, too, I suppose.

(I do still wonder what all breaks if assumption is allow mit-krb5 to
be installed, rather than heimdal.)



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] kerberos, virtuals, rattling cages

[Michael Mol]

(I really don't have time to actively participate on this list right
now, but I believe that if I bring it up on b.g.o, I'll be directed
here, so...)

So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to
enable kerberos system-wide on my server.

No joy, as net-fs/nfs-utils has an explicit dependency on
app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on
app-crypt/heimdal (for reasons noted in bug 195703, comment 25).

Questions:

1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3
and kerberos demands that things with explicit dependencies on mit-krb5
either be fixed or not used at all.

I'm the first activity on bug 231936 in two years...could someone please
look into that one?

2) Is it possible to slot mit-krb5 and heimdal instead of pulling them
through a virtual? My suspicion is no, but I don't know enough about
kerberos to say whether or not it would work, even as a hack.

I'm sure explicit dependencies on mit-krb5 and heimdal will continue to
crop up, so (and forgive the nausea this might cause) it might help to
slot mit and heimdal, and have virtual/krb5 depend on the presence of at
least one.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] kerberos, virtuals, rattling cages

[Michael Mol]

On 02/24/2013 09:48 PM, Alec Warner wrote:
 On Sun, Feb 24, 2013 at 6:25 PM, Michael Mol mike...@gmail.com wrote:
 (I really don't have time to actively participate on this list right
 now, but I believe that if I bring it up on b.g.o, I'll be directed
 here, so...)

 So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to
 enable kerberos system-wide on my server.

 No joy, as net-fs/nfs-utils has an explicit dependency on
 app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on
 app-crypt/heimdal (for reasons noted in bug 195703, comment 25).
 
 I'm not familiar with anyone using Kerberos on Gentoo. I use it on
 Ubuntu; but we do not use it with Samba (or at least, if we do, I am
 not aware of it.)

It's one of the core components of Active Directory, so anyone who puts
a Gentoo machine on an AD domain will likely be using it. I'm playing
around with Samba 4, which is supposed to have full support as a
standalone AD controller. An AD controller is effectively a central box
that manages and directs domain members to DNS (the host directory),
LDAP (the user and authorization directory) and Kerberos (the
authentication mechanism).

 

 Questions:

 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3
 and kerberos demands that things with explicit dependencies on mit-krb5
 either be fixed or not used at all.
 
 I'm fairly sure samba supports either kerberos implementation; is
 there something that makes you think differently?

The explicit dependency on app-crypt/heimdal in the ebuild, and comment
25 attached to b.g.o bug 195703. I've taken those at face value; I
haven't followed up on them myself.

 

 I'm the first activity on bug 231936 in two years...could someone please
 look into that one?

 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them
 through a virtual? My suspicion is no, but I don't know enough about
 kerberos to say whether or not it would work, even as a hack.

 
 I'm not following you here. 'slot' means a very specific thing. You
 are not actually suggesting we use SLOT, you simply want both versions
 of the library to be installed in one ROOT?
 
 I would not advocate this approach. You should strive to have only one
 kerberos implementation on a given machine.

I'm really not certain, to be honest. It was my impression that slots
allow for two different versions of a thing to be present on the same
system, and that their different sonames on the system would lead to
correct symbol resolution. (Although it would require that the soname
being sought be adjusted in a dependent program to target the version
required.)

Even if it works, I acknowledge it's a nauseating hack for the circumstance.

 
 I'm sure explicit dependencies on mit-krb5 and heimdal will continue to
 crop up, so (and forgive the nausea this might cause) it might help to
 slot mit and heimdal, and have virtual/krb5 depend on the presence of at
 least one.

 
 It is likely that explicit dependencies are wrong, and are just bugs.

This is what I found in the ebuild for net-fs/nfs-utils:

# kth-krb doesn't provide the right include
# files, and nfs-utils doesn't build against heimdal either,
# so don't depend on virtual/krb.
# (04 Feb 2005 agriffis)

Which I noted in a comment I attached to bug 231936 (relating to
net-fs/nfs-util).

In bug 195703 (relating to the samba-4 version bump), there's this:

Since samba 4 doesn't support mit-krb5, I think we shouldn't depend on
virtual/krb5 but instead directly on heimdal after the com_err.h problem
is fixed. in comment 25, dated 2009-11-24 23:07:18 UTC.

Directly responded to later by this:

Agreed. in comment 26, dated 2009-11-25 10:01:48 UTC





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: kerberos, virtuals, rattling cages

[Michael Mol]

On 02/24/2013 10:40 PM, Duncan wrote:
 Michael Mol posted on Sun, 24 Feb 2013 22:17:56 -0500 as excerpted:
 
 I'm not following you here. 'slot' means a very specific thing. You are
 not actually suggesting we use SLOT, you simply want both versions of
 the library to be installed in one ROOT?

 I would not advocate this approach. You should strive to have only one
 kerberos implementation on a given machine.

 I'm really not certain, to be honest. It was my impression that slots
 allow for two different versions of a thing to be present on the same
 system, and that their different sonames on the system would lead to
 correct symbol resolution. (Although it would require that the soname
 being sought be adjusted in a dependent program to target the version
 required.)
 
 The issue is in one's definition of two different versions of a thing.
 
 Slot, in the gentoo sense, has the meaning of two different versions of 
 the same package, say qt-3 (tho that's long out-of-tree, but alive in kde-
 sunset) and qt-4 and qt-5 (tho that's very new, but is or will soon be a 
 problem as more packages dep on it), where there'd ordinarily be file and/
 or functionality collisions, NOT two different packages containing the 
 same functionality, which is the extended meaning it appears you're 
 applying here, but which only confuses people when used within the gentoo 
 context.
 

My presumption was that both app-crypt/heimdal and app-crypt/mit-krb5
used the same binary names.

$ equery f app-crypt/mit-krb5|grep -e '\.so'|sed -e 's/\.so.*//'|sed -e
's/.*\///'|sort -u|grep -v debug
db2
encrypted_challenge
libgssapi_krb5
libgssrpc
libk5crypto
libkadm5clnt
libkadm5clnt_mit
libkadm5srv
libkadm5srv_mit
libkdb5
libkrb5
libkrb5support
pkinit

(on a different machine)

$ equery f app-crypt/heimdal|grep -e '\.so'|sed -e 's/\.so.*//'|sed -e
's/.*\///'|sort -u|grep -v debug
libasn1
libgssapi
libhcrypto
libhdb
libheimbase
libheimntlm
libhx509
libkadm5clnt
libkadm5srv
libkafs
libkdc
libkrb5
libroken
libsl
libwind
windc


The overlap between the two includes libkrb5, libkadm5clnt and
libkadm5srv. When I was thinking why not slots?, that was explicitly
the part I was thinking of.

The distinction between two versions of a thing, and two implementations
of a thing, is a thorny epistemological issue; extended meaning is
good way to put it. I've acknowledge that abusing slots in this way is
pretty vile. I don't really care to advocate it; I merely brought it up
as an alternative. (But it seems it's a difficult question to bridge.)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] kerberos, virtuals, rattling cages

[Michael Mol]

On 02/24/2013 10:46 PM, Alec Warner wrote:
 On Sun, Feb 24, 2013 at 7:17 PM, Michael Mol mike...@gmail.com wrote:
 On 02/24/2013 09:48 PM, Alec Warner wrote:
 On Sun, Feb 24, 2013 at 6:25 PM, Michael Mol mike...@gmail.com wrote:
 (I really don't have time to actively participate on this list right
 now, but I believe that if I bring it up on b.g.o, I'll be directed
 here, so...)

 So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to
 enable kerberos system-wide on my server.

 No joy, as net-fs/nfs-utils has an explicit dependency on
 app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on
 app-crypt/heimdal (for reasons noted in bug 195703, comment 25).

 I'm not familiar with anyone using Kerberos on Gentoo. I use it on
 Ubuntu; but we do not use it with Samba (or at least, if we do, I am
 not aware of it.)

 It's one of the core components of Active Directory, so anyone who puts
 a Gentoo machine on an AD domain will likely be using it. I'm playing
 around with Samba 4, which is supposed to have full support as a
 standalone AD controller. An AD controller is effectively a central box
 that manages and directs domain members to DNS (the host directory),
 LDAP (the user and authorization directory) and Kerberos (the
 authentication mechanism).
 
 Don't misunderstand, I know what all these things are ;)
 



 Questions:

 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3
 and kerberos demands that things with explicit dependencies on mit-krb5
 either be fixed or not used at all.

 I'm fairly sure samba supports either kerberos implementation; is
 there something that makes you think differently?

 The explicit dependency on app-crypt/heimdal in the ebuild, and comment
 25 attached to b.g.o bug 195703. I've taken those at face value; I
 haven't followed up on them myself.



 I'm the first activity on bug 231936 in two years...could someone please
 look into that one?

 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them
 through a virtual? My suspicion is no, but I don't know enough about
 kerberos to say whether or not it would work, even as a hack.


 I'm not following you here. 'slot' means a very specific thing. You
 are not actually suggesting we use SLOT, you simply want both versions
 of the library to be installed in one ROOT?

 I would not advocate this approach. You should strive to have only one
 kerberos implementation on a given machine.

 I'm really not certain, to be honest. It was my impression that slots
 allow for two different versions of a thing to be present on the same
 system, and that their different sonames on the system would lead to
 correct symbol resolution. (Although it would require that the soname
 being sought be adjusted in a dependent program to target the version
 required.)
 
 mit-krb5 and heimdal are separate packages. They both provide krb
 headers and kerb libraries. You could easily patch them to be on the
 same system. The problem with doing so is that packages are expecting
 only one set of kerberos headers and kerberos shared libraries.
 
 We have the 'eselect' framework for switching between 'providers'
 which we could use in this case (similar to say, the opengl libraries
 your system might use.) It is not clear to me if switching providers
 is at all safe in the kerberos instance, or if software built against
 mit-krb5 would crash if you pointed the loader at some heimdal shared
 objects.

Don't misunderstand, I know about eselect. ;)

And, yeah, I don't know if thunking/shimming/redirecting is safe in the
kerberos context. If it was, there should never have been any question
of compatibility.

 

 Even if it works, I acknowledge it's a nauseating hack for the circumstance.


 I'm sure explicit dependencies on mit-krb5 and heimdal will continue to
 crop up, so (and forgive the nausea this might cause) it might help to
 slot mit and heimdal, and have virtual/krb5 depend on the presence of at
 least one.


 It is likely that explicit dependencies are wrong, and are just bugs.

 This is what I found in the ebuild for net-fs/nfs-utils:

 # kth-krb doesn't provide the right include
 # files, and nfs-utils doesn't build against heimdal either,
 # so don't depend on virtual/krb.
 # (04 Feb 2005 agriffis)

 Which I noted in a comment I attached to bug 231936 (relating to
 net-fs/nfs-util).

 In bug 195703 (relating to the samba-4 version bump), there's this:

 Since samba 4 doesn't support mit-krb5, I think we shouldn't depend on
 virtual/krb5 but instead directly on heimdal after the com_err.h problem
 is fixed. in comment 25, dated 2009-11-24 23:07:18 UTC.

 Directly responded to later by this:

 Agreed. in comment 26, dated 2009-11-25 10:01:48 UTC



 
 So nothing recent then ;p

Which is exactly why I bring it up; the net-fs/nfs-utils bug is stale,
and the reference in the samba package is ancient. (Things directly
partaining to samba-4 get bounced into that bug, which really means a
stale

Re: How a proper server profile should look like (was: Re: [gentoo-dev] removing the server profiles...)

[Michael Mol]

On Jan 17, 2013 3:35 AM, Dirkjan Ochtman d...@gentoo.org wrote:

 On Thu, Jan 17, 2013 at 3:23 AM, Walter Dnes waltd...@waltdnes.org
wrote:
If someone wants a *REALLY* basic system, they can start off with
  USE=-* and add on stuff as necessary when portage complains and/or
  ebuilds break.  That's what I'd recommend to someone wanting to set up a
  basic server machine.

 Yeah, but that sucks with USE_EXPAND. For example, I sure want some
 version of Python installed, but setting USE=-* removes all support
 for Python versions and has me add them one by one. I guess I could do
 that, but now I always have to keep up to date myself, which sucks.

 Cheers,

 Dirkjan


My thought is that base should have just enough enabled for stage3 to be
self-hosting. Moving existing base to something like common would retain
a profile for that most people would want this set.

Re: [gentoo-dev] removing the server profiles...

[Michael Mol]

On Wed, Jan 16, 2013 at 8:32 AM, Panagiotis Christopoulos
pchr...@gentoo.org wrote:
 On 00:36 Wed 16 Jan , Andreas K. Huettel wrote:
 several people have pointed out to me that the 10.0 - 13.0 transition would
 be a good moment to finally remove the (also in my opinion rather useless)
 server profiles.


 The server profiles are not useless, if we can maintain them, and if
 they actually are, nowadays, they shouldn't be.

 -1, unless other profile options being offered are minimal enough for the 
 job
 and enabling certain things that someone may need in a server.

The problem, I think, is that 'server' is a very generic thing. Am I
looking for a NAS? A SAN? A web server? A proxy server? An X11
application server? A font server? VOIP?

If people who use the server profile are looking for a minimalist
profile, I think they'd probably be best served with a profile that's
specifically designed for we disable everything we can to still wind
up with a working stage 3. Enable what you need from there.

That also suggests a way to help automate maintenance; if building a
stage 3 with the minimal profile fails, then either the package has a
bug or the profile needs an update...with a strong bias toward the
former.

-- 
:wq

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Michael Mol]

On Sun, Jan 6, 2013 at 8:54 PM, Zac Medico zmed...@gentoo.org wrote:
 On 01/06/2013 05:36 PM, Michael Mol wrote:

 On Jan 6, 2013 8:32 PM, Zac Medico zmed...@gentoo.org
 mailto:zmed...@gentoo.org wrote:

 On 01/06/2013 01:04 AM, Ralph Sennhauser wrote:
  On Fri, 4 Jan 2013 23:34:59 -0600
  Donnie Berkholz dberkh...@gentoo.org mailto:dberkh...@gentoo.org
 wrote:
 
  On 10:26 Sat 22 Dec , Pacho Ramos wrote:
  Hello
 
  After seeing:
  https://bugs.gentoo.org/show_bug.cgi?id=440214
 
  Looking to a lot of its blockers shows that we are using elog
  messages for informing people about configuration (like pointing
  people to external links to get proper way of configuring things,
  tell them to add to some system groups...). I thought that maybe
  this kind of information could be simply included in a canonical
  file under /usr/share/doc/ package dir called, for example,
  CONFIGURATION or SETUP. We would them point people (now with a news
  item, for the long term provably a note to handbook to newcomers
  would be nice) to that file to configure their setups. The main
  advantages I see:
  - We will flood less summary.log ;)
  - The information to configure the package is always present while
  package is installed, now, if we remove merge produced logs, people
  will need to reemerge the package or read directly the ebuild
 
  What do you think?
 
  Bikeshedding ... would go with README.gentoo, because people are
  already used to looking for README files. Every time we can eliminate
  Gentoo-specific weirdness, we should.
 
 
  See the documentation for README.Debian[1], most importantly the
  example. ;)
 
  I'd say we should handle it the same as Debian does.

 README.gentoo sounds good to me.

  What could we possibly gain from doing it differently?

 Does Debian have a postinst message, like the proposed eclass would
 generate? Do you agree that a postinst message is desirable feature?

  [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme
 
 --
 Thanks,
 Zac


 If we had README.gentoo, I'd love it if Portage alerted me as those
 files changed.

 Even if it's just whitespace or formatting changes? Maybe it's better to
 let the ebuild do version comparisons and decide whether to generate a
 message based on that.

I see two solutions to that:

1) Define a format for the file, so that substantive difference can be
programmatically discerned from non-substantive differences. I don't
have a good proposal for a particular format.

2) Make it so that an author of a README.gentoo file is well aware
that any change he makes will potentially annoy all his users if the
change isn't substantive.

Frankly, (2) seems entirely reasonable. And at the same time, being
able to look at version history for README.gentoo files would be
extraordinarily enlightening.

--
:wq

Re: [gentoo-dev] About using a CONFIGURATION (or SETUP) file under /usr/share/doc for configuration information

[Michael Mol]

On Jan 6, 2013 8:32 PM, Zac Medico zmed...@gentoo.org wrote:

 On 01/06/2013 01:04 AM, Ralph Sennhauser wrote:
  On Fri, 4 Jan 2013 23:34:59 -0600
  Donnie Berkholz dberkh...@gentoo.org wrote:
 
  On 10:26 Sat 22 Dec , Pacho Ramos wrote:
  Hello
 
  After seeing:
  https://bugs.gentoo.org/show_bug.cgi?id=440214
 
  Looking to a lot of its blockers shows that we are using elog
  messages for informing people about configuration (like pointing
  people to external links to get proper way of configuring things,
  tell them to add to some system groups...). I thought that maybe
  this kind of information could be simply included in a canonical
  file under /usr/share/doc/ package dir called, for example,
  CONFIGURATION or SETUP. We would them point people (now with a news
  item, for the long term provably a note to handbook to newcomers
  would be nice) to that file to configure their setups. The main
  advantages I see:
  - We will flood less summary.log ;)
  - The information to configure the package is always present while
  package is installed, now, if we remove merge produced logs, people
  will need to reemerge the package or read directly the ebuild
 
  What do you think?
 
  Bikeshedding ... would go with README.gentoo, because people are
  already used to looking for README files. Every time we can eliminate
  Gentoo-specific weirdness, we should.
 
 
  See the documentation for README.Debian[1], most importantly the
  example. ;)
 
  I'd say we should handle it the same as Debian does.

 README.gentoo sounds good to me.

  What could we possibly gain from doing it differently?

 Does Debian have a postinst message, like the proposed eclass would
 generate? Do you agree that a postinst message is desirable feature?

  [1] http://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme
 
 --
 Thanks,
 Zac


If we had README.gentoo, I'd love it if Portage alerted me as those files
changed.

Re: [gentoo-dev] Gentoo and Root CAs

[Michael Mol]

On Tue, Jan 1, 2013 at 5:51 AM, Dirkjan Ochtman d...@gentoo.org wrote:
 On Tue, Jan 1, 2013 at 1:44 AM, Rich Freeman ri...@gentoo.org wrote:
 The certificates that Gentoo distributes have at least been vouched
 for by somebody who is a part of our community, which is more than can
 be said for most of the upstream certificates.

 And you think vouched for by some community member is better than
 Mozilla's audit process, however limiting it may be?

 Yes, the CA system is broken, but it's what we've got for now. It
 seems obvious that including fewer CA roots in our base package is a
 better solution than including more of them, since (a) it's pretty
 easy for our users to install more of them, including at scale (via an
 overlay), and (b) actual security of a CA probably goes down
 exponentially as you move towards CA's with a lower level of trust
 placed in them by organizations like Mozilla.

 Speaking of which, say what you will about Mozilla's broken criteria
 for root inclusion, but Mozilla has no commercial interests,

Wait, what? How does taking income during a process not constitute a
commercial interest? That money goes to something that's in the
interest of the Mozilla Foundation, whether it's paying for
infrastructure, paying for developers to do their thing, sponsoring
this, that or the other thing...

Without money Mozilla wouldn't exist, ergo Mozilla is interested in
money, ergo taking money in exchange for bundling a root cert carries
its own interest outside of the security properties of bundling the
root cert.

So if Mozilla has an interest in cert security, and an interest in
money, than including certs for money carries with it an inherent
conflict of interest.

Such as the world is, things cannot be done without money to exchange
for goods and services, so any entity with interests beyond money
needs to manage such a conflict, one way or another. So, the question
comes around to how well the entity manages that conflict of interest,
via things like ombudsmen or independent (how?) audit processes. Or
how it's managed for them, via things like reputation. (And it sounds
to me like Rich is making a strong argument about the reputation
angle, both in favor of vouching, and for observing security problems
with people Mozilla still bundles.)

(That's all I've got for this thread. Going back to lurking.)


--
:wq

Re: [gentoo-dev] Re: Gentoo and Root CAs

[Michael Mol]

On Tue, Jan 1, 2013 at 9:37 PM, Benjamin Peterson benja...@python.org wrote:
 Michael Mol mikemol at gmail.com writes:
 On Tue, Jan 1, 2013 at 5:51 AM, Dirkjan Ochtman djc at gentoo.org wrote:
  Speaking of which, say what you will about Mozilla's broken criteria
  for root inclusion, but Mozilla has no commercial interests,

 Wait, what? How does taking income during a process not constitute a
 commercial interest?

 There seems to be some confusion about Mozilla's cert inclusion process. 
 Mozilla
 does not make any money by including CA certificates. Per its own policy [1],
 We will not charge any fees to have a CA's certificate(s) distributed with 
 our
 software products.

 [1] 
 https://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html

Fair enough. I took Rich's email as an indication they did.



--
:wq

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

[Michael Mol]

On Sat, Dec 29, 2012 at 11:13 AM, Brian Dolbec dol...@gentoo.org wrote:
 On Sat, 2012-12-29 at 16:42 +0800, Ben de Groot wrote:
 On 27 December 2012 00:39, Kent Fredric kentfred...@gmail.com wrote:
  Can we short cut the whole quiz process and have some Inbound repository
  until we're full git, which people can fork/commit/pull and trusted people
  can review submitted branches and apply them to CVS?

 This is why I started https://github.com/yngwin/proxy-maint/
 Feel free to send pull requests my way. I have been very busy lately
 with work, so I am a bit behind on my Gentoo stuff, but I should be back
 in full swing soon.


 Not to sidetrack the topic farther, but isn't this best done in our
 github/gentoo account.  It is one of the main reasons we have it, to
 easily accept pull requests from users.  It would also make it easier
 for more devs to participate in a group proxy-maint repo.

Certainly a sidetrack: I would like to point out that Github now
supports Organizations as a semantic concept. I *highly* recommend
using something like that over using an 'individual' account as an
organization.

I've been using Github Organizations in a private context, and it's
been working extremely well.

--
:wq

Gentoo and Github (Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...) )

[Michael Mol]

On Sat, Dec 29, 2012 at 11:32 AM, Michael Mol mike...@gmail.com wrote:
 On Sat, Dec 29, 2012 at 11:13 AM, Brian Dolbec dol...@gentoo.org wrote:
 On Sat, 2012-12-29 at 16:42 +0800, Ben de Groot wrote:
 On 27 December 2012 00:39, Kent Fredric kentfred...@gmail.com wrote:
  Can we short cut the whole quiz process and have some Inbound repository
  until we're full git, which people can fork/commit/pull and trusted people
  can review submitted branches and apply them to CVS?

 This is why I started https://github.com/yngwin/proxy-maint/
 Feel free to send pull requests my way. I have been very busy lately
 with work, so I am a bit behind on my Gentoo stuff, but I should be back
 in full swing soon.


 Not to sidetrack the topic farther, but isn't this best done in our
 github/gentoo account.  It is one of the main reasons we have it, to
 easily accept pull requests from users.  It would also make it easier
 for more devs to participate in a group proxy-maint repo.

 Certainly a sidetrack: I would like to point out that Github now
 supports Organizations as a semantic concept. I *highly* recommend
 using something like that over using an 'individual' account as an
 organization.

 I've been using Github Organizations in a private context, and it's
 been working extremely well.

Ugh. Apologies. I meant to change the subject line, spent a couple
minutes figuring out how to do it in GMail...and then forgot. :-|

Fixing...

--
:wq

Re: [gentoo-dev] Is /var/cache the right place for repositories?

[Michael Mol]

On Mon, Dec 24, 2012 at 4:08 AM, Ulrich Mueller u...@gentoo.org wrote:
 On Mon, 24 Dec 2012, Sebastian Pipping wrote:

 On 20.12.2012 19:14, Ciaran McCreesh wrote:
 The tree is a database. It belongs in /var/db/.

 I don't see /var/db in the latest release of the Filesystem
 Hierarchy Standard:

   http://www.pathname.com/fhs/pub/fhs-2.3.html#THEVARHIERARCHY

 Wrong standard to choose from. ;-) /var/db/ is already required by the
 PMS for /var/db/pkg/.

 I would prefer something that blends with FHS.

 Is this important for a Gentoo specific directory?

/var/db/portage/ PORTDIR
/var/db/layman/  layman storage
/var/db/pkg/ VDB (no change)
/usr/local/portage/  local overlays (no change)
/var/cache/distfiles/DISTDIR
/var/cache/packages/ PKGDIR

 Alternatively, the last two could be under
 /var/cache/portage/{distfiles,packages}/.

Query that's been percolating in my mind...how much of this is
specific to Gentoo, and how much has strong overlap with closely
related distros like Sabayon and Funtoo?

--
:wq

Re: [gentoo-dev] Is /var/cache the right place for repositories?

[Michael Mol]

On Mon, Dec 24, 2012 at 8:32 AM, Ulrich Mueller u...@gentoo.org wrote:
 On Mon, 24 Dec 2012, Diego Elio Pettenň wrote:

 /var/cache/packages/ PKGDIR

 Maybe /var/spool/binpkgs ?

 This doesn't look right to me. /var/spool contains things like printer
 queues or outgoing mail that are typically deleted after processing.

Then treat it like garbage collection. Some maintenance action could
go through and remove the files which aren't fetch-restricted. Portage
could do this at the end of its cycle, or it could be set up as a cron
job, or it could require a manual maintenance step.


--
:wq

Re: [gentoo-dev] Re: Wordiness

[Michael Mol]

On Fri, Dec 21, 2012 at 8:31 AM, Matt Turner matts...@gentoo.org wrote:
 On Thu, Dec 20, 2012 at 11:05 PM, Duncan 1i5t5.dun...@cox.net wrote:


 My point is that you consistently write long essays that I, and
 apparently most others, don't bother to read. I'm not sure if you're
 aware of this.

 Someone said on IRC this morning in response to this thread

 the tragic thing is that guy would be able to make valuable contributions if 
 it weren't for the excessive length of his mails

 So, your emails are way too long. A huge percentage of recipients
 don't bother to read them. I don't know whether you just enjoy writing
 (you must!) or if you hope to actually be heard, but as it stands now
 you're not being heard by most.


I dunno. I read them.

Duncan, I think the clue here, though, is that you should start a
blog. I'd read that, too. :)


--
:wq

Re: [gentoo-dev] Moving our/portage stuff to var

[Michael Mol]

On Thu, Dec 20, 2012 at 11:01 AM, Ian Stakenvicius a...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 20/12/12 10:37 AM, Brian Dolbec wrote:

 /var/cache/repositories/ /var/cache/repositories/gentoo   ==
 the main portage tree /var/cache/repositories/local== the
 new location for a local overlay
 /var/cache/repositories/some-overlay  == layman installed
 overlay

 My idea for having all repos under one directory is to make it
 easier for a pkg manager to simply scan the directory to know all
 installed overlays.  Currently each one has to be listed in a
 configured variable in make.conf.  So if you wanted your local
 overlay somewhere else, then a symlink would work (provided the PM
 can/will autoscan repos), or add it to the PORTDIR_OVERLAY variable
 (current behavior).  I don't otherwise have a strong desire for it
 to be there.

 If and only if the tree and all overlays (not other directories)
 are not under one directory, then an autoscan cannot easily
 happen.



 You could do this while not having the portage tree be in that
 directory.  IE, portage goes in /var/cache/portage , and all the
 overlays go into /var/cache/repositories.

 The tree is separate enough IMO that autoscan can still happen easily,
 and also I believe that it can be assumed that the tree is in place.
 For instance, if the tree's location is defined to be elsewhere, it
 isn't done so via PORTDIR_OVERLAYS but rather PORTDIR.


 On an unrelated note, I would never treat my local overlays as
 cache.  Ebuilds that (as a user) I wrote and installed by hand are not
 likely to be kept in a repository someplace, but rather the overlay
 dir would most likely be it's only location.  IIRC the reason for
 /usr/portage/local/ was to have a path within the portage tree that
 rsync wouldn't kill; given that what you're suggesting is already not
 under the proposed portage tree location, emerge --sync couldn't touch
 it, and so I don't see a need at all to provide a 'local' repository
 destination by default.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.19 (GNU/Linux)

 iF4EAREIAAYFAlDTNlQACgkQ2ugaI38ACPCxQAEApT/7CaIbuVTwnDQk93hhDjGu
 mXKPdCJg4h1iMECtdoABAJj2601LuRPUKFJ+BJa/FqrdRTsjSpBRiEd8pvO2042P
 =W3T9
 -END PGP SIGNATURE-


It's sounding like the nearly the optimal solution would be:

/var/cache/portage/distfiles
/var/cache/portage/repositories/gentoo
/var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
/var/db/portage/repositories/{non-cache,repo,names,go,here}

Clearly, some data in question needs to be treated as persistent, and
others can be treated as cache. So it should probably be divided up
that way. The placement of tree and overlays as subfolders of the same
folder strikes me as appropriate, too.

The only thing I can't see an elegant workaround for are how to avoid
or handle repo name collisions between
/var/cache/portage/repositories/* and /var/db/portage/repositories/*

--
:wq

Re: [gentoo-dev] Moving our/portage stuff to var

[Michael Mol]

On Thu, Dec 20, 2012 at 12:05 PM, Ulrich Mueller u...@gentoo.org wrote:
 On Thu, 20 Dec 2012, Diego Elio Pettenň wrote:

 /var/cache/portage/distfiles
 /var/cache/portage/repositories/gentoo
 /var/cache/portage/repositories/{sunrise,kde,gnome,whatever,layman,grabs}
 /var/db/portage/repositories/{non-cache,repo,names,go,here}

 +1

 -1

 The subdirs are too deeply nested. (Ebuilds would be at the eighth
 level then...)

Maybe I missed something...but what's wrong with that?


 Let's put the tree in /var/cache/portage please, and distfiles in
 /var/cache/distfiles. Layman overlays can stay where they are, or move
 to /var/cache/layman.

--
:wq

Re: [gentoo-dev] Moving our/portage stuff to var

[Michael Mol]

On Thu, Dec 20, 2012 at 12:31 PM, William Hubbs willi...@gentoo.org wrote:
 On Thu, Dec 20, 2012 at 06:58:11AM -0500, Rich Freeman wrote:
 On Thu, Dec 20, 2012 at 4:25 AM, George Shapovalov geo...@gentoo.org wrote:
  On Thursday 20 December 2012 09:11:39 Ulrich Mueller wrote:
   /var/cache/repositories/local== the new location for a local 
   overlay
 
  Also I wonder if local overlays should be in /var/cache? It might not
  always be possible to restore them.
  So, this is the present /usr/local/portage? What's wrong with it?
  According to FHS, /usr/local/ is reserved for local admin meddling, which 
  fits
  the bill rather nicely fo local overlay. This is the one location that was
  actually making sense from the beginning.

 I actually like the /var/cache/repositories approach.  You can always
 add a symlink to it if you want to for convenience (as I already do
 for /var/lib/portage/world).  There is really nothing special about
 /usr/portage, other than it being the lowest-priority overlay.

  If we do this, I don't like the name repositories -- what kind of
  repositories? should I put git repositories in there?

I was pondering this, too. How about 'pms', for trees and overlays?

--
:wq

Re: [gentoo-dev] College Course in Gentoo Development

[Michael Mol]

On Mon, Dec 17, 2012 at 1:09 PM, Roy Bamford neddyseag...@gentoo.org wrote:
 On 2012.12.17 16:02, Rick Zero_Chaos Farina wrote:
 On 12/17/2012 10:32 AM, Anthony G. Basile wrote:
  Hi everyone,
 
  Give the talk on the list about attracting devs, I've should
  probably mention that I'm teaching a College Course on Gentoo
  Development
 [snip]

 Can I take this course online? Will the lectures be recorded?

 -ZC


 I would be interested in an online version too.

As would I.

(I'd also be very interested in seeing the structure duplicated to
produce similar material for other common distributions...but I'm a
chrestomathy addict.)

--
:wq

Re: [gentoo-dev] Attracting developers (Re: Packages up for grabs...)

[Michael Mol]

On Sun, Dec 16, 2012 at 2:04 PM, Markos Chandras hwoar...@gentoo.org wrote:
 On 16 December 2012 16:57, Michael Orlitzky mich...@orlitzky.com wrote:
 Inspired by the number of packages being unmaintained -- why not use
 some of that bug bounty money to fix up the recruitment documentation

 Recruitment documentatiob? What does that mean?

  People still think of Gentoo as a ricer distro that's broken all
  the time, when in reality, it's one of the most stable.

 Well that's not entirely true but that's a different issue

What's not really true? That it's the most stable? or that people
think of it as a ricer distro?

I face funroll-loops references and worse almost every time I bring up
Gentoo among a different group of Linux-familiar technical people.
There are still *very* strong prejudices against Gentoo in most places
I've brought it up. But when I bring it up, and I argue against those
funroll-loops references, one or two people come out of lurking and
admit that they use it...and it's a surprise to people around them.

I've started describing it as a coming out of the closet experience
for a reason... There's a _serious_ reputation issue that Gentoo still
hasn't completely sloughed off...which is incredibly sad. Of all the
distros I've used, I've come to the conclusion that Gentoo is the
easily nicest for almost anyone even moderately technical.

--
:wq

Re: [gentoo-dev] Using emerge-webrsync to simplify the handbook

[Michael Mol]

On Fri, Nov 30, 2012 at 10:57 AM, Richard Yao r...@gentoo.org wrote:
 On 11/28/2012 11:08 AM, Matthew Thode wrote:
 On 11/28/2012 09:05 AM, Richard Yao wrote:
 On 11/28/2012 09:17 AM, Maxim Kammerer wrote:
 On Wed, Nov 28, 2012 at 3:54 PM, Richard Yao r...@gentoo.org wrote:
 We could slightly simplify the handbook installation procedure if we
 told people to use emerge-webrsync to fetch the initial snapshot.

 Using emerge-webrsync also makes the installation process more robust,
 since it only requires HTTP access (whereas many firewalls restrict
 RSYNC). Besides, emerge-webrsync can check PGP signatures, so I think
 that it should be the primary recommended portage tree synchronization
 method.


 The only downside of which I am aware is increased network traffic.
 However, we could redesign emerge-webrsync to take advantage of GNU
 Tar's incremental archive functionality.

 That would permit us to mirror compressed diffs in addition to regular
 portage snapshots. Doing that well could reduce bandwidth requirements.

 weekly fulls and daily diffs?


 Determining what is right here probably requires calculus, but this
 scheme does not seem like a bad choice to me. My main concern is that
 maintaining weekly full snapshots would require too much space for the
 mirrors. It might be better go monthly, with diffs on the following
 intervals:

 1 week
 1 day
 30 minutes

 Doing that would eliminate the benefit of rsync entirely, with the
 caveat that we now need to mirror a ton of diffs. This would make it
 easy for us to provide the ability to obtain historical snapshots, which
 would be nice.

Worth noting that all this moves us nicely in the direction of
allowing HTTP proxies to cache data, reducing load on mirrors. And
moves us in the direction of implementing mirrors themselves as a
network of caching proxies.

--
:wq

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Michael Mol]

On Tue, Nov 20, 2012 at 10:25 AM, Greg KH gre...@gentoo.org wrote:
 On Mon, Nov 19, 2012 at 08:08:38PM -0500, Walter Dnes wrote:
 On Mon, Nov 19, 2012 at 09:08:52AM -0800, Greg KH wrote

  Again, any specific pointer to a commit in the tree that caused this?

   See http://wiki.gentoo.org/index.php?title=Udev/upgraderedirect=no
 Comments?

 As I don't know who made those wiki changes, I don't know, but this
 seems to be a choice made by the gentoo udev maintainers, not
 necessarily the upstream developer's choice.

http://wiki.gentoo.org/index.php?title=Udev/upgradeaction=history
http://wiki.gentoo.org/wiki/User:Astaecker

Best ask him, I suppose.

--
:wq

Re: [gentoo-dev] Re: Additional USE_EXPAND variables: E_MODULES and E_MODULES_CONF

[Michael Mol]

On Thu, Nov 15, 2012 at 3:43 PM, Duncan 1i5t5.dun...@cox.net wrote:
 Thomas Sachau posted on Thu, 15 Nov 2012 20:45:16 +0100 as excerpted:

 Ben de Groot schrieb:
 On 14 November 2012 05:13, Thomas Sachau to...@gentoo.org wrote:

 Alexis Ballier schrieb:
 - considering gentoo generally uses e-prefixed names (econf, emake,
   etc.) maybe its wiser to name the variables E17_* instead of only
   E_*, or ENLIGHTENMENT_*, so that it makes the confusion harder.

 Those functions are internal ebuild functions, while the USE_EXPANDed
 var is exposed to and may be used by the user, so i dont see a high
 risk of people mixing them. Maybe some other people can also comment
 on this?

 I agree that E_* is more confusing than it needs to be. Please use
 something that is unmistakeably clearer.

 ok, so what about ENLIGHTENMENT_MODULES as USE_EXPANDED var?

 That's certainly clear enough.  Alternatively, something like ENL_* would
 be shorter if somewhat more cryptic, but should eliminate any possible
 E_* confusion.

 Because as a user I recently noted some package with a use-expand that
 gets REALLY long in portage's emerge --verbose --pretend output, which
 lists ALL variants on or off, with the prefix repeated for each one.
 ENLIGHTENMENT_MODULES is certainly clear enough, but when it's repeated a
 dozen or more times, once for each expansion, that's a VERY long
 emerge --pretend --verbose output!

 So as a user I'd prefer the shorter if more cryptic ENL_*, which does at
 least eliminate the potential confusion of the originally proposed E_*,
 while still being short enough to not be horribly annoying when repeated
 a dozen times.

As a user, I'd prefer the full ENLIGHTENMENT_MODULES, as I prefer
verbosity over cryptocity in configuration and debugging output. But
then, I don't use E...



--
:wq

Re: [gentoo-dev] Merging the devrel handbook into the devmanual

[Michael Mol]

On Thu, Nov 1, 2012 at 5:34 PM, Michał Górny mgo...@gentoo.org wrote:
 On Wed, 31 Oct 2012 17:26:38 +0100
 Theo Chatzimichos tampak...@gentoo.org wrote:

 On Wed, Oct 31, 2012 at 1:39 PM, Michael Palimaka kensing...@gentoo.org 
 wrote:
  Hi all,
 
  In bug #304435[1], hwoarang suggested merging the devrel handbook[2] into
  the devmanual[3].
 
  As the project has grown, so has the amount - and dispersion - of
  development information. I believe consolidation of this information into a
  single point will make everyone's (especially new developers) lives easier.
 
  What do you think?
 
  Best regards,
  Michael
 
  [1]: https://bugs.gentoo.org/show_bug.cgi?id=304435
  [2]: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml
  [3]: http://devmanual.gentoo.org/

 +1 and btw move the devmanual in the wiki :D

 I'm not sure if wiki fits nicely here. I believe that wiki is very
 useful at taking notes, writing quick guides and sharing information
 and tips in general. The main advantage is the free workflow -- you
 have an idea to share but can't do it all by yourself. You start it,
 others can easily improve it.

 Sadly, our wiki is MediaWiki. Not getting deep into it, the syntax is
 worse than awful. It could be considered acceptable if you write
 encyclopedia articles, stuff with heavy inside linking and not much
 code inside. However, for technical articles it is horrible, horrible
 and once more horrible.

 Shortly saying, devmanual in wiki would mostly consist of HTML tagsoup
 intermixed with wiki text. For the very simple reason that MediaWiki
 lags markup for as basic things as inline code and requires you to use
 HTML instead. Not something I'd use for anything as fundamental
 as devmanual.

Rosetta Code (my site) runs MediaWiki. I can attest to the terrible
thing that is MW syntax. That said, we did ultimately come up with
workarounds for 98% of the problems. (Most of the remaining 2% are
spammers...and that comes down to a question of strongly you lock the
thing down.)

I've submitted patches to Gentoo docs before. Honestly, I found it a
pain; I'm not accustomed to that particular process. Admittedly, this
is one of those cases where I simply lack an attainable skill.

If nothing else, I'd love to see the docs all reside in Git; I could
fork to my Github account and generate pull requests from there. A
proper maintainer could review the pull request and decide whether or
not to merge it. That would be a much more comfortable workflow, IMO.
(Heck, I wouldn't mind migrating RC to a similar workflow; I'd just
have to migrate gigabytes worth of wikitext history to a format with
new semantics...)

--
:wq

Re: [gentoo-dev] Merging the devrel handbook into the devmanual

[Michael Mol]

On Wed, Oct 31, 2012 at 3:02 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:

 On Wed, 31 Oct 2012 17:26:38 +0100
 Theo Chatzimichos tampak...@gentoo.org wrote:
  +1 and btw move the devmanual in the wiki :D

 That would rather go against the original idea behind the devmanual,
 which was that it was supposed to be high quality and authoritative.

Pages can be locked to be editable only by members of blessed groups.

--
:wq

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Michael Mol]

On Tue, Oct 30, 2012 at 3:24 PM, Michał Górny mgo...@gentoo.org wrote:

 On Tue, 30 Oct 2012 11:30:16 -0700
 Diego Elio Pettenò flamee...@flameeyes.eu wrote:

  Given the amount of headaches that Boost seems to give us all, now
  thanks to the recent changes even more because Gentoo's boost is
  different from all others and no upstream default check seem to work
  correctly with it, I'm questioning the usefulness of having it slotted.

 Could you elaborate on that? I don't remember having problems with
 boost.m4 or cmake's default checks unless I'm missing something which
 is obvious to you.

  So given that it's a PITA for the maintainers, a PITA for the users,
  eselect boost has been shown to be a bad idea and so on ... can we just
  go back to just install it and that's about it?

 How are you going to solve the issue of a lot of packages being broken
 with new boost versions? Are you volunteering to keep fixing them with
 each release?


It's worth noting that Boost themselves recommend developers inline the
code they want to use.

I've never understood why Gentoo uses a separate ebuild for it. I mean, I
can understand some efficiency gains from having a single compiled copy,
but it shouldn't be surprising in the least when upstream makes breaking
changes in the API.

-- 
:wq

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Michael Mol]

On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò
flamee...@flameeyes.euwrote:

 On 30/10/2012 13:39, Michael Mol wrote:
  In general, I agree...but Boost wasn't intended to be a shared library,
  so there shouldn't be a conflict there.

 But there are shared libraries, and they are not small either. And I'd
 rather, say, hunt an RWX section problem (a security problem) with a
 single shared library rather than having to hunt it down in a dozen or so.

 Besides, honestly it's not that bad. I think that half the headache that
 we're having is due to the slotting more than from boost itself. And the
 other half is due to people actually not going to fix their crap because
 oh I can just use the older version (until a new compiler or C library
 comes out).

 I've had to do my share of porting to newer boost — and as I said most
 of the headaches have been for the build system to find the object,
 rather than anything else.


Thank you. That was enlightening. :)

-- 
:wq

Re: [gentoo-dev] [RFC] Dropping slotted boost

[Michael Mol]

On Tue, Oct 30, 2012 at 4:59 PM, Samuli Suominen ssuomi...@gentoo.org wrote:

 On 30/10/12 22:49, Michael Mol wrote:

 On Tue, Oct 30, 2012 at 4:45 PM, Diego Elio Pettenò
 flamee...@flameeyes.eu mailto:flamee...@flameeyes.eu wrote:

 On 30/10/2012 13:39, Michael Mol wrote:
   In general, I agree...but Boost wasn't intended to be a shared
 library,
   so there shouldn't be a conflict there.

 But there are shared libraries, and they are not small either. And
 I'd
 rather, say, hunt an RWX section problem (a security problem) with a
 single shared library rather than having to hunt it down in a dozen
 or so.

 Besides, honestly it's not that bad. I think that half the headache
 that
 we're having is due to the slotting more than from boost itself. And
 the
 other half is due to people actually not going to fix their crap
 because
 oh I can just use the older version (until a new compiler or C
 library
 comes out).

 I've had to do my share of porting to newer boost — and as I said
 most
 of the headaches have been for the build system to find the object,
 rather than anything else.


 Thank you. That was enlightening. :)


 Please remove HTML from your e-mail clients settings, at least for this
 mailing list. It's unreadable.

Apologies; didn't even realize it was enabled.

Incidentally can you forward a screenshot to me so I can see exactly
how poorly it integrated with your normal settings? I don't expect I
can get GMail to take a bug report, but if its HTML emails are setting
things like fixed sizes, that's something that needs to be brought up.
(I certainly wasn't copy/pasting or setting _anything_ manually. I
avoid that as much as possible.)

--
:wq

Re: [gentoo-dev] Re: [RFC] A news item covering PYTHON_TARGETS

[Michael Mol]

On Mon, Oct 29, 2012 at 1:01 PM, Duncan 1i5t5.dun...@cox.net wrote:

 Michał Górny posted on Mon, 29 Oct 2012 15:45:01 +0100 as excerpted:

  Title: PYTHON_TARGETS deployment

 [snip]

  Lately, a new Python eclasses were deployed and the way of supporting
  multiple Python implementations changes with ebuilds being migrated to
  them. While before the implementations being installed were used by
  default, the migrated packages will instead use explicit choice based on
  PYTHON_TARGETS USE flags. This may require action from some of our
  users.

 That paragraph needs help. Try this:

 Recently, new python eclasses were deployed.  As ebuilds migrate, the way


Recently, a new python eclass was deployed.

or

Recently, a few new python eclasses were deployed.

or even

Recently, a few python eclasses were deployed.

And then capitalize Python.

-- 
:wq

Re: [gentoo-dev] Re: CIA replacement

[Michael Mol]

On Tue, Oct 2, 2012 at 8:21 PM, Jeroen Roovers j...@gentoo.org wrote:
 Responding to no one in particular, but to the sub-thread about IRC
 bots:

 On Tue, 2 Oct 2012 08:32:26 +0200
 Fabian Groffen grob...@gentoo.org wrote:

 On 02-10-2012 12:40:20 +0800, Ben de Groot wrote:
  The irker proxy was mentioned in this thread. I think we should look
  into this. Unless someone has a better idea.

 I think it might be more beneficial to try and relay -commits email to
 irc.

 An IRC bot is nice, but CIA also provided current (!) statistics, which
 isn't merely useful in order to boost your own morale/ego/self-esteem,
 but also provided up to date information about other developers'
 activity, which can help other developers decide if and when to step in
 and start (temporarily) maintaining packages that need immediate
 attention. ohloh cannot do that for us, presently, and a simple IRC
 bot cannot either.

Bouncing over to -scm list. Maybe this can be implemented in a post-commit hook.


-- 
:wq

Re: [gentoo-dev] CIA replacement

[Michael Mol]

On Mon, Oct 1, 2012 at 1:29 PM, Rich Freeman ri...@gentoo.org wrote:
 On Mon, Oct 1, 2012 at 11:21 AM, Rafael Goncalves Martins
 rafaelmart...@gentoo.org wrote:
 Maybe someone with good cvs knowledge can contribute a hook for irker
 [1], so we can have #gentoo-commits flooding our irc clients again! :)

 Why exactly are we still using cvs?  Rather than building enhancements
 for cvs, why not just migrate everything to git, and spend our time
 building the git hooks/etc necessary to make this work?

 Looking at the tracker [1], we need a pre-upload hook (I'm not quite
 sure why), an rsync conversion script, the ability to validate the
 converted tree, and documentation.  There is still an open bug for
 commit signing, and I'm not quite sure why as this was implemented.

 It seems like a lot has already been done with validation.  Checking
 the active tree is pretty trivial - just compare the trees and they
 should be the same.  I guess we need to check history, but it seems to
 me like the risk of problems is low, and if we just keep a backup of
 the cvs repository if there is ever a concern about who made some
 commit 5 years ago we can always dig it up.

 It really seems to me like little remains to be done here.  Mostly we
 just need somebody to push a decision on things like workflow.  A few
 of the bugs have comments like no sense working on this with other
 stuff still needed - which seems to be outdated thinking with so
 little left to do.

 Am I missing some big concern that just isn't obvious in these bugs?

 I also fear that we're refusing to take action on a great solution
 because it isn't a perfect solution.  Nobody in the world is using
 tree-signing with git, and we aren't really using it in cvs either.
 We now have the ability to do it with git, but depending on workflow
 3rd-party signatures might not end up in the history of head, or we
 might not be able to verify them in an automated fashion.  Honestly, I
 think the appropriate response here is whoop-de-doo.  We can't do any
 of that stuff with cvs, but moving to git would have a lot of other
 benefits.  We can always change our processes later once somebody has
 a solution for the signing problem.  Right now we're making do without
 it on cvs, and so is every other project using git.  We can also
 continue to sign manifests as a workaround, which is what we'll be
 doing anyway if we never migrate to git.

 The git migration just strikes me as one of those cases where anybody
 is free to come up with a reason not to use something, but nobody has
 to defend keeping the status quo.  I think the question isn't whether
 there is anything wrong with using git, but whether the problems with
 git are worse than the problems we already have.

 But, hey, if somebody wants to write an irc bot that posts cvs
 commits, knock yourself out.

 Rich

 [1] - https://bugs.gentoo.org/show_bug.cgi?id=333531


I don't know to what depth this has been discussed in the past, but if
you use git, you also get an HTTP transport, which has a useful
feature: You could simplify updating the tree on end-users's machines
by using caching proxy servers (operating in accelerator mode) on the
various mirrors.

Those of us who have our own, local caching proxy servers (I have
squid running on my network gateway) can reduce the network load even
further by getting cache hits on our local network before even making
queries outside our network. (Personally, I find this a far easier
thing to maintain and do debugging reasoning on than, e.g. sharing a
network mount or running a local rsync server managed by a cron job.)

-- 
:wq

Re: [gentoo-dev] CIA replacement

[Michael Mol]

On Mon, Oct 1, 2012 at 1:54 PM, Rich Freeman ri...@gentoo.org wrote:
 On Mon, Oct 1, 2012 at 1:42 PM, Michael Mol mike...@gmail.com wrote:
 I don't know to what depth this has been discussed in the past, but if
 you use git, you also get an HTTP transport, which has a useful
 feature: You could simplify updating the tree on end-users's machines
 by using caching proxy servers (operating in accelerator mode) on the
 various mirrors.

 The issue I see here is a tradeoff of bandwidth vs CPU.  I just ran an
 emerge --sync and the total amount of transmitted data was 5M.  The
 whole tree is 250M, though no doubt with compression that could be
 reduced.

 Now, one advantage of HTTP is that caching http servers are likely
 more ubiquitous in general than rsync servers.  But, we have a whole
 bunch of rsync servers already, and we don't have a bunch of caching
 http servers.

 I suspect bandwidth is going to cost more than CPU here.

 In any case, not a reason to hold up git, just one more possibility if
 we ever move.

It really depends on how efficient 'git pull' is over HTTP, IMO. I
mean, when I do pulls and pushes in my workflows, it doesn't do a full
data send or a full data pull; that's reserved for 'git clone'.

It may also depend on how often the pull is done; rsync doesn't pull a
tree history, just a copy at the time of sync. git pulls new objects,
which may include intermediate versions which are no longer necessary.
(git may be capable of only syncing to 'HEAD' without worrying about
intermediate states, but I don't know. I'm not advanced enough to
definitively say one way or another.)

As for setting up caching proxies at existing mirror sites...It should
be a case of publishing, a single squid (or pick whatever proxy you
prefer to standardize on) configuration file with appropriate ACLs and
copy it all over the place. I'm not on the infra team, so I don't know
what things look like under the hood, but I do know setting up squid
in forward and reverse roles isn't very painful.

-- 
:wq

Re: [gentoo-dev] Discussing stuff that is not appropriate to discuss

[Michael Mol]

On Mon, Oct 1, 2012 at 8:58 PM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
 On 01/10/2012 17:51, Gregory M. Turner wrote:

 Anyhow, I get it: administering the vcs for a huge project such as
 Gentoo is very hard work.  If I somehow gave some other impression, I'm
 sorry.   Perhaps Rich and I insensitively voiced our shared assumption
 that Gentoo's continued reliance on cvs stems from a lack of motivation
 and consensus, rather than a shortage of labor and resources.

 That's definitely not the case. While we do have had some complains
 (mostly from Prefix last I knew) about git's working, the consensus for
 going to git is there. The problems are vastly technical.

 Problems such as how many developers would be fine with having to
 checkout 2GB of history to be able to commit? git support shallow
 clones but not if you want to commit to them.

 Then
 again, if the folks in the trenches doing the work think I've slighted
 them, surely they are perfectly capable of chewing me out on their own
 behalfs and don't need you to do it for them?

 It is at the very least disturbing that you think that people whose
 work, and commitment, has been overlooked for a whole discussion can't
 be bothered by it unless they are actually reactive aggressively.

 I know the kind of thankless tasks Infra has to deal with on a daily
 basis, and I think they deserve more respect that most of the time they
 are given here, especially when technical challenges are billed under
 the we just need to push harder for it to move banner like this time.

Some fascinating problems (social and technical) to address. I joined
the -scm list because it was implied that these things would be
discussed over there.

Could we take this outside? I'd be interested in looking at
solutions...but I don't want to drop them in here, since it's been
pounded on a few times by a few people that this isn't the place.

-- 
:wq

Re: [gentoo-dev] How to raise money for Gentoo

[Michael Mol]

On Thu, Sep 27, 2012 at 9:23 AM, wbrana wbr...@gmail.com wrote:
 Page www.gentoo.org asks for donations
 Donate to support our development efforts.
 Gentoo could get more money if all *.gentoo.org would contain advertisements.

I run a technical website with around 6k visits per day, and my
experience is that ads which aren't irritating and annoying don't pay
much. I had an almost-nice experience with Text-Link-Ads, but they
have a manual URL submission and approval process, and they turned
down my most-trafficked pages.

The other recurring difficulty I've had is finding an ad network which
comprehends technical markets. Since I can't find an ad network which
runs ads relevant to my users, I don't show ads.

-- 
:wq

Re: [gentoo-dev] How to raise money for Gentoo

[Michael Mol]

On Thu, Sep 27, 2012 at 10:29 AM, Alec Warner anta...@gentoo.org wrote:
 On Thu, Sep 27, 2012 at 4:11 PM, Dale rdalek1...@gmail.com wrote:
 wbrana wrote:
 Page www.gentoo.org asks for donations
 Donate to support our development efforts.
 Gentoo could get more money if all *.gentoo.org would contain 
 advertisements.




 My questions are this:  Does Gentoo need more money?  Is it in need of
 more funds to support itself?

 On a yearly basis, we take in more money than we spend. We primarily
 spend money on fees (legal, accountant, etc) and funding requests
 (infra hardware, requests from foundation members.)

 Its all on http://foundation.gentoo.org if you are curious. The 2011
 report notes that we have approximately $70,000 USD in funds. Some
 Gentoo developers want to do more conference-type events. However
 those typically come with much higher budgets than our funds and
 require sponsors to make happen. Without clearer goals on what to
 spend the money on, I can't really see the need to increase our
 advertising.

Could some of the money be spent on bug bounties?

[snip]

-- 
:wq

Re: [gentoo-dev] How to raise money for Gentoo

[Michael Mol]

On Thu, Sep 27, 2012 at 10:42 AM, Alec Warner anta...@gentoo.org wrote:
 On Thu, Sep 27, 2012 at 4:35 PM, Michael Mol mike...@gmail.com wrote:
 On Thu, Sep 27, 2012 at 10:29 AM, Alec Warner anta...@gentoo.org wrote:
 On Thu, Sep 27, 2012 at 4:11 PM, Dale rdalek1...@gmail.com wrote:
 wbrana wrote:
 Page www.gentoo.org asks for donations
 Donate to support our development efforts.
 Gentoo could get more money if all *.gentoo.org would contain 
 advertisements.




 My questions are this:  Does Gentoo need more money?  Is it in need of
 more funds to support itself?

 On a yearly basis, we take in more money than we spend. We primarily
 spend money on fees (legal, accountant, etc) and funding requests
 (infra hardware, requests from foundation members.)

 Its all on http://foundation.gentoo.org if you are curious. The 2011
 report notes that we have approximately $70,000 USD in funds. Some
 Gentoo developers want to do more conference-type events. However
 those typically come with much higher budgets than our funds and
 require sponsors to make happen. Without clearer goals on what to
 spend the money on, I can't really see the need to increase our
 advertising.

 Could some of the money be spent on bug bounties?

 You want gentoo-nfp@, not this list. I'm trying to move the discussion
 there. Go visit the foundation webpages I linked to earlier. Funding
 requests are pretty easy to write...

kk. I'll stop adding noise to this list on this topic. :)

-- 
:wq

[gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Michael Mol]

A few months ago, I filed bug 423651 to ask that bzip2 on the install
media be replaced with
 pbzip2. It was closed a short while later, telling me that it'd
involve changing what's kept in @system, and that had to be discussed
here, rather than in a bug report.

Here's a detailed description of how pbzip2 operates, as described by
a friend of mine:

 pbzip2's compression routine splits the input into blocks (with a default of 
 900,000
 bytes), which it then feeds into the standard bzip2 compression routine. The 
 output
 of the various calls to the bzip2 compression routine are then concatenated 
 together.
 The end result is the same as if you had first used the split command on 
 the input,
 run individual bzip2 commands on the split pieces, then recombined the 
 individual
 bz2 files using cat.

 The down side to this is that you have multiple file headers, footers, and 
 byte-align
 padding, plus the fact that bzip2 does a RLE compression stage to fill the 
 buffer it
 feeds to the BWT, the main part of the compression routine. If you happen to 
 have a
 section with 1MiB of the same byte, the pbzip2 front-end will split that into 
 two blocks
 (at the default settings) and feed them to separate bzip2 compressors. bzip2 
 will
 then compress the first block down to a buffer of about 17kiB before passing 
 it on
 to be compressed further, and the rest of the data would have fit within this 
 block, if
 pbzip2 hadn't split it the way it had.

 As for decompression, pbzip2 can only really do parallel decompression of 
 files that it
 created, since it seeks for the bz2 file header in order to split it to 
 different workers. One
 reason for this is that the bz2 block header is not byte aligned.

I really don't know how to carry this discussion any further than
this; I'll answer any questions I can.

-- 
:wq

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Michael Mol]

On Wed, Sep 26, 2012 at 5:27 PM, Florian Philipp li...@binarywings.net wrote:
 Am 26.09.2012 22:43, schrieb Matt Turner:
 On Wed, Sep 26, 2012 at 1:30 PM, Michael Mol mike...@gmail.com wrote:
 A few months ago, I filed bug 423651 to ask that bzip2 on the install
 media be replaced with
  pbzip2. It was closed a short while later, telling me that it'd
 involve changing what's kept in @system, and that had to be discussed
 here, rather than in a bug report.

 If we're going to ship a parallel bzip2 implementation, it should be
 lbzip2 and not pbzip2.

 lbzip2 can decompress bz2 archives with multiple threads that haven't
 been compressed with lbzip2/pbzip2.


 This seems relevant, especially comment 12ff:
 https://bugs.gentoo.org/show_bug.cgi?id=309683

 For further anecdotal evidence: I've used pbzip2 with USE=symlink for
 several months now and never had trouble with it. Checking out lbzip2
 now. I noticed it doesn't install a bunzip2 symlink.

Piotr Szymaniak asked me about lbzip2, and I bounced the question over
to my friend. He didn't investigate it deeply; it crashed (OOM or
something else, I don't know) when he tried it on a large file. Could
have been from 2GB to 2TB, from what he has laying around. I don't
know; I didn't get that one in writing. :)

But if it proves to be stable for small and very large files, I'd have
no complaint. :)

-- 
:wq

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Michael Mol]

On Wed, Sep 26, 2012 at 5:49 PM, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
 Michael Mol schrieb:
 A few months ago, I filed bug 423651 to ask that bzip2 on the install
 media be replaced with
  pbzip2.

 If I understand correctly, pbzip2 depends on bzip2. So what you are
 asking is that pbzip2 is preferred over bzip2 when both are installed,
 and that pbzip2 is installed by default?

pbzip2 uses libbzip2, which I understand bzip2 to also be a wrapper around.


 I have so far encountered only one anecdotal case in #gentoo IRC where
 pbzip2[symlink] caused problems in emerging a package. Disabling the
 symlink flag made the problem go away. However I can't point to the
 report right now, maybe someone with searchable backlog can uncover it.

pbzip2[symlink] is more or less the scenario I'd like to see.


 A different question is whether in the cases where parallel bzip2 makes
 sense, is it really the best solution? xz is outperforming bzip2's
 compression ratio for large files (for an informal comparison, see bug
 434350). And xz is faster at decompression, which offsets the parallel
 advantage to some degree.

xz is faster for decompression, by my inspiration case was during
system installation, so compression. Last I looked, xz was still very
slow for threaded compression. And it's not block-oriented, so I don't
think that's really possible without loss of compression efficiency,
anyway...and my use cases range from 4-8 physical cores.

-- 
:wq

Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2

[Michael Mol]

On Wed, Sep 26, 2012 at 6:57 PM, Christoph Junghans ott...@gentoo.org wrote:
 2012/9/26 Mike Gilbert flop...@gentoo.org:
 On Wed, Sep 26, 2012 at 5:59 PM, Michael Mol mike...@gmail.com wrote:
 On Wed, Sep 26, 2012 at 5:49 PM, Chí-Thanh Christopher Nguyễn
 chith...@gentoo.org wrote:
 Michael Mol schrieb:
 A few months ago, I filed bug 423651 to ask that bzip2 on the install
 media be replaced with
  pbzip2.

 If I understand correctly, pbzip2 depends on bzip2. So what you are
 asking is that pbzip2 is preferred over bzip2 when both are installed,
 and that pbzip2 is installed by default?

 pbzip2 uses libbzip2, which I understand bzip2 to also be a wrapper around.


 libbz2 is built and installed by the app-arch/bzip2 package. Thus,
 app-arch/pbzip2 depends on app-arch/bzip2, unless someone rips libbz2
 out into a separate ebuild.
 That sound like a plan. Maybe bzip2 should become a virtual as busybox
 also provides an implementation.

This makes sense. And going back to my initial issue, I don't really
care which implementation gets used on the bootable media, so long as
it supports scaling to use my CPU cores.

-- 
:wq

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michael Mol]

On Thu, Sep 20, 2012 at 1:58 PM, Pacho Ramos pa...@gentoo.org wrote:
 El jue, 20-09-2012 a las 10:14 -0400, Ian Stakenvicius escribió:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 20/09/12 09:52 AM, Ciaran McCreesh wrote:
  On Thu, 20 Sep 2012 09:13:40 -0400 Ian Stakenvicius
  a...@gentoo.org wrote:
  PMS may not need to be fixed, just the spec
 
  PMS is the spec, and it doesn't need fixing, since it accurately
  reflects the situation we're dealing with.
 

 Sorry, I misread PMS as PMs (portage, paludis, etc).

 And, for support to be official for ebuilds or eclasses to query IUSE
 (or other globals) within phase functions, then the 'spec' (PMS) is
 probably all that needs to be 'fixed'.  Right?

 So, in EAPI=6, we propose something that'll make it official (ie a
 querying function; or ensure that PMs can provide these variables
 along with their proper 'effective' values, or their in-ebuild
 'explicit' values, or whatever it is we want to say can be relied
 upon, to the environment).


 The problem of waiting for eapi6 to specify CURRENT behavior is that we
 don't know how much time will need to wait until it's approved (as I
 think eapi5 cannot include this extra function as was approved some
 hours ago). Other option would be to fast release some kind of eapi5.1
 adding this... but, again, I think we are discussing about something
 that could be resolved as simply as specifying current behavior for all
 existing eapis (as we are in fact doing in the tree) and rely on new
 eapis for future hypothetical changes on it.

The key question is: How would you formally describe the current behavior?

I think someone already noted it's not reliable behavior in all places.

-- 
:wq

Re: [gentoo-dev] vala.eclass: change vala_src_prepare behavior when USE=-vala

[Michael Mol]

On Thu, Sep 20, 2012 at 2:13 PM, Pacho Ramos pa...@gentoo.org wrote:
 El jue, 20-09-2012 a las 18:55 +0100, Ciaran McCreesh escribió:
 On Thu, 20 Sep 2012 19:54:43 +0200
 Pacho Ramos pa...@gentoo.org wrote:
  That isn't necessary what could occur if the behavior changes
  unexpectedly: as current behavior is already being assumed in
  eclasses/ebuilds, portage couldn't change it without, before, porting
  ebuilds/eclasses to use that new hypothetical behavior.

 Sure it can. Portage supports what's in the spec. If you're relying
 upon undefined behaviour, it's your problem when it stops working.


 It cannot break the tree, only square-headed people can think somebody
 would force a breakage and don't try to fix it before.

Isn't this why there are stable and unstable versions of PMs? And why
we have things like 'undefined behavior' in language specs? And why
depending on them is considered a bad thing? At least in the C world,
it's considered within the compiler's rights to take a UB dependency
in your code and stick in a routine to play salsa music in an infinite
loop while driving your laptop's hard drive to dance across the table.
(More frequently, it just omits the code entirely, but that's
typically less amusing.)

If I'm writing a PM, and I have to make sure my code conforms to some
condition, something static like a spec is the only thing I can really
depend on. If I use does this break anything in the tree as a test,
then I have to re-test every time some someone makes a change to the
tree, in case someone stumbled into more undefined behavior that works
for the PM they test against, but not for mine. And there's no
guarantee somebody else won't commit a different breaking UB-dependent
change to the tree in the two hours I spent changing my code to act
more like the one they're testing against--assuming they even tested
correctly!

On the other hand, if there's a spec document, I can say that ebuild
is depending on undefined behavior, and then come to an agreement
whether the ebuild needs to be changed, or whether the behavior needs
to be defined. And if the behavior is defined, then either my PM code
or the ebuild code changes to conform.

This sounds exactly like a classic de jure vs de facto standards
debate...and de facto really only works well when the number of
implementations that need to conform with each other is very
small--ideally one.

-- 
:wq

Re: [gentoo-dev] The lack of maintainer causing media-video/mediatomb to be lastrited next

[Michael Mol]

On Tue, Sep 18, 2012 at 6:44 AM, Samuli Suominen ssuomi...@gentoo.org wrote:
 Use bugzilla's search for 'mediatomb' and you will find multiple counts of
 build failures the media-video@ herd is simply not capable of handling due
 to lack of resources (manpower)

 So if nobody steps up, I've CCd treecleaners at bug 423991, the package
 shall be removed

I'll take that one on via proxy dev. What's the ETA for its removal?

-- 
:wq

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michael Mol]

On Tue, Sep 18, 2012 at 1:07 PM, Hans de Graaff gra...@gentoo.org wrote:
 On Tue, 2012-09-18 at 11:47 +0200, Michał Górny wrote:

 Yes, and sometimes we're doing 'use test'. I simply don't see how
 adding a separate group of dependencies just for 'test' phase is going
 to help us. They fit just fine into build-time dependencies right now.

 It would enable us to consider making tests on some packages optional to
 break circular dependencies with FEATURES=test, i.e. only run the tests
 if the test dependencies can be installed without circular dependencies.

 https://bugs.gentoo.org/show_bug.cgi?id=175808

Thought: That might also allow you to split an emerge into two
separate jobs. I.e. it's inconvenient, difficult or impossible to
have test dependencies installed at build time, but we could circle
back and run the tests in a test-only entry somewhere later in the job
queue, if the package build setup can support it.

-- 
:wq

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michael Mol]

On Mon, Sep 17, 2012 at 9:48 AM, Ben de Groot yng...@gentoo.org wrote:
 On 17 September 2012 20:41, Ciaran McCreesh
 ciaran.mccre...@googlemail.com wrote:
 On Mon, 17 Sep 2012 19:49:12 +0800
 Ben de Groot yng...@gentoo.org wrote:
 Or, even easier and more straightforward: just keep using *DEPEND. The
 case hasn't been made yet why we need to change that in the first
 place.

 We're looking at something like eight *DEPEND variables in EAPI 6, with
 considerable overlap between them all.

 And like now, in the great majority of cases, only two or three will be used.
 The enormous cost of moving to a different system (or the folly of using
 two systems in parallel) is not worth the slight benefit of a more cosmetic
 handling of the few cases where a few more *DEPEND variables would be
 needed and/or there is some overlap to be dealt with.

As someone who's been reading these threads, but hasn't actually
written any ebuilds from scratch, I'd like to offer my perspective as
a well-intentioned beginner:

On labels: The labels, to me, appeared largely more readable (and less
formidable a syntax to read and write as a human) than the foo? (
bar/baz ) syntax...until someone demonstrated a distinction between
depends and dependency types. I hadn't even noticed a distinction
between the two, until that point was raised.

While I like the labels (to me, they feel similar to Makefiles or C
switch statements), a clearer distinction between dependencies and
dependency types would be nice.

On unified DEPENDS vs *DEPEND: It seems to me that at a code level,
there's no real semantic difference. Since they both parse out
losslessly to the same abstract thing, you could serialize that
abstract thing back out into either format. Given most cases will be
simple, you could even serialize it away into something not
bash-based, if desired. All this means, to me, that the behavior of
the two under the hood is essentially irrelevant, and any bugs in
complex implementation could be caught with automated testing.

I personally favor a singular 'DEPENDS', because

1) I feel it would lead to better-organized documentation (I'm looking
for details about one var, rather than two or three vars--oh and then
there's the other N *DEPENDS I may not even have heard of yet), and

2) I worry less about accidental namespace pollution in my make.conf
file. Why do I worry about namespace pollution? Rather than using
profiles, I have around 40-50 USE flags divided by category into
varnames like SYS_USE_COMPRESION, and then I have a line that says
USE=${SYS_USE_CPU} ${SYS_USE_COMPRESSION} ${SYS_USE_DONOTWANT} # etc
which coalesces it all. When I ran into a strange problem some time
back, someone assisting me initially suspected that my SYS_USE_* vars
might be conflicting with something internal to portage.

Again, this isn't coming from a seasoned developer, this is coming
from a well-intentioned beginner with very little time on his hands.
-- 
:wq

Re: [gentoo-dev] EJOBS variable for EAPI 5?

[Michael Mol]

On Wed, Sep 12, 2012 at 12:33 PM, Hans de Graaff gra...@gentoo.org wrote:

 On Wed, 2012-09-12 at 08:58 -0400, Ian Stakenvicius wrote:

  So essentially what you're saying here is that it might be worthwhile
  to look into parallelism as a whole and possibly come up with a
  solution that combines 'emerge --jobs' and build-system parallelism
  together to maximum benefit?

 Forget about jobs and load average, and just keep starting jobs all
 around until there is only 20% (or whatever tuneable amount) free memory
 left. As far as I can tell this is always the real bottleneck in the
 end. Once you hit swap overall throughput has to go down quite a bit.

 I've been thinking about this, but that only works until you get to the
huge link step of, e.g. chromium, firefox, libreoffice.

I've had programs with memory leaks in the past, but I've never seen a
program validly consume as much memory as ld during those builds.

To cover something like that, you would need to be able to freeze and swap
out an entire process (such as ld) to allow something else to complete
quickly...but there's no good way I can think of to prioritize sanely
between the one big process and the few dozen smaller ones which might be
allowed to spawn and complete first.

-- 
:wq

Re: [gentoo-dev] Unified DEPENDENCIES concept

[Michael Mol]

On Fri, Sep 7, 2012 at 12:11 PM, Ian Stakenvicius a...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 07/09/12 12:03 PM, Michał Górny wrote:
 On Fri, 7 Sep 2012 12:46:41 -0300 Alexis Ballier
 aball...@gentoo.org wrote:

 I actually do like the concept but I'm not sure we can reach
 consensus about '*DEPEND vs DEPENDENCIES'; a possibility to get
 people used to it could be to have two parallel EAPIs, like 6 and
 6-dependencies, where the former will keep the old style and the
 latter use DEPENDENCIES.

 With eclasses supporting both of them? That's more than crazy.


 By the time EAPI=6* would happen we should have a git tree so we'd
 just fork the tree for EAPI=6-dependencies.  :)

 A change like this would *NEED* a long-term test phase with a lot of
 developer participation, so if we were to consider it we'd need to
 fork the tree and implement/maintain it in parallel to main tree
 maintenance, imo.  A translation script could probably also be used to
 convert *DEPEND into DEPENDENCIES automatically for any packages that
 dev's aren't manually managing...

 ...But I digress; we're nowhere near doing this yet.

An intermediate form of that might be useful for auditing the tree and
finding packages which aren't expressing, e.g. RDEPENDS, but probably
should.

-- 
:wq

Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching

[Michael Mol]

On Tue, Sep 4, 2012 at 12:43 PM, Michał Górny mgo...@gentoo.org wrote:
 Hello,

 As Sid Hayn raised today on #gentoo-portage, it would be useful to
 finally have portage able to fetch updates from VCS-es independently
 of src_unpack(). This could be used, for example, on machines
 temporarily connected to the network -- one would then fetch files
 while connected to the network, and perform the updates later.

 There are a few ways how we could handle that but the cleanest and most
 universal one seems to be defining a src_fetch() phase function
 in a future EAPI.

 In the EAPIs supporting src_fetch(), that phase function would be used
 by PM when requesting the files to be fetched. A default_src_fetch()
 will be declared as well, providing implementation-defined code
 fetching files like they are fetched now. Older EAPIs will simply
 always use that default.

 The phase function would be disjoint from the normal merge process,
 much like pkg_pretend(). In portage, it will be called as 'portage'
 user if FEATURES=userfetch is enabled.

 VCS eclasses supporting separated fetching would define two phase
 functions:
 - src_fetch() which would be responsible for fetching updates,
 - src_unpack() which would be responsible for checking out the source
   to work directory.

The 'checking out' language for src_unpack() sounds like it assumes a
DVCS such as mercurial or git. What about cvs or svn, where fetching
is also checking out? (This is probably a trivial thing to clear up,
though.)

Also, where would the local copy go? distfiles? It's common for
distfiles to be stored on, e.g. an NFS mount, so you may need to be
careful not to place repositories there which have filesystem
semantics that are disagreeable to NFS. (The only example I know of
off the top of my head is svn, where the documentation warns against
using the dbd backend on top of NFS.)

Other common remote mounts (such as cifs) may have restrictions that
could force munging of filenames, too, and VCS infrastructures (or
even unpacked checkouts with strange filenames) placed on those
filesystems may have unanticipated results.

It may be helpful to have some kind of adapter mount in place, or even
generate a tarball of the local copy and store that instead. (That'd
be problematic if multiple boxes were modifying the local copy on the
same share, but that's obviously problematic anyway.)

-- 
:wq

Re: [gentoo-dev] EJOBS variable for EAPI 5? (was: [RFC] Create a JOBS variable to replace -jX in MAKEOPTS)

[Michael Mol]

On Sat, Sep 1, 2012 at 8:20 PM, Brian Harring ferri...@gmail.com wrote:
 On Fri, Aug 31, 2012 at 11:12:44AM -0400, Alexis Ballier wrote:
 On Fri, 31 Aug 2012 15:45:21 +0100
 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:

  On Fri, 31 Aug 2012 10:21:15 +0200
  Ulrich Mueller u...@gentoo.org wrote:
   Coming back to this old topic [1]. Is there still consensus that we
   should have such an EJOBS variable? (It shouldn't be called JOBS
   because this name is too generic, see the old discussion.) Then we
   could add it to EAPI 5.
  
   Ulrich
  
   [1]
   http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml
 
  If we're doing this, do we tell users to stop setting MAKEOPTS for
  EAPIs 5 and greater?

 How can this work ? I cant think of any simple solution.

  Do we change the name of MAKEOPTS for EAPIs 5 and
  greater instead? Do we put fancy code in the package mangler to deal
  with it?

 IMHO EAPI-5 compliant PMs should do MAKEOPTS=$MAKEOPTS -j$EJOBS for
 every EAPI; using EJOBS from ebuilds/eclasses is allowed only in EAPI 5
 and greater.
 This is retroactive but could be classified 'PM internals' so its fine
 imho.

 This approach is fine imo, although I'd *potentially* look at adding a
 magic $PROC_COUNT var that is the # of cpu threads on the system;
 either that or defaulting jobs to it.

 I rather dislike requiring users to go jam a 2/4/8 in there when it's
 easy to compute.  That said, it's minor.

On this point, I use dynamic load-based job counting. I'd be using
distcc, too, but I don't have the spare hardware for a second build
box right now.

For a single box, I target a load average of $PROC_COUNT, with a max
jobs in the vicinity of 2x$PROC_COUNT, to prevent I/O hangs from
causing job count explosions. (Where I/O hiccups aren't a concern,
I've found leaving --jobs open-ended worked fine, but builds always
eventually expand to consume available I/O as upstream things get
larger) I find this works very well; emerge and make both manage to
lurk near the optimum point of keeping the CPU busy without spending
too much time in context switches.

In a distcc context, I would most likely target a load average of
$LOCAL_PROC_COUNT, with a max jobs of
(2*$LOCAL_PROC_COUNT+$REMOTE_PROC_COUNT).

If ebuilds are try to be more aware of parallel-build contexts, I
think it's important they're not limited to static job counts.

-- 
:wq

Re: [gentoo-dev] EAPI usage

[Michael Mol]

On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber j...@gentoo.org wrote:

[snip]

 Developers have only a limited amount of time, and this will eat into
 it.  The result is likely to not be new shiny ebuilds that use the new
 EAPIs, but rather old rusty ones that still use the old EAPI but also
 which contain other bugs, since they don't get touched at all (since
 touching them triggers the new policy).

 You dont need to touch the old ebuild, but if you are touching it for example
 a version bump, a bug fix etc you should be able to do the EAPI bump as long 
 as
 you have done the ebuild quizzes ;)

I'm a proxy maintainer. Meaning I haven't done these quizzes. Heck,
I've never even seen them. I catch bug reports, come up with a
solution and pass it back to Markos, who then decides whether or not
to put it in and give feedback.

How would this impact me?


 For a real-world analogy - look at the result of well-intended laws
 that require ADA compliance and such on building modifications.  The
 result is often stuff like kids taking classes in modular trailers and
 such because in order to add an extension to the building you need to
 bring the entire building up to code (and not just the new part).  The
 result isn't more elevators and ramps - but the use of hacked together
 solutions to work around the policy.

 Examples?

Every single hack you've ever seen which was written to get a unit
test to pass, but makes the code more difficult to modify or refactor
in the future.


 If it ain't broke, don't fix it.

 Essential part of software development is refactoring to get the code in a
 modern state.

As a professional software developer, I can say that the decision to
refactor or not is couched deeply in the question of whether or not it
makes sense to do it at that moment. Typically, you don't refactor
unless time pressures are sufficiently low, or unless you can see some
specific way that the refactor will save you time in the very near
future.

The latter condition will happen normally for a maintainer. But all
maintainers are volunteers, which means time pressures are always
high. (Especially if they have lives outside of Gentoo.)

-- 
:wq

Re: [gentoo-dev] EAPI usage

[Michael Mol]

On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman ri...@gentoo.org wrote:
 On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius a...@gentoo.org wrote:

 The primary benefit to the policy that dev's should bump EAPI when
 bumping ebuilds is so that older inferior EAPIs can be deprecated and
 eventually removed from the tree.

 What is the benefit from removing the old EAPIs?

I can answer this one...removing old EAPIs simplifies code for things
which need to be EAPI-aware. There are no bugs in code that doesn't
exist.

-- 
:wq

Re: [gentoo-dev] EAPI usage

[Michael Mol]

On Thu, Aug 30, 2012 at 3:47 PM, Thomas Sachau to...@gentoo.org wrote:
 Michael Mol schrieb:
 On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman ri...@gentoo.org wrote:
 On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius a...@gentoo.org wrote:

 The primary benefit to the policy that dev's should bump EAPI when
 bumping ebuilds is so that older inferior EAPIs can be deprecated and
 eventually removed from the tree.

 What is the benefit from removing the old EAPIs?

 I can answer this one...removing old EAPIs simplifies code for things
 which need to be EAPI-aware. There are no bugs in code that doesn't
 exist.


 Like package managers?

 Sorry, but this is not true, since you can never assume, that older
 EAPIs dont exist any more (even a simple EAPI-0 ebuild, which never
 needed a bump, is enough), so older EAPI versions have to be supported
 forever.

I would assume that's what auditing is for. Unless I'm sorely mistaken
(and I may be; I don't know much at all about eclasses), it should be
fairly simple to script through the tree to find any eclasses or
ebuilds which express a dependency on an EAPI of a given level,
presuming the expression is of a standard form.

Compile a list of existing ebuilds which depend on old EAPIs, and
you've got a TODO list. (eclasses, I don't know; I don't know if
eclasses explicitly express EAPI compatibility in metadata) Once that
list is cleared, yes, you can assume there are no ebuilds with a
specified EAPI of 0. I'd presume it would have been made widely known
that new ebuilds shouldn't use the old EAPI by that point, and so
support for the deprecated EAPI level can be abandoned.

Out-of-tree ebuilds pose their own problems, but that's a matter for
the managers of the relevant overlays.

Now, for the million-dollar question: Who should do the work? My
answer would be whoever wants it done. Whoever wants the work done
can go through their audit list and submit the relevant patches to the
maintainers. Whether that's a team of twenty people or the work of an
individual with a shell script and a lot of time on his hands, that's
where that kind of work belongs. Now, if a maintainer rejects the
patch, then the submitter can fix the patch to the maintainer's
specifications. If the maintainer rejects the patch on some principle,
that's an issue that can be raised and dealt with rationally at the
time it happens. I imagine most maintainers would welcome assistance,
especially if it means simplifying future work they may need to do.

-- 
:wq

Re: [gentoo-dev] remove system set?

[Michael Mol]

On Fri, Aug 17, 2012 at 9:03 PM, Rich Freeman ri...@gentoo.org wrote:
 On Thu, Aug 16, 2012 at 11:26 PM, Michael Mol mike...@gmail.com wrote:
 Bootstrapping is an inherently curious problem. Most systems are built
 upon the systems they themselves build, but getting to that
 self-hosting state always requires some unclean solution.

 Yup, I never viewed getting rid of @system as a solution to the
 bootstrapping problem.  You could even have an @stage3 set for
 convenience, or a meta-virtual to create one, using a fully
 functioning Gentoo system.  I also wasn't suggesting we have empty
 stage3s or anything like that.  By all means supply a default
 collection of packages, and feel free to include openssh in that
 collection.  However, those default packages would be nothing more
 than a starting point and users could uninstall them at will.  Perhaps
 portage would have some set it would offer a warning before
 uninstalling (either a hardcoded list like @system, or use logic like
 any dep of portage or gcc).

Sure, this makes perfect sense to me. It does depend on having
dependency logic fully expressed, and not dependent on @system as an
inherent dependency. But that's something that ought to be a long-term
goal, not a short-term goal, just based on the amount of work required
to get there, and possibly the work required to maintain it.

Incidentally, I'm pretty sure portage already does offer a warning
when you might unmerge a package that's in @system; on a fresh
install, the first --depclean will try to remove nano, and portage
warns the user.

-- 
:wq

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Michael Mol]

On Thu, Aug 16, 2012 at 3:51 PM, Gregory M. Turner g...@malth.us wrote:
 On 8/16/2012 4:59 AM, Rich Freeman wrote:

[snip]



 tldr: I like, approve and otherwise +1 the idea of somehow paring down or
 eliminating @system but I think it's going to be fairly challenging, so more
 discussion on this topic is warranted in my humble non-developer opinion :)

 --

 I really like everything you have to say here.  Unfortunately, assumptions
 of toolchain availability have gotten into the DNA of Gentoo in ways that
 make it nontrivial -- although probably not rocket science, either -- to
 implement these ideas.

The limited-visibility build feature discussed a week or so ago would
go a long way in detecting unexpressed build dependencies.

-- 
:wq

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Michael Mol]

On Thu, Aug 16, 2012 at 9:26 PM, Rich Freeman ri...@gentoo.org wrote:
 On Thu, Aug 16, 2012 at 4:05 PM, Michael Mol mike...@gmail.com wrote:
 The limited-visibility build feature discussed a week or so ago would
 go a long way in detecting unexpressed build dependencies.

 I can't say that is a coincidence, but my intent would be to include
 @system as implicit dependencies, at least until we change that policy
 (though the morbidly curious could use that as a test in a tinderbox
 to find packages in @system that are good candidates for removal).

 I haven't gotten to test it, but after studying sandbox it shouldn't
 be hard to just hack together a manual test by removing read access to
 root from the config files and adding in a bazillion files. That
 should at least let me profile performance/etc.  I'm not convinced
 that there isn't room for improvement, but if it works well as-is then
 automating this shouldn't be hard at all.  If portage has the
 dependency tree in RAM then you just need to dump all the edb listings
 for those packages plus @system and feed those into sandbox.  That
 just requires reading a bunch of text files and no searching, so it
 should be pretty quick. As far as I can tell the relevant calls to
 check for read access are already being made in sandbox already, and
 obviously they aren't taking forever.  We just have to see if the
 search gets slow if the access list has tens of thousands of entries
 (if it does, that is just a simple matter of optimization, but being
 in-RAM I can't see how tens of thousands of entries is going to slow
 down a modern CPU even if it is just an unsorted list).

Yeah, I presumed you'd have @system as a set of implicit dependencies.
The obvious approaches would be to either temporarily remove a package
from @system, tell the portage to ignore a package while doing limited
visibility, or copy @system to a different, temporary set and remove
things piecemeal from there.

That last might make the most sense. --implicit-dependencies ---
defaults to @system. Additional instances append to the set of
implicit dependencies. Use, e.g. -${ATOM} or -@system to override
default include.

-- 
:wq

Re: [gentoo-dev] remove system set?

[Michael Mol]

On Thu, Aug 16, 2012 at 11:13 PM, Doug Goldstein car...@gentoo.org wrote:
 On Thu, Aug 16, 2012 at 7:05 AM, Rich Freeman ri...@gentoo.org wrote:

[snip]


 It is only useful for situations where people want to do something
 unusual.  Some would argue that this is the only situation where
 Gentoo is useful.  If I wanted a system just like everybody else's I
 guess I'd run Ubuntu, if not Windows or OSX.

 In any case, I do agree that getting there is associated with pain.  I
 just like to think that getting there someday would be nice.  I know
 that a systematic effort exists in mathematics to try to reduce all of
 math to a minimum set of axioms and have everything else be formally
 derived.  I consider that a thing of beauty, even if I don't care to
 read the two volumes necessary to get to 1+1=2.

 Rich


 The other point of the system set is to get rid of the chicken and egg
 problem. For example, virtually every package in the system set ships
 as a tar, including tar itself. All the compression utilities ship as
 tars, which need to be installed to build tar (think -z, -j, -J). You
 need a standard C library to run virtually everything including tar,
 which you need to extract your standard C sources. The list goes on.

Bootstrapping is an inherently curious problem. Most systems are built
upon the systems they themselves build, but getting to that
self-hosting state always requires some unclean solution. (E.g. the
first C compiler couldn't have been written in C. The first x86
assembler wouldn't have been written in x86 assembler. Etc.)

Ideally, you'd want as narrow a bootstrapping channel as possible.
Assuming things start off statically linked, what's the sequence for
going from an empty chroot to stage 1, 2, 3...? What are the starting
conditions?


-- 
:wq

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Michael Mol]

On Wed, Aug 15, 2012 at 2:21 PM, Duncan 1i5t5.dun...@cox.net wrote:

 Rich Freeman posted on Wed, 15 Aug 2012 06:27:41 -0400 as excerpted:

  Right now having decent KDE and Gnome support with all the bells and
  whistles[...] isn't that hard, [It] will likely get harder, which means
  in practice what we'll probably have is a reasonable compromise which
  will never be quite as polished in any one direction as it could be,
  unless the end user does the polishing.

 Well stated.

  RE you concerns about OpenRC being in @system.  Personally I'm a fan of
  getting rid of @system entirely except as something used to build
  install CDs or having some sets for convenience in building systems. It
  only exists for a few reasons that I can think of:
  1.  Devs don't want to have ebuilds that capture dependencies on every
  little thing.  A few well-chosen virtuals like shell utilities or
  whatever might help with this.
  2.  Things like Prefix rely on the system not installing local copies of
  libraries in the core system it needs to link to.  Careful use of
  package.provided in profiles might address this.
  3.  We'd need many more virtuals to handle situations like FreeBSD where
  people don't what GNU on their systems.  Right now if they are system
  packages they just define system appropriately and ebuilds don't
  directly pull in the GNU stuff anyway.

 AFAIK, @system also helps resolve a few nasty circular dependencies.  In
 fact, I believe that's it's primary purpose.  As such I'm not sure it's
 practical (as opposed to possible, cost/benefit simply makes it
 impractical) to entirely get rid of, but it does occur to me that sets
 would be an interesting way to go.  Define a few sets that together
 compose @system as we have it today, and basically package.provide them
 during the bootstrap phase.

 AFAIK the original stage tarball also contains a minimal installed tree,
 for similar reasons.  I'm not actually sure how they interact.  That'd be
 releng/arch/catalyst territory.

Just piping up here, as this relates to an idea that's been
percolating through my mind for a couple weeks.

I've occasionally noticed portage tell me about circular dependencies,
where the most straight forward resolution is to emerge some package
in the loop twice. The first time, with a USE flag disabled (avahi and
gtk are the usual suspects), and the second time with the USE flag
enabled.

In circumstances where it's necessary to do something like that to
reach a final desired system state, I'm not sure I see any problem
with portage automatically doing the two-stage emerge.

It also sounds like something like that could be a benefit to shrinking @system.

As far as things such as libc, where many, many packages require their
use, I don't personally see a problem with recommending that ebuilds
depend on them. My only other notable experience for Linux
distributions is Debian/Ubuntu, and a quick glance shows 16,389
packages expressing explicit dependencies on libc6 in Ubuntu 12.04.

--
:wq

Re: [gentoo-dev] Re: Questions about SystemD and OpenRC

[Michael Mol]

On Wed, Aug 15, 2012 at 3:26 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Wed, 15 Aug 2012 15:18:24 -0400
 Michael Mol mike...@gmail.com wrote:
 I've occasionally noticed portage tell me about circular dependencies,
 where the most straight forward resolution is to emerge some package
 in the loop twice. The first time, with a USE flag disabled (avahi and
 gtk are the usual suspects), and the second time with the USE flag
 enabled.

 In circumstances where it's necessary to do something like that to
 reach a final desired system state, I'm not sure I see any problem
 with portage automatically doing the two-stage emerge.

 That's going to be rather horrible when your package mangler
 temporarily turns off acl or turns on build...

Fair observation; there would need to be a way either weight benign or
dangerous USE/package flags, and search paths with weights outside of
a 'safe' range would be discarded.

A mechanism like that also offers a means of finding and favoring
cheap rebuilds over expensive ones; rebuilding gcc an extra time ought
to be disfavored over rebuilding, say, sudo.

-- 
:wq

Re: [gentoo-dev] pid 1 design

[Michael Mol]

On Thu, Aug 9, 2012 at 4:37 PM, Michał Górny mgo...@gentoo.org wrote:
 On Thu, 9 Aug 2012 22:27:37 +0200
 Peter Stuge pe...@stuge.se wrote:

 Rich Freeman wrote:

[snip]

  Systemd isn't a like-for-like replacement for traditional inits.
  It aims to be much more, so this is a bit of an apples-to-oranges
  comparison.

 Yes, it is much more, which is a very nice thing on the systems
 it supports. I believe systemd is not usuable at all outside Linux
 and will not likely ever be, so for prefix there will anyway always
 be systemd alternatives in Gentoo! And on those systems the service
 files should never be installed.

 Considering that systemd unit files are sometimes shipped with upstream
 packages, and often they are practically equivalent to openrc init
 scripts, I'd rather see openrc supporting that file format
 as an extension and using it instead of duplicating the same thing
 in init.d scripts.

 And yes, that means that people masking service files shoot themselves
 in the foot.

 Also, if I had more time (or support), I'd probably start working
 on a systemd-compatible init system with a more portable design.

I would find this very interesting. I doubt I could find time for much
active contribution, unfortunately, but I'd help where I could.


  Again, I'm not sure that it HAS to work the way it does

 I would say that it does, because it is required in order to
 accomplish what systemd wants to deliver.

 Not necessarily. You can move many 'extra' systemd features outside of
 PID 1. For example, unit dependency trees are complex by definition
 and practically not necessary for PID 1.

 In other words, it could be designed to move more complex (and thus
 risky) tasks outside of PID 1.

+1

-- 
:wq

Re: [gentoo-dev] Global Systemd USE Flag

[Michael Mol]

On Wed, Aug 8, 2012 at 11:14 AM, Michał Górny mgo...@gentoo.org wrote:
 On Wed, 8 Aug 2012 16:48:20 +0200
 Jason A. Donenfeld ja...@zx2c4.com wrote:

 On Wed, Aug 8, 2012 at 4:45 PM, Michał Górny mgo...@gentoo.org
 wrote:
  Not everyone uses bash. Not everyone cares at all about
  bash-completion. What is your point?

 I'm not saying I agree with the removal of bash-completion flag (that
 discussion is for elsewhere), but just that your analogy doesn't hold.

 zx2c4@Dell /usr/lib/systemd $ equery d bash|grep portage
 sys-apps/portage-2.2.0_alpha120

 As you may or may not know, portage does not use bash completion. Bash
 completion is a strictly interactive-shell feature.

Pretty sure he was responding to your statement 'not everybody uses
bash', not to your statement about bash completion.

-- 
:wq