Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 19:41, Walter Dnes  wrote:
> On Mon, Mar 12, 2012 at 05:12:28PM +, Ciaran McCreesh wrote
>
>> This whole thing is just an exercise in trying to find excuses not to
>> use GLEP 55.
>
>  A filename should not be (ab)used as a database.  The main argument for
> GLEP 55 is that it would make ebuild-processing generic.  I.e. making
> ebuild info available to whatever future ebuild processor replacement
> for bash was used.  A couple of comments...
>
> 1) Let's talk generic.  Right now, we're talking about EAPI.  In future,
> what other (meta)data and characteristics will we need to know?  What
> else will be tacked onto the filename?  EAPI, and any other critical
> (meta)data should be declared early on in the ebuild.  That's what the
> ebuild is for.
>
> 2) Any potential ebuild processor that's incapable of looking for regex
> "^EAPI=" in a textfile, amd parsing the numbers that follow, has no
> business being used to process ebuilds.
>


Yeah, the only other concept I wanted to see addressed for technical
concerns is a per-package metadata file ( that is *not* metadata.xml )
that intends to associate out-of-band metadata with files in the
package's directory.

Consider  if it were in .json , just for ease of explaining the concept

category/package/
package-foo-1.2.ebuild
package-foo-1.2.3.ebuild
metamap.json

And in metamap.json :

{
"_metamap" : {  "api-version" : 1 },
"package-foo-1.2.ebuild" : {   "eapi" : "6" },
"package-foo-1.2.3.ebuild" : { "eapi" : "7" }
}

Yes, I'm aware this imposes some limitations on editing files somewhat.

But I don't think I've seen this specific concept has seen a proper
fleshing out/destruction yet.

Really, I've seen lots of interesting ideas thus far, but I'm having
trouble keeping the pros / cons of each variant of each approach in my
head, and Glep55 wins by default because it fits better in my
short-term-memory =).

( Yes, yes, I stuck a _metamap key with attached _metamap api version
subkey *just* in case the format of the metamap needs to change.  If
you want to have a metametamap, well, I guess thats why we have
hallucinogens ;) )

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Walter Dnes]

On Mon, Mar 12, 2012 at 05:12:28PM +, Ciaran McCreesh wrote

> This whole thing is just an exercise in trying to find excuses not to
> use GLEP 55.

  A filename should not be (ab)used as a database.  The main argument for
GLEP 55 is that it would make ebuild-processing generic.  I.e. making
ebuild info available to whatever future ebuild processor replacement
for bash was used.  A couple of comments...

1) Let's talk generic.  Right now, we're talking about EAPI.  In future,
what other (meta)data and characteristics will we need to know?  What
else will be tacked onto the filename?  EAPI, and any other critical
(meta)data should be declared early on in the ebuild.  That's what the
ebuild is for.

2) Any potential ebuild processor that's incapable of looking for regex
"^EAPI=" in a textfile, amd parsing the numbers that follow, has no
business being used to process ebuilds.

-- 
Walter Dnes 

[gentoo-dev] Re: RFD : .ebuild is only bash

[Duncan]

Alec Warner posted on Mon, 12 Mar 2012 15:53:58 -0700 as excerpted:

> On Mon, Mar 12, 2012 at 3:37 PM, Kent Fredric 
> wrote:
>> On 13 March 2012 11:02, Mike Gilbert  wrote:
 The previous council's decision does not prevent this same glep from
 going to the council again (decisions are not forever.) [...]
 Having the full notes would be helpful in determining why
 it was turned down back then; I'm sure a copy of the notes exist.
>>>
>>> http://www.gentoo.org/proj/en/council/
>>> http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt
>>>
>>>
>> Well that was insightful. As suspected,, there was a lot of people
>> saying "Yeaahh, I don't like it", and concluding there were problems
>> with it, but the actual technical issues still haven't been presented
>> to us.

>> Can somebody present a real ( or even theoretical ) problem that could
>> arise from having the EAPI in the filename that isn't some abstract
>> hand-waving?

> In general there was the 'I don't like it crowd (I was one of these, I
> care less these days ;p)'
> There was the 'it is Ciaran crowd.' This concept is difficult to
> describe without a fair bit of context in how the community was being
> run at the time.

Sometimes I wonder at how much more pleasant the dev-list in particular 
is these days.  It's as if people grew up and learned how to have a 
reasonable discussion.  Meanwhile, I doubt anyone who survived those days 
wants to relive them, for sure!  So let's just agree not to kick that 
sleeping dog any more than we already have, lest he wake up!  The posts 
are after all archived for those newbies who wish to see for themselves 
what the veterans of the era would rather leave well enough alone.

> None of the above reasons are what I would term 'technical merits.'
> However now (as then) not all decisions are made on their technical
> merits. We have adopted (and continue to adopt) solutions that are
> imperfect, technically silly, or otherwise lots of work because they
> meet some goal we are trying to accomplish. I don't think Gentoo is
> alone in this aspect of management.

IMO the real reason for the g55 "no" back then, was that whatever the 
technical merits of the various solutions were, the discussion was simply 
too politically and interpersonally poisoned to handle in any reasonable 
way.  Gentoo lost some good folks around that time, and if the council 
had moved forward with ANY of the more forward looking proposals, 
including g55 but not limited to it, it would have very likely triggered 
a split of gentoo into at least two, likely three or four different 
factions, and gentoo as we know it would have gone the way that the zynot 
fork went...  Honestly, as bad as things were at the time and knowing 
that there ARE unstable folks like Hans Reiser around in the FLOSS 
community, I wouldn't have been /that/ surprised if someone really DID 
take it too far.  Yes, things were THAT bad!

Tho it's worth noting that the 2010 date of the log above was, I think, 
after the worst of it was over, but it was still too poisoned to deal 
with in any reasonably sane way.

Luckily, the council had the wisdom to more or less punt, voting down g55 
AND the other discussed solutions, basically sticking with what we had, 
with minor tweaks, until things calmed down.  It is my opinion that they 
really did very possibly prevented the rather bad end of gentoo by doing 
so.  But they did leave the door open, calling for further study of the 
issues.

When I saw this thread start, I wondered if enough time had passed...


The most encouraging thing about this current discussion for me as a list 
veteran of that era, is that despite all the posts so far, the debate has 
remained reasonably civil.  People are debating hard for their 
viewpoints, but nobody's crossing the line and making it personal as was 
the unfortunate norm back then, and people approaching the line are 
quickly nudged back away from it.

I honestly don't know if it's something that can be reasonably dealt 
with, yet.  I honestly don't know how pressing is the need to deal with 
it /now/ vs perhaps punting it a couple more years.

Either way, the simple fact that we're discussing it as sane humans 
instead of as a pack of wild dogs, viciously snarling and snapping at 
each other, is progress.

For the record, I agree with someone else, sorry I don't remember who, 
that said it seems that a lot of folks seem to want glep55 now, just not 
by that name.  Ultimately, I believe at least the one-shot variant, 
possibly with additional later shots but with each one well debated on 
its own merits to be SURE about it before moving forward (IOW, not an 
open-ended forever increasing series), with intermediate updates keeping 
the same filename structure in between, is about the best choice 
available.

But whether now's the appropriate time for that one-shot, and its 
details, I don't know.  At least our discussion is on sane terms, these 
days, something I don

Re: [gentoo-dev] RFD : .ebuild is only bash

[Richard Yao]

On 03/12/12 11:57, Kent Fredric wrote:
> On 12 March 2012 22:37, Brian Harring  wrote:
>> Ebuilds *are* bash.  There isn't ever going to be a PMS labeled
>> xml format that is known as ebuilds... that's just pragmatic reality
>> since such a beast is clearly a seperate format (thus trying to call
>> it an 'ebuild' is dumb, confusing, and counter productive).
> 
> 
> I think this notion should be concluded before we continue debating as
> to how best to implement EAPI declarations.
> 
> Is it really so fixed that ".ebuild" will only ever be bash ?
> 
> If thats the case, then G55 ( or something similar ) is practically
> guaranteed as soon as we want something non-bash.
> 
> 
> 
> 
> --
> Kent
> 
> perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
> 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
> 

I imagine that POSIX Shell is a possibility, although strict compliance
would mean abandoning a few extensions like the local keyword that are
probably rather useful in eclasses.

To make XML a viable substitute for bash, you will need to implement a
turing complete language in XML, which should probably preclude its use
in ebuilds. You would  likely have better luck with a functional
programming language, although you are more than welcome to demonstrate
otherwise.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring]

On Tue, Mar 13, 2012 at 06:14:23PM +1300, Kent Fredric wrote:
> On 13 March 2012 17:31, Brian Harring  wrote:
> > Worse, it actually makes parsing _worse_ than it already is. ??What G55
> > had going for it was ease of filtering out unsupported eapi's.
> > Literally just filter the readdir results. ??This behemoth Zac is
> > proposing basically requires throwing regex at it, and *is* able to
> > be tripped up since eapi's aren't strictly integers (1-prefix,
> > 4-python, 4-eapi3 if I wanted to intentionally be a dick and break
> > likely non-greedy implementations of the regex).
> 
> Eh? How? If you make "." a forbidden character in an eapi
> specificiation, and make "." the delimiter
> 
>   dev-foo/foo-bar-2.3.4.eapi5.eb
> 
> 
> 
> How does that require regex?

That works; note however that wasn't what was proposed. ;)

Still is god awfuly fugly though, and reliant on digits as the first 
character to be readable.  Consider exheres: 

dev-foo/foo-bar-2.3.4.eapiexheres.eb 

Or arfrever's personal EAPI: 

dev-foo/foo-bar-2.3.4.eapi4-python.eb 

Etc.  This isn't an improvement, it's a regression in readability 
bordering on intentionally hating the developer who has to deal with 
it.


> remove the .eb  , and the last token remaining is the eapi .
> 
> it doesn't clash with the existing system for 2 reasons, 1) the .eb
> extension   and 2)  "eapi5" is not a valid version token
> 
> > Same angle, embedding it into the version space means that there can
> > be conflicts w/ PN.
> 
> I'm confused as to how, can you give one theoretical example?

If you change the delimiter, it's not an issue; if it was left, 
consider dev-foo/blah-eapi2-1-eapi2.ebuild .  It's intentionally 
breaking it, but the point is that the issue *exists*, a problem that 
didn't before.  Change the delimiter and you can duck most of it 
although I suspect there still is a naggle or two.

That doesn't make parsing any prettier to implement however.


>   dev-foo/foo-bar-2.3.4.eapi5.eb  <-- eapi5 can't be a package name
> here, because its got the .eb suffix which means an EAPI *MUST* be
> specified
> 
> and eapi5 also can't be a package name there, because then you're
> telling be it tokenizes as:
> 
> category=dev-foo
> package=foo-bar-2.3.4.eapi5
> version  = undefined
> eapi  = undefined
> 
> Which is clearly illegal.

Just a general point.  You changed the delimiter- meaning the 
failures mostly go away.  My points were against Zac's original 
proposal, thus arguing those points don't actually exist (swapping the 
delimiter) is a bit of a wrong way to argue- argue "change the 
delimiter and it goes away" rather than "nuh uh, there isn't an 
issue".  Way less confusing.


> > Basically... embedding it into the versioning like that, besides being
> > ugly as all hell, discards the main benefit g55 had- clear
> > identification of EAPI.
> 
> It still seems "clear" to me.

"clear" means different things to different people.  For example, this 
code is actually clear to me:

class MockObject(dict):
  locals().update(
('__%sattr__' % x, getattr(dict, '__%sitem__' % x) for x in
('get', 'set', 'del'))

That code for everyone else is basically akin to eye-gouging w/ a 
follow up diddling of the new hole.  'Clear' is quite subjective being 
hte point.

EAPI mechanisms have to be designed for functionality, *and* ease of 
use for the general dev populace.  Having 

sys-apps/paludis-0.72.0-eapiexheres.ebuild

is *not* clearly parsable by the majority.  Were it parsable for the 
masses, that doesn't make it anything less than butt-fugly in my view.

If you really think it's great, convince others.  Ulm/Myself seem to 
view it fairly negatively, and I strongly doubt you're going to 
convince either of us to change those views.

~brian

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

> On Mon, 12 Mar 2012, Alec Warner wrote:

> The previous council's decision does not prevent this same glep from
> going to the council again (decisions are not forever.)
> Some folks seem to think that taking glep55 back to the council is
> not allowed somehow (or is perhaps futile, but that is a different
> issue ;p) Having the full notes would be helpful in determining why
> it was turned down back then; I'm sure a copy of the notes exist.

Of course, decisions can be reconsidered. However, GLEP 55 was first
posted in 2007. We've had five councils since then, and none of these
councils has accepted it.

Also, this is one of the most controversial GLEPs that we ever had.
Even if it solves the technical problem for the package manager, I
believe that embedding such metadata information in the filename is
misguided.

Then the argument that GLEP 55 would be the only solution which
doesn't require a waiting period. Instead, we've been discussing it
since more than four years now (so it looks like we were not in a
hurry, and the urgent matters from 2007 haven't been so urgent, after
all). If some of the other less controversial solutions had been
implemented in 2008 or 2009, this wouldn't be an issue today.

Ulrich

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Luca Barbato]

On 3/12/12 8:53 PM, Robin H. Johnson wrote:

On Mon, Mar 12, 2012 at 11:14:23PM -0400, Joshua Kinard wrote:

Yeah, I think it's an easy fix either in openrc or in an initscript
somewhere.  I changed nothing except my kernel (was missing devtmpfs -- it's
not under Filesystems!), uninstalled module-init-tools, and installed kmod +
udev-181.  Then rolled back the snapshot once I had the results.

When udev is linked against a library in /usr, this is not going to work
anymore, because udev won't start at all.


So you need need a smaller udev that is completely self contained and 
make sure anything needed for the key rules works. I wonder if the 
pci-ids cannot stay somewhere in /etc or /lib


lu

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 17:31, Brian Harring  wrote:
> Worse, it actually makes parsing _worse_ than it already is.  What G55
> had going for it was ease of filtering out unsupported eapi's.
> Literally just filter the readdir results.  This behemoth Zac is
> proposing basically requires throwing regex at it, and *is* able to
> be tripped up since eapi's aren't strictly integers (1-prefix,
> 4-python, 4-eapi3 if I wanted to intentionally be a dick and break
> likely non-greedy implementations of the regex).

Eh? How? If you make "." a forbidden character in an eapi
specificiation, and make "." the delimiter

  dev-foo/foo-bar-2.3.4.eapi5.eb



How does that require regex?

remove the .eb  , and the last token remaining is the eapi .

it doesn't clash with the existing system for 2 reasons, 1) the .eb
extension   and 2)  "eapi5" is not a valid version token

> Same angle, embedding it into the version space means that there can
> be conflicts w/ PN.

I'm confused as to how, can you give one theoretical example?

  dev-foo/foo-bar-2.3.4.eapi5.eb  <-- eapi5 can't be a package name
here, because its got the .eb suffix which means an EAPI *MUST* be
specified

and eapi5 also can't be a package name there, because then you're
telling be it tokenizes as:

category=dev-foo
package=foo-bar-2.3.4.eapi5
version  = undefined
eapi  = undefined

Which is clearly illegal.

> Basically... embedding it into the versioning like that, besides being
> ugly as all hell, discards the main benefit g55 had- clear
> identification of EAPI.

It still seems "clear" to me.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Luca Barbato]

On 3/11/12 10:33 AM, William Hubbs wrote:

On Sat, Mar 10, 2012 at 07:28:41PM -0800, Luca Barbato wrote:

On 3/10/12 6:53 PM, Rich Freeman wrote:

neither the genkernel nor dracut docs have specific instructions about


I guess we could pour more effort in getting dracut more easy to use
and/or try to figure out which are the items that should be moved to /
and fix the remaining ones...


I highly discourage moving more things to /.  If you google for things
like, "case for usr merge", "understanding bin split", etc, you will
find much information that is very enlightening about the /usr merge and
the reasons for the /bin, /lib, /sbin ->  /usr/* split.


Our current init system doesn't have any problem with /usr being mounted 
later, but udev might have issues.


Same could be said about bluez and dbus.


I'll start another thread about this farely soon, but for now I'll say
that even though Fedora is a strong advocate of the /usr merge, it
didn't start there. Solaris started this 15 years ago, and I think it
would be a good thing for gentoo to implement the /usr merge at some
point to make us more compatible with other unixes. Another thing to add
is that it appears that at least Fedora and Debian are doing this.


Hurd got it first if I recall correctly. But hurd is a bit fringe I'd say.

lu

Re: [gentoo-dev] RFD : .ebuild is only bash

[Brian Harring]

On Mon, Mar 12, 2012 at 07:17:31PM +0100, Ulrich Mueller wrote:
> > On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> 
> > On Mon, 12 Mar 2012 19:00:32 +0100
> > Ulrich Mueller  wrote:
> >> > On Mon, 12 Mar 2012, Zac Medico wrote:
> >> > If we do go with a variant of GLEP 55, I'd prefer a variant that
> >> > uses a constant extension (like .eb) and places the EAPI string
> >> > just after the version component of the name. For example:
> >> 
> >> >foo-1.0-r1-eapi5.ebuild
> >> 
> >> This is so ugly... I guess I'll retire the same day when such an
> >> abomination gets accepted. ;-)
> 
> > I'm sorry, we're down to "it's ugly and someone already said no and
> > I'll throw my toys out of the pram if I don't get my way" as the
> > arguments against GLEP 55 now?
> 
> Note the smiley in my posting. And yes, it _is_ ugly.

Worse, it actually makes parsing _worse_ than it already is.  What G55 
had going for it was ease of filtering out unsupported eapi's.  
Literally just filter the readdir results.  This behemoth Zac is 
proposing basically requires throwing regex at it, and *is* able to 
be tripped up since eapi's aren't strictly integers (1-prefix, 
4-python, 4-eapi3 if I wanted to intentionally be a dick and break 
likely non-greedy implementations of the regex).

Same angle, embedding it into the version space means that there can 
be conflicts w/ PN.

Basically... embedding it into the versioning like that, besides being 
ugly as all hell, discards the main benefit g55 had- clear 
identification of EAPI.

It ain't worth it.

~brian

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Robin H. Johnson]

On Mon, Mar 12, 2012 at 11:14:23PM -0400, Joshua Kinard wrote:
> Yeah, I think it's an easy fix either in openrc or in an initscript
> somewhere.  I changed nothing except my kernel (was missing devtmpfs -- it's
> not under Filesystems!), uninstalled module-init-tools, and installed kmod +
> udev-181.  Then rolled back the snapshot once I had the results.
When udev is linked against a library in /usr, this is not going to work
anymore, because udev won't start at all.

On many simple setups, yes, it's not going actually break much in my
testing on pure OpenRC.

udev starts in the sysinit runlevel, and /usr would normally only become
available later, in the boot runlevel, when localmount runs...

Consider this potential boot order:
sysinit/sysfs
sysinit/udev (fails without sysfs)
boot/modules (after udev, so udev rules work on modprobe)
boot/hwclock (needs rtc modules on some systems)
boot/fsck (after devices are available)
boot/root (after fsck)
boot/localmount (after fsck)

udev before modules is fairly critical for some hardware, so that it
gets configured properly.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Ian Stakenvicius]

On 2012-03-12, at 9:22 PM, Joshua Kinard  wrote:

> 
> And yes, I've already tested out udev-181 on a VM with a
> separate /usr.  With devtmpfs, the system fully boots just fine, no
> initramfs needed.  Guess what the only piece of software to mess up is?
> Udev.  I largely think it's a timing issue in OpenRC, however, because /usr
> DOES get mounted fairly quickly, but not before udevd starts.  But udevd
> does restart itself and everything looks to work fine.  If you aren't
> watching the terminal, you wouldn't even notice the failures.
> 


THANK YOU for testing this -- I could not forsee a reason, back when this 
process started, as to why openrc couldn't mount /usr before udev started.   
since devtmpfs should provide the source devnode anyways.  It's good to have a 
(near) proof of that.

Ian

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Joshua Kinard]

On 03/12/2012 21:37, Kent Fredric wrote:

> On 13 March 2012 14:22, Joshua Kinard  wrote:
>> I thought this up on a whim, it hasn't been tested nor vetted.  It's largely
>> meant as a joke, but also to provoke discussion on the current filesystem
>> design and the direction we're getting pulled in with Fedora's declaration
>> that separate /usr is broken.  I don't think it is and I don't find their
>> argument very convincing, and probably never will.
>>
> 
> Why don't we just quit with this linux nonsense and all switch to Mac,
> after all, it just works!
> 
> 
> 
> =p


The problem with that, is, that the system wouldn't boot without /itunes
being available, so you can't partition that one off :P

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Stabilization requests from users

[Duncan]

Marco Paolone posted on Mon, 12 Mar 2012 18:58:37 + as excerpted:

> Hello gentoo-dev team,
> scarabeus recently posted on his blog [1] about submission of
> stabilization requests from users. Since using bugzilla could be a mess
> of duplicated entries, I was thinking about a "Stabilization Party" once
> a month for example,
> in order to have a coherent list of stabilizations, and users working
> togheter with you developers. How does it sound?
> 
> [1]
> http://blogs.gentoo.org/scarabeus/2012/03/05/stabilisations-and-testing/

This reminds me of the "bug days" they used to have, once a month or once 
a quarter, some years ago.  I haven't read anything about that for "aeons" 
now (since before arch-testers, IIRC), I'd guess since the dev(s) 
coordinating them retired (?), but resurrecting that idea could be 
useful.  The stabilization party idea would then simply be the arch side 
of the coin, with package bugs being the maintainer side.

Either way, it takes a strong leader with a decent priority for it and 
the time to dedicate, to pull it off as a regular thing.  Without that, 
there might be one or two, but it'll peter out by #3 or 4...

AFAIK there used to be a bug-day keyword that could be added as well.
A dev could add that to any bug he thought could use some user testing, 
either to nail down or pre-stabilization, and the bug-day coordinator 
would pick bugs, mostly from that list, that he thought fit.  Of course 
users and devs could work on any bugs they chose on that day for their 
"bug day points", but the list was helpful for categorizing bugs that 
needed more testing that deep technical skill, and/or that could probably 
be fixed with just a few minutes to hours of work, reasonably doable in a 
small enough fraction of a day to allow someone to work on several the 
same day, if they had the time to dedicate.

Back then, user bug-day activity, IRC presence, etc, was a big door to 
recruitment.

It seems to me that many (not all) stabilization bugs should fit right 
in, but the idea was then and I believe should be again, broader than 
simply stabilization bugs, so more folks can participate.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: newsitem: unmasking udev-181

[Ryan Hill]

On Sun, 11 Mar 2012 21:08:47 +
"Robin H. Johnson"  wrote:

> The quickest initramfs, assuming that ALL kernel modules you need to
> boot are already compiled into your kernel:
> genkernel --install --no-ramdisk-modules initramfs
> 
> Plus optionally, If you know you don't need any of these, include this
> to make it really get much smaller:
> --no-lvm --no-mdadm --no-dmraid --no-multipath --no-iscsi --no-disklabel
> --no-firmware --no-zfs --no-gpg --no-luks
> 
> --disklabel is the one that most users will probably need, if they use
> LABEL= or UUID= arguments in your fstab.
> 
> That will give you an initramfs of scripts + busybox.
> On my box, it's about 724KiB.

Thank you sir.  The last time I played with genkernel I had to kill the
result with a crucifix.  This should do the trick.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature

[gentoo-dev] Re: newsitem: unmasking udev-181

[Ryan Hill]

On Mon, 12 Mar 2012 18:34:37 +
Sven Vermeulen  wrote:

> On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote:
> > We should really have some documentation on how to create a minimal 
> > initramfs
> > that mounts /usr (if we don't already, I haven't looked).  I've never needed
> > one until now and don't have the foggiest idea how it's done.  I can't be 
> > the
> > only one.
> 
> I just started the tracker [1] for the documentation changes and sent info
> to gentoo-doc mailinglist about it. The upcoming days, I'll have the needed
> updates trickle into the documents.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=407959

Thanks!


> > Also, the handbook still endorses having a separate partition for /usr and
> > includes it in the example setup.  This should be changed now, not when
> > stabilization time comes.  
> 
> It's an example, and we still endorse it. Only will we now tell users to use
> an initramfs with it.

That sounds good to me.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org


signature.asc
Description: PGP signature

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Kent Fredric]

On 13 March 2012 14:22, Joshua Kinard  wrote:
> I thought this up on a whim, it hasn't been tested nor vetted.  It's largely
> meant as a joke, but also to provoke discussion on the current filesystem
> design and the direction we're getting pulled in with Fedora's declaration
> that separate /usr is broken.  I don't think it is and I don't find their
> argument very convincing, and probably never will.
>

Why don't we just quit with this linux nonsense and all switch to Mac,
after all, it just works!



=p


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

[gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Joshua Kinard]

On 03/11/2012 13:33, William Hubbs wrote:

> I highly discourage moving more things to /.  If you google for things 
> like, "case for usr merge", "understanding bin split", etc, you will
> find much information that is very enlightening about the /usr merge and
> the reasons for the /bin, /lib, /sbin -> /usr/* split.
> 
> I'll start another thread about this farely soon, but for now I'll say 
> that even though Fedora is a strong advocate of the /usr merge, it
> didn't start there. Solaris started this 15 years ago, and I think it
> would be a good thing for gentoo to implement the /usr merge at some
> point to make us more compatible with other unixes. Another thing to add
> is that it appears that at least Fedora and Debian are doing this.



On a somewhat sarcastic note, why don't we just deprecate /usr and move
everything back to /?  Isn't that, largely, what is being accomplished here?
 Solaris at least keeps some kernel stuff in / off of /stand (I believe).
Linux, after this /usr thing is fully complete, about the only thing left in
/ that is of any value will be /etc.  Kernels were moved into /boot ages ago.

I mean, what really is / in the literal sense?  It's the first filesystem
that the kernel mounts.  If you put everything into /usr, including the init
scripts and /etc, create a few stub mount points for /var, /tmp, etc
(assuming those are separate partitions), then told the kernel that /usr is
/, what's the real difference?  So I think Fedora's approach, while copying
existing behavior from Solaris, is partially broken in this regard.

We should be working to getting rid of /usr and bring it all back into /,
then create temporary /usr symlinks to point programs in the right
direction.  After all, /usr was originally for user data, not system data,
until someone cooked up /home (I don't know the full exact history here, so
feel free to correct me).

Heck, why not redesign the original root filesystem layout while we're at it?

/ - Root.
/boot - Kernels, bootloader.
/apps - Installed, non-system critical applications.  Merges /bin,
/sbin, /usr/{bin,sbin}, /usr/local/{bin,sbin}, and /lib and
all of its multilib variants.
/core - System-critical apps needed to get the system into a MINIMAL,
usable state (core device detection, mounting disks, etc)
/conf - System configuration data.
/dev  - Device nodes.
/home - User stuff.
/data - Variable data.  /var's new name.
/tmp  - System-wide temp dir.
/virt - virtual filesystems (proc, sys, ramfs).
/svcs - Data dir for services (Apache, LDAP, FTP, etc).
/ext  - holds mount points for external devices (merges /mnt & /media).
/root - Superuser's /home.


From that, for the new proposed directories:

/apps/sys/bin - System binaries.  Only non-critical, system-wide binaries
go here.
/apps/sys/lib - Like /apps/sys/bin above.  Except this can also be
duplicated for multilib (lib32, lib64, lib128, etc).

/apps/std/bin - Standard program binaries for all non-system, non-critical
binaries.
/apps/std/lib - Like /apps/std/bin above.  Ditto for multilib.

/apps/local   - If on a stand-alone system, this is a symlink to /apps/std.
otherwise, this holds a bin/lib folder that is only for apps
installed locally, while /apps/std might be a network mount
that holds apps common to multiple systems of the
same/similar type of install.

/core/bin - Critical system, binaries needed to get the system into a
minimally-usable state.  Predominantly occupied by various
filesystem tools.
/core/lib - Libraries, usually static, to support /core/bin.  Can be
multilib, but a system should have a single ABI that can
successfully boot the userland components of the system.
/core/inf - Holds minimal information to identify and locate
boot-critical devices, typically in the form of a small
database of some design, but which can be parsed with
no additional dependencies.
/core/init- Home of your init system of choice, including all the
information needed for various run levels, etc.  Its
sub-layout is dependent on the particular init system that
is installed.

/conf - Basically a rename of /etc.  The "etc" name doesn't
convey any useful information to a user anymore about its
true purpose.  /conf, however, does.  Files stored here
will largely be comprised of text files that configure
various system services.  Like /etc, it's sub-layout will
probably be a complete, unrestrained mess.

/virt - Everyone loves virtual filesystems.  When there was just
/proc, everything was alright.  Then /sys comes along, and
now we've polluted the / namespace with two virtua

Re: [gentoo-dev] RFD : .ebuild is only bash

[Patrick Lauer]

On 03/13/12 02:28, Ciaran McCreesh wrote:
[snip lots of political rhetoric]
> 
> GLEP 55 is simple,
No.

> it solves all the problems we have
No, it just tries to shove them under the carpet

> (including the
> version issue, which everyone is conveniently ignoring),
Say what?

> it doesn't require us to guess what's going to happen next and it can be
> implemented immediately.
So can migrating the tree to posix-only "ebuilds", but at what cost, and
what do we gain from it?

> That's a rather big deal.
So is switching to Arch Linux.


... why would we want to do such things?!

Re: [gentoo-dev] RFD : .ebuild is only bash

[Patrick Lauer]

On 03/13/12 01:12, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller  wrote:
>> See above, even if we should ever move away from bash, GLEP 55 is
>> still not needed.
> 
> ...but we might as well go with GLEP 55 anyway, since GLEP 55
> definitely works, whereas other solutions might work so long as we
> don't do something unexpected.
> 
> This whole thing is just an exercise in trying to find excuses not to
> use GLEP 55.
> 

That kind of circular reasoning makes my head hurt.

We discussed that ... topic ... to death about three times over the last
2 years, and the same arguments still apply.

Put an EAPI-marker in a well-defined position near the top of the
ebuild, problem solved. If it needs more it's not an ebuild anymore and
we should consider fixing all the other annoying glitches we have at the
same time, which causes a backwards-incompatible tree format change,
which means we need to plan the whole thing properly.

Trying to nail on GLEP55 is just trying to fix issues arising from not
fixing issues properly, so *if* we want to change things for no apparent
reason we should change them properly.

Re: [gentoo-dev] RFD : .ebuild is only bash

[James Broadhead]

On 12 March 2012 22:37, Kent Fredric  wrote:
>
> Can somebody present a real ( or even theoretical ) problem that could
> arise from having the EAPI in the filename that isn't some abstract
> hand-waving?
>
> Not trying to be a troll here, but really, I still haven't seen any.

This isn't a real-world problem, but we're arguably over-loading too
much information into the filename already;
- package name
- package version
- ebuild revision
- (EAPI?)

Re: [gentoo-dev] RFD : .ebuild is only bash

[Alec Warner]

On Mon, Mar 12, 2012 at 3:37 PM, Kent Fredric  wrote:
> On 13 March 2012 11:02, Mike Gilbert  wrote:
>>> The previous council's decision does not prevent this same glep from
>>> going to the council again (decisions are not forever.)
>>> Some folks seem to think that taking glep55 back to the council is not
>>> allowed somehow (or is perhaps futile, but that is a different issue
>>> ;p) Having the full notes would be helpful in determining why it was
>>> turned down back then; I'm sure a copy of the notes exist.
>>
>> http://www.gentoo.org/proj/en/council/
>> http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt
>>
>
> Well that was insightful. As suspected,, there was a lot of people
> saying "Yeaahh, I don't like it", and concluding there were problems
> with it, but the actual technical issues still haven't been presented
> to us.
>
> While they're still batting for the alternative solutions, which there
> are known potential issues with.
>
> Or did I read it selectively?
>
> Can somebody present a real ( or even theoretical ) problem that could
> arise from having the EAPI in the filename that isn't some abstract
> hand-waving?
>
> Not trying to be a troll here, but really, I still haven't seen any.

In general there was the 'I don't like it crowd (I was one of these, I
care less these days ;p)'
There was the 'it is Ciaran crowd.' This concept is difficult to
describe without a fair bit of context in how the community was being
run at the time.

None of the above reasons are what I would term 'technical merits.'
However now (as then) not all decisions are made on their technical
merits. We have adopted (and continue to adopt) solutions that are
imperfect, technically silly, or otherwise lots of work because they
meet some goal we are trying to accomplish. I don't think Gentoo is
alone in this aspect of management.

The inherent problem of course is that these merits are not provable,
so one cannot 'win' an argument on 'aesthetically pleasing filenames';
thus we are doomed to discuss glep55 until someone makes a decision in
favor or the proponents of the GLEP stop trying to push it (which is
what happened last time.)

-A

>
>
> --
> Kent
>
> perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
> 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
>

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 11:02, Mike Gilbert  wrote:
>> The previous council's decision does not prevent this same glep from
>> going to the council again (decisions are not forever.)
>> Some folks seem to think that taking glep55 back to the council is not
>> allowed somehow (or is perhaps futile, but that is a different issue
>> ;p) Having the full notes would be helpful in determining why it was
>> turned down back then; I'm sure a copy of the notes exist.
>
> http://www.gentoo.org/proj/en/council/
> http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt
>

Well that was insightful. As suspected,, there was a lot of people
saying "Yeaahh, I don't like it", and concluding there were problems
with it, but the actual technical issues still haven't been presented
to us.

While they're still batting for the alternative solutions, which there
are known potential issues with.

Or did I read it selectively?

Can somebody present a real ( or even theoretical ) problem that could
arise from having the EAPI in the filename that isn't some abstract
hand-waving?

Not trying to be a troll here, but really, I still haven't seen any.


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFC: Change mail-mta/msmtp to be the default in virtual/mta instead of mail-mta/ssmtp ?

[Eray Aslan]

On 2012-03-12 10:20 PM, Robin H. Johnson wrote:
> One of the greatest things that bugs me about ssmtp is that if the
> mailserver is not available, it hangs for a while, and then it loses the
> email. 

To be fair, a queue-less design does keep it simple.

> Where I need a simple mail relay, I've gone with nullmailer instead,
> because it supports the features, and it explicitly has a lightweight
> daemon mode that queues mail to send.

msmtp: TLS/SSL and AUTH support.  Config can be easier.  No queue.
nullmailer:  AUTH support.  No TLS/SSL.  Easy to configure and use.  Has
a queue.

I like nullmailer better but usually go with msmtp.  TLS/SSL is usually
mandatory for login when emails go to some central mail hub and not
directly to MX hosts - which is pretty much guaranteed nowadays.  I am
not sure if we should install a TLS-less mailer by default.

Some documantation would be nice in either case.

-- 
Eray Aslan 



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Alec Warner]

On Mon, Mar 12, 2012 at 3:06 PM, James Broadhead
 wrote:
> On 12 March 2012 21:14, Ulrich Mueller  wrote:
>>> On Mon, 12 Mar 2012, James Broadhead wrote:
>>
>>> I'm sure that it's been considered already, but what are the arguments
>>> against embedding the EAPI on a per-package (default) or per-version
>>> basis in metadata.xml. It IS metadata after all.
>>
>> You can find a recent discussion in bug 402167, comment #4 and
>> following. 
>>
>> Ulrich
>>
>
> That makes sense (actually, it calls for metadata.xml to be converted
> to json even without bundling EAPI in there).
>
> If repoman validated metadata.json based on a clear definition in PMS,
> that would be a valid solution to the problem (that wouldn't require
> external libraries beyond python)
>

I'm not really convinced 'external libraries' is a critical problem;
it just seems like a nice thing to (try to) avoid.

-A

Re: [gentoo-dev] RFD : .ebuild is only bash

[James Broadhead]

On 12 March 2012 21:14, Ulrich Mueller  wrote:
>> On Mon, 12 Mar 2012, James Broadhead wrote:
>
>> I'm sure that it's been considered already, but what are the arguments
>> against embedding the EAPI on a per-package (default) or per-version
>> basis in metadata.xml. It IS metadata after all.
>
> You can find a recent discussion in bug 402167, comment #4 and
> following. 
>
> Ulrich
>

That makes sense (actually, it calls for metadata.xml to be converted
to json even without bundling EAPI in there).

If repoman validated metadata.json based on a clear definition in PMS,
that would be a valid solution to the problem (that wouldn't require
external libraries beyond python)

Re: [gentoo-dev] RFD : .ebuild is only bash

[Mike Gilbert]

On Mon, Mar 12, 2012 at 5:49 PM, Alec Warner  wrote:
> On Mon, Mar 12, 2012 at 2:28 PM, Kent Fredric  wrote:
>> On 13 March 2012 10:14, Ulrich Mueller  wrote:
 On Mon, 12 Mar 2012, James Broadhead wrote:
>>>
 I'm sure that it's been considered already, but what are the arguments
 against embedding the EAPI on a per-package (default) or per-version
 basis in metadata.xml. It IS metadata after all.
>>>
>>> You can find a recent discussion in bug 402167, comment #4 and
>>> following. 
>>
>> I note that there is a link to the council minutes, with the reason
>> for voting "no" against GLEP55 being "it has issues that are
>> unsolved", but I don't see any reference to said issues.
>>
>> Is the actual IRC transcript available? Because I'd hate for this
>> decision to have been made on the assumption of issues which didn't
>> really exist.
>
> The previous council's decision does not prevent this same glep from
> going to the council again (decisions are not forever.)
> Some folks seem to think that taking glep55 back to the council is not
> allowed somehow (or is perhaps futile, but that is a different issue
> ;p) Having the full notes would be helpful in determining why it was
> turned down back then; I'm sure a copy of the notes exist.

http://www.gentoo.org/proj/en/council/
http://www.gentoo.org/proj/en/council/meeting-logs/20100823.txt

[gentoo-dev] Stabilization requests from users

[Marco Paolone]

Hello gentoo-dev team,
scarabeus recently posted on his blog [1] about submission of stabilization
requests from users. Since using bugzilla could be a mess of duplicated
entries, I was thinking about a "Stabilization Party" once a month for example,
in order to have a coherent list of stabilizations, and users working togheter
with you developers. How does it sound?

[1] http://blogs.gentoo.org/scarabeus/2012/03/05/stabilisations-and-testing/

-- 
Linux Registered User #401479
GPG: 0x897AF14E

Re: [gentoo-dev] RFD : .ebuild is only bash

[Alec Warner]

On Mon, Mar 12, 2012 at 2:28 PM, Kent Fredric  wrote:
> On 13 March 2012 10:14, Ulrich Mueller  wrote:
>>> On Mon, 12 Mar 2012, James Broadhead wrote:
>>
>>> I'm sure that it's been considered already, but what are the arguments
>>> against embedding the EAPI on a per-package (default) or per-version
>>> basis in metadata.xml. It IS metadata after all.
>>
>> You can find a recent discussion in bug 402167, comment #4 and
>> following. 
>
> I note that there is a link to the council minutes, with the reason
> for voting "no" against GLEP55 being "it has issues that are
> unsolved", but I don't see any reference to said issues.
>
> Is the actual IRC transcript available? Because I'd hate for this
> decision to have been made on the assumption of issues which didn't
> really exist.

The previous council's decision does not prevent this same glep from
going to the council again (decisions are not forever.)
Some folks seem to think that taking glep55 back to the council is not
allowed somehow (or is perhaps futile, but that is a different issue
;p) Having the full notes would be helpful in determining why it was
turned down back then; I'm sure a copy of the notes exist.

-A

>
>
>
> --
> Kent
>
> perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
> 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
>

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 10:14, Ulrich Mueller  wrote:
>> On Mon, 12 Mar 2012, James Broadhead wrote:
>
>> I'm sure that it's been considered already, but what are the arguments
>> against embedding the EAPI on a per-package (default) or per-version
>> basis in metadata.xml. It IS metadata after all.
>
> You can find a recent discussion in bug 402167, comment #4 and
> following. 

I note that there is a link to the council minutes, with the reason
for voting "no" against GLEP55 being "it has issues that are
unsolved", but I don't see any reference to said issues.

Is the actual IRC transcript available? Because I'd hate for this
decision to have been made on the assumption of issues which didn't
really exist.



-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

> On Mon, 12 Mar 2012, James Broadhead wrote:

> I'm sure that it's been considered already, but what are the arguments
> against embedding the EAPI on a per-package (default) or per-version
> basis in metadata.xml. It IS metadata after all.

You can find a recent discussion in bug 402167, comment #4 and
following. 

Ulrich

Re: [gentoo-dev] newsitem: unmasking udev-181

[Robin H. Johnson]

On Sun, Mar 11, 2012 at 12:26:57PM -0500, William Hubbs wrote:
> An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25 or
> >=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
> sure any initramfs you create pre-mounts /usr.
Minor tweak:
>=sys-kernel/genkernel-3.4.25.1
As I missed enabling the new default.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFD : .ebuild is only bash

[James Broadhead]

On 12 March 2012 20:10, Ciaran McCreesh  wrote:
> On Mon, 12 Mar 2012 20:49:22 +0100
> Ulrich Mueller  wrote:
>> > That's already not the way things work, since different version
>> > strings can be equal versions (and it's illegal to do this),
>> > so it's not relevant to the discussion.
>>
>> This is a design flaw in our versioning system, and it can only occur
>> in some corner cases where version components have leading zeros.
>
> You know, if we had GLEP 55, we could fix that. Although it's debatable
> whether it's a flaw, since we're trying to match upstream version
> formats where reasonably possible.
>
> --
> Ciaran McCreesh

I'm sure that it's been considered already, but what are the arguments
against embedding the EAPI on a per-package (default) or per-version
basis in metadata.xml. It IS metadata after all.

Something like:
6  

4
3

Where the version attribute should presumably have the same syntax as
versions in package.* already.

Re: [gentoo-dev] RFC: Change mail-mta/msmtp to be the default in virtual/mta instead of mail-mta/ssmtp ?

[Robin H. Johnson]

On Mon, Mar 12, 2012 at 10:07:48PM +0200, Samuli Suominen wrote:
> ssmtp has been quiet project for quite a while, where as msmtp is 
> maintained one.
> 
> sure, ssmtp might be just mature, but msmtp is equally small and has 
> more features.
> 
> any thoughts?
+1 to getting rid of ssmtp. But I'm not sure that msmtp is the best
replacement.

One of the greatest things that bugs me about ssmtp is that if the
mailserver is not available, it hangs for a while, and then it loses the
email. 

Where I need a simple mail relay, I've gone with nullmailer instead,
because it supports the features, and it explicitly has a lightweight
daemon mode that queues mail to send.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

[gentoo-dev] RFC: Change mail-mta/msmtp to be the default in virtual/mta instead of mail-mta/ssmtp ?

[Samuli Suominen]

ssmtp has been quiet project for quite a while, where as msmtp is 
maintained one.


sure, ssmtp might be just mature, but msmtp is equally small and has 
more features.


any thoughts?

- Samuli

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

On Mon, 12 Mar 2012 20:49:22 +0100
Ulrich Mueller  wrote:
> > That's already not the way things work, since different version
> > strings can be equal versions (and it's illegal to do this),
> > so it's not relevant to the discussion.
> 
> This is a design flaw in our versioning system, and it can only occur
> in some corner cases where version components have leading zeros.

You know, if we had GLEP 55, we could fix that. Although it's debatable
whether it's a flaw, since we're trying to match upstream version
formats where reasonably possible.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:

> On Mon, 12 Mar 2012 14:58:01 -0400
> Ian Stakenvicius  wrote:
>> If the answer to this is no, that there should always be only one
>> ebuild per package version

Right.

> That's already not the way things work, since different version
> strings can be equal versions (and it's illegal to do this),
> so it's not relevant to the discussion.

This is a design flaw in our versioning system, and it can only occur
in some corner cases where version components have leading zeros. It
would be much better if any two different version strings had a unique
order relation (as for example it is the case with strverscmp(3)).

But that's not an excuse for adding another such flaw to our naming
scheme.

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

On Mon, 12 Mar 2012 20:38:21 +0100
Ulrich Mueller  wrote:
> The performance argument is in GLEP 55 itself:
> 
> | Easily fetchable EAPI inside the ebuild
> |
> | Properties:
> |Can be used right away: no
> |Hurts performance: yes

Sure. And it's a benefit, if your package mangler is carefully
designed to avoid doing unnecessary I/O. It's just not the primary
point. The primary point is that it handles whatever we feel like doing
in the future, even the "conveniently ignoring" stuff that you're
conveniently ignoring.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Robin H. Johnson]

On Mon, Mar 12, 2012 at 03:09:39PM +0100, Marc Schiffbauer wrote:
> > The quickest initramfs, assuming that ALL kernel modules you need to
> > boot are already compiled into your kernel:
> > genkernel --install --no-ramdisk-modules initramfs
> But this will not mount /usr. At least it did not for me.
Ouch, nice catch.

I missed merging my commit to flip the default of mounting /usr when
that file is missing. I fixed that in 3.4.25.1 now.

3.4.25-r1 also installed /etc/initramfs.mounts by default, that's where
the documentation is.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:

> Ulrich Mueller  wrote:
>> The "header comment" solution solves all these issues too, without
>> embedding unrelated information in the filename [1].

>> It can be implemented immediately, too.

> No it can't, since existing package managers don't handle it.

It can be easily implemented in a way that existing package managers
would mask the ebuild by unrecognised EAPI. At least if we stay with
bash, and nobody expects that we switch to any other format within the
next few years.

>> The argument that was always used against such solutions was that
>> it would "hurt performance". However, when the council asked for
>> benchmarks that would prove that point, nobody could provide them.

> No, the argument was that such solutions didn't solve the full
> problem. Performance issues were secondary, and were picked up upon
> as a way of avoiding the whole "nothing else solves all the
> problems" thing.

The performance argument is in GLEP 55 itself:

| Easily fetchable EAPI inside the ebuild
|
| Properties:
|Can be used right away: no
|Hurts performance: yes

Ulrich

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Robin H. Johnson]

On Mon, Mar 12, 2012 at 06:01:21PM +0100, Matthias Hanft wrote:
> Rich Freeman wrote:
> >
> > I think that makes the most sense.  That news item can include links
> > to the documentation that gets written over the next few months.
> 
> In the German (not Gentoo-specific) newsgroup de.comp.os.unix.linux.misc,
> someone mentioned that he upgraded to udev-180 and lost the device nodes
> for the hard disk (or something like that) because CONFIG_DEVTMPFS was
> not set in his kernel configuration.  He says udev>=180 needs DEVTMPFS
> set.  Is there any issue with Gentoo's udev-181 and CONFIG_DEVTMPFS?
We already issue a warning if you do not have CONFIG_DEVTMPFS.

It is required.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Rich Freeman]

On Mon, Mar 12, 2012 at 1:46 PM, Zac Medico  wrote:
> If we want to handle every possible screwup, including stray EAPI
> assignments inside inherited eclasses, we still need to compare the
> probed value to the value that's obtained from bash.

Well, I wasn't intending to suggest that the repoman check need be the
only one.  However, preventing problems is at least as useful as
detecting them.

That said, it would probably best to have exactly one way to determine
the official EAPI.  If that is to parse the filename, then parse the
filename.  If it is to grep for a regexp and expect exactly one hit
and parse it in a certain way, then do that.

It might be that the "one" official way is to grep for a regexp and if
you find it, use it, otherwise assume 0, 1, 2, 3, or 4 and source the
ebuild for it.  That still gives you only a single answer (well,
except in situations where the current way is already broken).

If people want to abuse the EAPI syntax I suppose we can generate an
error, but ignoring it might be just as valid behavior.  I'm not sure
what happens if you define PN/etc in ebuild besides things breaking in
a horrible manner.  I'd put changing EAPI in the same category.

Rich

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/jbigkit: jbigkit-2.0-r1.ebuild ChangeLog

[Samuli Suominen]

I thought we had this discussion already. USE=static-libs is for 
controlling the build of static libraries, not the install alone.


Changed it the way it was.

On 03/12/2012 07:57 PM, Tomas Chvatal (scarabeus) wrote:

scarabeus12/03/12 17:57:41

   Modified: jbigkit-2.0-r1.ebuild ChangeLog
   Log:
   Deploy static libs only if wanted.

   (Portage version: 2.2.0_alpha90/cvs/Linux x86_64)

Revision  ChangesPath
1.11 media-libs/jbigkit/jbigkit-2.0-r1.ebuild

file : 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild?rev=1.11&view=markup
plain: 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild?rev=1.11&content-type=text/plain
diff : 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild?r1=1.10&r2=1.11

Index: jbigkit-2.0-r1.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- jbigkit-2.0-r1.ebuild   5 Sep 2010 13:16:55 -   1.10
+++ jbigkit-2.0-r1.ebuild   12 Mar 2012 17:57:41 -  1.11
@@ -1,8 +1,8 @@
-# Copyright 1999-2010 Gentoo Foundation
+# Copyright 1999-2012 Gentoo Foundation
  # Distributed under the terms of the GNU General Public License v2
-# $Header: /var/cvsroot/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild,v 
1.10 2010/09/05 13:16:55 armin76 Exp $
+# $Header: /var/cvsroot/gentoo-x86/media-libs/jbigkit/jbigkit-2.0-r1.ebuild,v 
1.11 2012/03/12 17:57:41 scarabeus Exp $

-EAPI="3"
+EAPI=4

  inherit eutils multilib toolchain-funcs

@@ -13,7 +13,7 @@
  LICENSE="GPL-2"
  SLOT="0"
  KEYWORDS="alpha amd64 arm hppa ia64 m68k ~mips ppc ppc64 s390 sh sparc x86 
~sparc-fbsd ~x86-fbsd ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~sparc-solaris 
~x64-solaris ~x86-solaris"
-IUSE=""
+IUSE="static-libs"

  S=${WORKDIR}/${PN}

@@ -23,20 +23,21 @@

  src_compile() {
tc-export AR CC RANLIB
-   emake LIBDIR="${EPREFIX}/usr/$(get_libdir)" || die
+   emake LIBDIR="${EPREFIX}/usr/$(get_libdir)"
  }

  src_test() {
-   LD_LIBRARY_PATH=${S}/libjbig make -j1 test || die
+   LD_LIBRARY_PATH=${S}/libjbig make -j1 test
  }

  src_install() {
-   dobin pbmtools/jbgtopbm{,85} pbmtools/pbmtojbg{,85} || die
+   dobin pbmtools/jbgtopbm{,85} pbmtools/pbmtojbg{,85}
doman pbmtools/jbgtopbm.1 pbmtools/pbmtojbg.1

insinto /usr/include
-   doins libjbig/*.h || die
-   dolib libjbig/libjbig{,85}{.a,$(get_libname)} || die
+   doins libjbig/*.h
+   dolib libjbig/libjbig{,85}$(get_libname)
+   use static-libs&&  dolib libjbig/libjbig{,85}.a

dodoc ANNOUNCE CHANGES TODO libjbig/*.txt
  }



1.51 media-libs/jbigkit/ChangeLog

file : 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/ChangeLog?rev=1.51&view=markup
plain: 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/ChangeLog?rev=1.51&content-type=text/plain
diff : 
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/jbigkit/ChangeLog?r1=1.50&r2=1.51

Index: ChangeLog
===
RCS file: /var/cvsroot/gentoo-x86/media-libs/jbigkit/ChangeLog,v
retrieving revision 1.50
retrieving revision 1.51
diff -u -r1.50 -r1.51
--- ChangeLog   9 Oct 2011 11:59:40 -   1.50
+++ ChangeLog   12 Mar 2012 17:57:41 -  1.51
@@ -1,6 +1,9 @@
  # ChangeLog for media-libs/jbigkit
-# Copyright 1999-2011 Gentoo Foundation; Distributed under the GPL v2
-# $Header: /var/cvsroot/gentoo-x86/media-libs/jbigkit/ChangeLog,v 1.50 
2011/10/09 11:59:40 ssuominen Exp $
+# Copyright 1999-2012 Gentoo Foundation; Distributed under the GPL v2
+# $Header: /var/cvsroot/gentoo-x86/media-libs/jbigkit/ChangeLog,v 1.51 
2012/03/12 17:57:41 scarabeus Exp $
+
+  12 Mar 2012; Tomáš Chvátal  jbigkit-2.0-r1.ebuild:
+  Deploy static libs only if wanted.

09 Oct 2011; Samuli Suominen  -jbigkit-1.6-r1.ebuild,
-files/jbigkit-1.6-build.patch, -files/jbigkit-1.6-respect-make.patch,

Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies

[Samuli Suominen]

On 03/12/2012 07:59 PM, Francisco Blas Izquierdo Riera (klondike) wrote:

El 12/03/12 17:29, Samuli Suominen escribió:

# Samuli Suominen  (12 Mar 2012)
# media-sound/lilypond required for this is masked in ../package.mask
# for removal
app-text/asciidoc test


asciidoc only depends with the test use flag set so why don't just
remove the test USE and the test function from the ebuilds instead?
If somebody is willing to proxy the changes for me I can patch the tree
with this fix.



I know.

If you look more closely, this is from package.use.mask, not package.mask.

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 12 Mar 2012 14:58:01 -0400
Ian Stakenvicius  wrote:
> If the answer to this is no, that there should always be only one
> ebuild per package version

That's already not the way things work, since different version
strings can be equal versions (and it's illegal to do this), so it's
not relevant to the discussion.

- -- 
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk9eSAwACgkQ96zL6DUtXhGpEwCfWS9u6S4oqNebnRrofwqWKFAy
tGMAoNX/2T7dyBqW+sSVO+O5nSMp5NKm
=Y5Tt
-END PGP SIGNATURE-

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

On Mon, 12 Mar 2012 19:50:36 +0100
Ulrich Mueller  wrote:
> > On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> > GLEP 55 is simple, it solves all the problems we have (including the
> > version issue, which everyone is conveniently ignoring), it doesn't
> > require us to guess what's going to happen next and it can be
> > implemented immediately. That's a rather big deal.
> 
> The "header comment" solution solves all these issues too, without
> embedding unrelated information in the filename [1].

No it doesn't. See the "conveniently ignoring" part you're conveniently
ignoring.

> It can be implemented immediately, too.

No it can't, since existing package managers don't handle it.

> The argument that was always used against such solutions was that
> it would "hurt performance". However, when the council asked for
> benchmarks that would prove that point, nobody could provide them.

No, the argument was that such solutions didn't solve the full problem.
Performance issues were secondary, and were picked up upon as a way of
avoiding the whole "nothing else solves all the problems" thing.

> [1]  "The filename is metadata
> about a file; a string used to uniquely identify a file stored on the
> file system."

By that argument, there's no point in having a ".ebuild" there either.
Please don't continue the bad trend of posting irrelevant Wikipedia
links as footnotes as though the primary issue should be anything other
than a comparison of solutions to a technical problem [1].

[1] http://en.wikipedia.org/wiki/Spork

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/03/12 02:50 PM, Ulrich Mueller wrote:
>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
>> GLEP 55 is simple, it solves all the problems we have (including
>> the version issue, which everyone is conveniently ignoring), it
>> doesn't require us to guess what's going to happen next and it
>> can be implemented immediately. That's a rather big deal.
> 
> The "header comment" solution solves all these issues too, without 
> embedding unrelated information in the filename [1]. It can be 
> implemented immediately, too.
> 
> The argument that was always used against such solutions was that 
> it would "hurt performance". However, when the council asked for 
> benchmarks that would prove that point, nobody could provide them.
> 
> Ulrich


Regarding the filename issue, and the potential in the future for
ebuilds that get parsed with other parsers:

Is there any particular reason why we would want multiple ebuilds for
a package to exist for the same version, but supporting different
EAPIs (ad therefore different parsers)?

If the answer to this is no, that there should always be only one
ebuild per package version, then chances are good that we should keep
the eapi (or other identifier) out of the file name.  However, if the
answer is yes, then the filename method is probably the cleanest way
to do this.

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

iF4EAREIAAYFAk9eRzkACgkQAJxUfCtlWe18WwD5AeXETH+J4X8d8P7TX76FPGPS
0vS2rrRZktpLp70TkcQA/0Cl2/OdSlfwi0CqC8IBJffsY3epXkqxhzPL8bwsNAoj
=Q5aK
-END PGP SIGNATURE-

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
> GLEP 55 is simple, it solves all the problems we have (including the
> version issue, which everyone is conveniently ignoring), it doesn't
> require us to guess what's going to happen next and it can be
> implemented immediately. That's a rather big deal.

The "header comment" solution solves all these issues too, without
embedding unrelated information in the filename [1]. It can be
implemented immediately, too.

The argument that was always used against such solutions was that
it would "hurt performance". However, when the council asked for
benchmarks that would prove that point, nobody could provide them.

Ulrich

[1]  "The filename is metadata
about a file; a string used to uniquely identify a file stored on the
file system."

Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies

[Tim Harder]

On 2012-03-12 Mon 10:54, Nathan Phillip Brink wrote:
> > > # Samuli Suominen  (12 Mar 2012)
> > > # Severely broken wrt bugs #179178, #331181, #334835, #350059,
> > > # #372839, #380155, #380627, #381055, #383515, #383553, #384687,
> > > # and #403399. Search bugzilla with keyword lilypond. Nothing
> > > # left in tree that builds. Removal in 30 days.
> > >  > > media-sound/denemo
> > > media-sound/frescobaldi
> > >
> > > # Samuli Suominen  (12 Mar 2012)
> > > # media-sound/lilypond required for this is masked in ../package.mask
> > > # for removal
> > > app-text/asciidoc test
> > >
> > Just curious, but is there no one interested in this, lilypond,
> > package anymore? The latest stable is 2.14.2 and the project is pretty
> > active. Seems like a shame to get rid of it entirely.

> I myself am quite interested in lilypond. I only use it occasionally
> and am still a novice at it, but I like the typesetting it does.

> Maybe next week I can find time to attack some of these bugs and
> rescue it, unless if someone more qualified or with more time is
> interested...

For those not following #gentoo-dev, I already said I'd take over
maintainership since I've been using it an overlay for years.

Anyone is free to help close bugs and co-maintain it if they wish.

Tim


pgpnJL6RZXo86.pgp
Description: PGP signature

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Sven Vermeulen]

On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote:
> We should really have some documentation on how to create a minimal initramfs
> that mounts /usr (if we don't already, I haven't looked).  I've never needed
> one until now and don't have the foggiest idea how it's done.  I can't be the
> only one.

I just started the tracker [1] for the documentation changes and sent info
to gentoo-doc mailinglist about it. The upcoming days, I'll have the needed
updates trickle into the documents.

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

> Also, the handbook still endorses having a separate partition for /usr and
> includes it in the example setup.  This should be changed now, not when
> stabilization time comes.  

It's an example, and we still endorse it. Only will we now tell users to use
an initramfs with it.

Wkr,
Sven Vermeulen

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 07:17, Ulrich Mueller  wrote:
>
> Note the smiley in my posting. And yes, it _is_ ugly.
>

It may be ugly, but I'll take ugly over "doesn't work" and "serious
technical limitations" any day ;)

Binary executables are "ugly", you don't see many people complaining ;)


-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

On Mon, 12 Mar 2012 19:17:31 +0100
Ulrich Mueller  wrote:
> > The person who wrote it is one of Satan's little minions. Also,
> > change is bad.
> 
> And you think that this is better?

Those *are* the arguments against GLEP 55 that we've had so far. You're
adding in "someone already said no" (and the people who said that were
discussing nonsense like using xattrs in its place, which should
immediately invalidate anything they said on the matter) and "it looks
ugly, but not just because I don't like the people who proposed it,
honest" to that. The only reason this discussion is going on is because
some people still think it's in their advantage politically to say no to
anything seen as coming from "the wrong people".

GLEP 55 is simple, it solves all the problems we have (including the
version issue, which everyone is conveniently ignoring), it doesn't
require us to guess what's going to happen next and it can be
implemented immediately. That's a rather big deal.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:

> On Mon, 12 Mar 2012 19:00:32 +0100
> Ulrich Mueller  wrote:
>> > On Mon, 12 Mar 2012, Zac Medico wrote:
>> > If we do go with a variant of GLEP 55, I'd prefer a variant that
>> > uses a constant extension (like .eb) and places the EAPI string
>> > just after the version component of the name. For example:
>> 
>> >foo-1.0-r1-eapi5.ebuild
>> 
>> This is so ugly... I guess I'll retire the same day when such an
>> abomination gets accepted. ;-)

> I'm sorry, we're down to "it's ugly and someone already said no and
> I'll throw my toys out of the pram if I don't get my way" as the
> arguments against GLEP 55 now?

Note the smiley in my posting. And yes, it _is_ ugly.

> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:

> The person who wrote it is one of Satan's little minions. Also,
> change is bad.

And you think that this is better?

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

On Mon, 12 Mar 2012 19:00:32 +0100
Ulrich Mueller  wrote:
> > On Mon, 12 Mar 2012, Zac Medico wrote:
> > If we do go with a variant of GLEP 55, I'd prefer a variant that
> > uses a constant extension (like .eb) and places the EAPI string
> > just after the version component of the name. For example:
> 
> >foo-1.0-r1-eapi5.ebuild
> 
> This is so ugly... I guess I'll retire the same day when such an
> abomination gets accepted. ;-)
> 
> (Still better than the original variant of GLEP 55 though.)

I'm sorry, we're down to "it's ugly and someone already said no and I'll
throw my toys out of the pram if I don't get my way" as the arguments
against GLEP 55 now?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 13 March 2012 06:53, Ulrich Mueller  wrote:
>
> There are very good reasons not to embed this information in the
> filename. That it makes the filename harder to parse for the human eye
> and more difficult to type is one of them.
>
> Besides, we already have a council decision about that GLEP.

Difficulty in typing them is not really much of an argument,
considering the present complexity with file-names already having
versions encoded in them.

And difficulty reading them isn't much of an argument really either.

But difficulty identifying the format systematically seems a
reasonable enough objection, and for this, I can see the translation
of

abz-123.ebuild-5  to  ->  abz-123.eapi5.eb

Being a more practical change ( or something of that nature ).

At least that way, its easier to have a way to find "all ebuilds"
without needing extension permutation.

Another thought: Presently we have versions encoded in the file name.
If we ever decide we need to change our versioning syntax or
versioning semantics, we might be up the creek without a paddle, and
EAPI being *in* the file will probably make that harder, and I'd
probably prefer some sort of out-of-band location for EAPI in that
situation too.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD : .ebuild is only bash

[Michał Górny]

On Tue, 13 Mar 2012 04:57:04 +1300
Kent Fredric  wrote:

> On 12 March 2012 22:37, Brian Harring  wrote:
> > Ebuilds *are* bash.  There isn't ever going to be a PMS labeled
> > xml format that is known as ebuilds... that's just pragmatic reality
> > since such a beast is clearly a seperate format (thus trying to call
> > it an 'ebuild' is dumb, confusing, and counter productive).
> 
> 
> I think this notion should be concluded before we continue debating as
> to how best to implement EAPI declarations.
> 
> Is it really so fixed that ".ebuild" will only ever be bash ?
> 
> If thats the case, then G55 ( or something similar ) is practically
> guaranteed as soon as we want something non-bash.

Maybe instead of per-EAPI suffix change, we'd want to prepend the
suffix with something special whenever the actual format changes.

In other words, if EAPI 15 introduces XML-based syntax, we start
using .xml.ebuild. If EAPI 7 introduces bash4 in global scope (still
don't see much reason for it), we use .bash4.ebuild.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

> On Mon, 12 Mar 2012, Zac Medico wrote:

> If we do go with a variant of GLEP 55, I'd prefer a variant that uses a
> constant extension (like .eb) and places the EAPI string just after the
> version component of the name. For example:

>foo-1.0-r1-eapi5.ebuild

This is so ugly... I guess I'll retire the same day when such an
abomination gets accepted. ;-)

(Still better than the original variant of GLEP 55 though.)

Ulrich

Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies

[Francisco Blas Izquierdo Riera (klondike)]

El 12/03/12 17:29, Samuli Suominen escribió:
> # Samuli Suominen  (12 Mar 2012)
> # media-sound/lilypond required for this is masked in ../package.mask
> # for removal
> app-text/asciidoc test
>
asciidoc only depends with the test use flag set so why don't just
remove the test USE and the test function from the ebuilds instead?
If somebody is willing to proxy the changes for me I can patch the tree
with this fix.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Michał Górny]

On Mon, 12 Mar 2012 10:22:57 -0700
Zac Medico  wrote:

> On 03/12/2012 10:12 AM, Ciaran McCreesh wrote:
> > On Mon, 12 Mar 2012 18:05:46 +0100
> > Ulrich Mueller  wrote:
> >> See above, even if we should ever move away from bash, GLEP 55 is
> >> still not needed.
> > 
> > ...but we might as well go with GLEP 55 anyway, since GLEP 55
> > definitely works, whereas other solutions might work so long as we
> > don't do something unexpected.
> > 
> > This whole thing is just an exercise in trying to find excuses not
> > to use GLEP 55.
> 
> If we do go with a variant of GLEP 55, I'd prefer a variant that uses
> a constant extension (like .eb) and places the EAPI string just after
> the version component of the name. For example:
> 
>foo-1.0-r1-eapi5.ebuild

Or .eapi5.ebuild, to make it more of a suffix and less of PV part.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies

[Nathan Phillip Brink]

On Mon, Mar 12, 2012 at 12:29:47PM -0500, Matthew Summers wrote:
> On Mon, Mar 12, 2012 at 11:29 AM, Samuli Suominen  
> wrote:
> > # Samuli Suominen  (12 Mar 2012)
> > # Severely broken wrt bugs #179178, #331181, #334835, #350059,
> > # #372839, #380155, #380627, #381055, #383515, #383553, #384687,
> > # and #403399. Search bugzilla with keyword lilypond. Nothing
> > # left in tree that builds. Removal in 30 days.
> >  > media-sound/denemo
> > media-sound/frescobaldi
> >
> > # Samuli Suominen  (12 Mar 2012)
> > # media-sound/lilypond required for this is masked in ../package.mask
> > # for removal
> > app-text/asciidoc test
> >
> 
> Just curious, but is there no one interested in this, lilypond,
> package anymore? The latest stable is 2.14.2 and the project is pretty
> active. Seems like a shame to get rid of it entirely.

I myself am quite interested in lilypond. I only use it occasionally
and am still a novice at it, but I like the typesetting it does.

Maybe next week I can find time to attack some of these bugs and
rescue it, unless if someone more qualified or with more time is
interested...

-- 
binki

Look out for missing or extraneous apostrophes!


pgpikFikeaWP7.pgp
Description: PGP signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:

> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller  wrote:
>> See above, even if we should ever move away from bash, GLEP 55 is
>> still not needed.

> ...but we might as well go with GLEP 55 anyway, since GLEP 55
> definitely works, whereas other solutions might work so long as we
> don't do something unexpected.

> This whole thing is just an exercise in trying to find excuses not
> to use GLEP 55.

There are very good reasons not to embed this information in the
filename. That it makes the filename harder to parse for the human eye
and more difficult to type is one of them.

Besides, we already have a council decision about that GLEP.

Ulrich

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

On 03/12/2012 10:30 AM, Rich Freeman wrote:
> On Mon, Mar 12, 2012 at 1:01 PM, Zac Medico  wrote:
>> It would be very fragile without the sanity check / feedback mechanism
>> that's already been suggested.
> 
> Another obvious check is to have repoman run a grep with the regexp
> and give an error if there is not exactly one match.

If we want to handle every possible screwup, including stray EAPI
assignments inside inherited eclasses, we still need to compare the
probed value to the value that's obtained from bash.

I guess you're hinting at using a non-bash ebuild format? Even if in
that case, the the package manager should simply use whatever
interpreter is appropriate for the probed EAPI. So, if EAPI 7 is a
posix-shell format, and the probed EAPI is 7, then the package manager
should source the ebuild with it's posix-shell instead of bash. If the
probed EAPI is not a supported EAPI, then it should skip the sourcing
entirely, and report the ebuild as having an unsupported EAPI.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFD : .ebuild is only bash

[Zac Medico]

On 03/12/2012 10:17 AM, Michael Orlitzky wrote:
> On 03/12/12 13:12, Ciaran McCreesh wrote:
>> On Mon, 12 Mar 2012 18:05:46 +0100
>> Ulrich Mueller  wrote:
>>> See above, even if we should ever move away from bash, GLEP 55 is
>>> still not needed.
>>
>> ...but we might as well go with GLEP 55 anyway, since GLEP 55
>> definitely works, whereas other solutions might work so long as we
>> don't do something unexpected.
>>
>> This whole thing is just an exercise in trying to find excuses not to
>> use GLEP 55.
>>
> 
> Not understanding any of the politics involved, what are the technical
> arguments against it?

I think the bulk of resistance has been due to its use of an infinite
series of extensions, like .ebuild-5, .ebuild-6 and so on. GLEP 55
itself has since been amended to include a "one time extension change"
option [1].

[1]
http://www.gentoo.org/proj/en/glep/glep-0055.html#eapi-in-the-filename-with-one-time-extension-change
-- 
Thanks,
Zac

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Rich Freeman]

On Mon, Mar 12, 2012 at 1:01 PM, Zac Medico  wrote:
> It would be very fragile without the sanity check / feedback mechanism
> that's already been suggested.

Another obvious check is to have repoman run a grep with the regexp
and give an error if there is not exactly one match.

Rich

Re: [gentoo-dev] Lastrite: lilypond and reverse dependencies

[Matthew Summers]

On Mon, Mar 12, 2012 at 11:29 AM, Samuli Suominen  wrote:
> # Samuli Suominen  (12 Mar 2012)
> # Severely broken wrt bugs #179178, #331181, #334835, #350059,
> # #372839, #380155, #380627, #381055, #383515, #383553, #384687,
> # and #403399. Search bugzilla with keyword lilypond. Nothing
> # left in tree that builds. Removal in 30 days.
>  media-sound/denemo
> media-sound/frescobaldi
>
> # Samuli Suominen  (12 Mar 2012)
> # media-sound/lilypond required for this is masked in ../package.mask
> # for removal
> app-text/asciidoc test
>

Just curious, but is there no one interested in this, lilypond,
package anymore? The latest stable is 2.14.2 and the project is pretty
active. Seems like a shame to get rid of it entirely.

-- 
Matthew W. Summers
Gentoo Foundation Inc.

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

On Mon, 12 Mar 2012 13:17:15 -0400
Michael Orlitzky  wrote:
> > This whole thing is just an exercise in trying to find excuses not
> > to use GLEP 55.
> > 
> 
> Not understanding any of the politics involved, what are the technical
> arguments against it?

The person who wrote it is one of Satan's little minions. Also, change
is bad.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Zac Medico]

On 03/12/2012 10:12 AM, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller  wrote:
>> See above, even if we should ever move away from bash, GLEP 55 is
>> still not needed.
> 
> ...but we might as well go with GLEP 55 anyway, since GLEP 55
> definitely works, whereas other solutions might work so long as we
> don't do something unexpected.
> 
> This whole thing is just an exercise in trying to find excuses not to
> use GLEP 55.

If we do go with a variant of GLEP 55, I'd prefer a variant that uses a
constant extension (like .eb) and places the EAPI string just after the
version component of the name. For example:

   foo-1.0-r1-eapi5.ebuild
-- 
Thanks,
Zac

Re: [gentoo-dev] RFD : .ebuild is only bash

[Michael Orlitzky]

On 03/12/12 13:12, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 18:05:46 +0100
> Ulrich Mueller  wrote:
>> See above, even if we should ever move away from bash, GLEP 55 is
>> still not needed.
> 
> ...but we might as well go with GLEP 55 anyway, since GLEP 55
> definitely works, whereas other solutions might work so long as we
> don't do something unexpected.
> 
> This whole thing is just an exercise in trying to find excuses not to
> use GLEP 55.
> 

Not understanding any of the politics involved, what are the technical
arguments against it?

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

On Mon, 12 Mar 2012 18:05:46 +0100
Ulrich Mueller  wrote:
> See above, even if we should ever move away from bash, GLEP 55 is
> still not needed.

...but we might as well go with GLEP 55 anyway, since GLEP 55
definitely works, whereas other solutions might work so long as we
don't do something unexpected.

This whole thing is just an exercise in trying to find excuses not to
use GLEP 55.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

> On Mon, 12 Mar 2012, Rich Freeman wrote:

> Well, we do always have the option of keeping the EAPI= syntax but
> making it more strict per the proposals, and then grepping it out
> rather than sourcing the ebuild. That seems likely to always work
> with bash. Then if we ever switched to some other format we'd have
> to reconsider whether we want to tweak this approach further or
> adopt GLEP 55.

As long as we stay with some textual format for ebuilds, the "header
comment" approach will always work, if its syntax is general enough.
(For example, requiring # as comment introducer would be stupid.)

And I don't expect that we will move away from bash within the next
two or three years, so there won't be any upgrade problems for systems
with old package managers.

> If you envision a future where big changes are inevitable over the
> long term, then just going with GLEP 55 is probably the cleanest
> solution. If you envision a future where we are likely to never move
> away from bash, or if we do it is so far off that we're content to
> let our children deal with it, then other approaches may seem nicer.

> I guess the question is whether we need to future-proof against a
> future that may never come. Then again, as we're seeing from systemd
> a lot of stuff that "always" was done in bash doesn't necessarily
> have to stay that way.

See above, even if we should ever move away from bash, GLEP 55 is
still not needed.

Ulrich

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

On 03/12/2012 02:16 AM, Kent Fredric wrote:
> I just find a top-down regexp solution dangerously naive, as its
> infering that the first line that matches the regexp *is* the EAPI
> requirement field, when depending on the actual format used, that may
> not be the case.
> 
> If for example, a format is machine generated, and the EAPI
> declaration accidentally comes after something that *isnt* an EAPI
> declaration but by the regexp, LOOKS like one,   then the probing
> mechanism will resolve the WRONG value.
> 
> And that doesn't strike me as being very resilient.

It would be very fragile without the sanity check / feedback mechanism
that's already been suggested [1]. The idea is to compare the probed
EAPI with the result that's obtained from bash, and treat the ebuild as
invalid if they are not identical. This would allow ebuilds that don't
fit our EAPI probing mechanism to be immediately detected so that the
ebuild developer could fix them. In practice, this will not be much of
an issue, since the EAPI assignment will be required to be very close to
the top of the file, and the package manager will stop searching as soon
as it finds the first match.

[1] https://bugs.gentoo.org/show_bug.cgi?id=402167#c18
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Matthias Hanft]

Rich Freeman wrote:


I think that makes the most sense.  That news item can include links
to the documentation that gets written over the next few months.


In the German (not Gentoo-specific) newsgroup de.comp.os.unix.linux.misc,
someone mentioned that he upgraded to udev-180 and lost the device nodes
for the hard disk (or something like that) because CONFIG_DEVTMPFS was
not set in his kernel configuration.  He says udev>=180 needs DEVTMPFS
set.  Is there any issue with Gentoo's udev-181 and CONFIG_DEVTMPFS?
If so, you should include it in the documentation.

-Matt

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ulrich Mueller]

> On Tue, 13 Mar 2012, Kent Fredric wrote:

> Is it really so fixed that ".ebuild" will only ever be bash ?

Certainly it would make sense to change the file extension when an
EAPI will require something different than bash. For example, some
editors (Emacs and XEmacs at least) recognise the .ebuild extension
and use corresponding syntax rules.

> If thats the case, then G55 ( or something similar ) is practically
> guaranteed as soon as we want something non-bash.

No, you just use a new extension once and you're done. And I guess
such drastic changes won't happen frequently. In the past 12 years
there hasn't been a single one. (If they will ever happen, this is a
pretty academic discussion.)

Ulrich

Re: [gentoo-dev] RFD : .ebuild is only bash

[Rich Freeman]

On Mon, Mar 12, 2012 at 11:59 AM, Ciaran McCreesh
 wrote:
> On Tue, 13 Mar 2012 04:57:04 +1300
> Kent Fredric  wrote:
>> I think this notion should be concluded before we continue debating as
>> to how best to implement EAPI declarations.
>>
>> Is it really so fixed that ".ebuild" will only ever be bash ?
>
> What version of bash are we talking about here? It's not the case that
> ebuilds will always be bash 3, which is enough to make GLEP 55 the safe
> option.

Well, we do always have the option of keeping the EAPI= syntax but
making it more strict per the proposals, and then grepping it out
rather than sourcing the ebuild.  That seems likely to always work
with bash.  Then if we ever switched to some other format we'd have to
reconsider whether we want to tweak this approach further or adopt
GLEP 55.

If you envision a future where big changes are inevitable over the
long term, then just going with GLEP 55 is probably the cleanest
solution.  If you envision a future where we are likely to never move
away from bash, or if we do it is so far off that we're content to let
our children deal with it, then other approaches may seem nicer.

I guess the question is whether we need to future-proof against a
future that may never come.  Then again, as we're seeing from systemd
a lot of stuff that "always" was done in bash doesn't necessarily have
to stay that way.

Rich

[gentoo-dev] Lastrite: lilypond and reverse dependencies

[Samuli Suominen]

# Samuli Suominen  (12 Mar 2012)
# Severely broken wrt bugs #179178, #331181, #334835, #350059,
# #372839, #380155, #380627, #381055, #383515, #383553, #384687,
# and #403399. Search bugzilla with keyword lilypond. Nothing
# left in tree that builds. Removal in 30 days.
 (12 Mar 2012)
# media-sound/lilypond required for this is masked in ../package.mask
# for removal
app-text/asciidoc test

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

On 03/12/2012 09:12 AM, Ciaran McCreesh wrote:
> On Mon, 12 Mar 2012 09:05:26 -0700
> Zac Medico  wrote:
>> It's just a symptom of people not abiding by the KISS principle.
> 
> "Abiding by the KISS principle" is what got us into this mess in the
> first place. EAPI as a metadata variable is too simple to allow us to
> do what we want to do.

If our goal is to obtain the EAPI before the ebuild is sourced, then
GLEP 55 is more in alignment with the KISS principle. The "EAPI as
metadata variable" approach simply wasn't designed with our current goal
in mind.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

On Mon, 12 Mar 2012 09:05:26 -0700
Zac Medico  wrote:
> It's just a symptom of people not abiding by the KISS principle.

"Abiding by the KISS principle" is what got us into this mess in the
first place. EAPI as a metadata variable is too simple to allow us to
do what we want to do.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Zac Medico]

On 03/12/2012 01:36 AM, Brian Harring wrote:
> On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote:
>> 1) User downloads an overlay that doesn't provide cache. We want the
>> package manager to give a pretty "EAPI unsupported" message, rather than
>> spit out some bash syntax errors.
> 
> This criticsm pretty much applies *strictly to the existing 
> implementation*.  It's disenguous busting it in this fashion.
> 
> EAPI as a function explicitly gives it an out before hitting any of 
> that, eliminating your entire critique.  Same goes for parsing it out 
> of the ebuild, or renaming the extension.

You're assuming that the ebuild calls your eapi() function before it
uses any syntax that's unsupported by the user's installed version of bash.

> 1) PM still doesn't support that EAPI, looks at the cache/ebuild: 
> checksums are the same, thus the stored EAPI is trustable, leading to 
> the PM knowing it still can't process that ebuild and masking it 
> appropriately.

You're assuming that cache is provided by the repo, which is not
guaranteed, depending on the source. Even if the cache does exist, then
you're assuming it's in a format that the package manager can reliably
parse the EAPI from, even though that EAPI may not be supported. That
may or may not reliable assumption, and having a pre-defined protocol to
directly obtain the EAPI without using the cache is much more reliable.

> What I'd like to see, is accuracy in this discussion.  Skip the 
> handwavey "complexity! complexity! complexity!" crap, same for 
> selective robustness definitions.  Past attempts at this discussion 
> mostly failed due to people pulling crap like this and frankly it just 
> pisses people off. 

It's just a symptom of people not abiding by the KISS principle. When
you start talking about an approach such as the "eapi() function"
approach which introduces lots of unnecessary complexity, it naturally
makes the whole discussion more complex and hand-wavey.
-- 
Thanks,
Zac

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ciaran McCreesh]

On Tue, 13 Mar 2012 04:57:04 +1300
Kent Fredric  wrote:
> I think this notion should be concluded before we continue debating as
> to how best to implement EAPI declarations.
> 
> Is it really so fixed that ".ebuild" will only ever be bash ?

What version of bash are we talking about here? It's not the case that
ebuilds will always be bash 3, which is enough to make GLEP 55 the safe
option.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

[gentoo-dev] RFD : .ebuild is only bash

[Kent Fredric]

On 12 March 2012 22:37, Brian Harring  wrote:
> Ebuilds *are* bash.  There isn't ever going to be a PMS labeled
> xml format that is known as ebuilds... that's just pragmatic reality
> since such a beast is clearly a seperate format (thus trying to call
> it an 'ebuild' is dumb, confusing, and counter productive).


I think this notion should be concluded before we continue debating as
to how best to implement EAPI declarations.

Is it really so fixed that ".ebuild" will only ever be bash ?

If thats the case, then G55 ( or something similar ) is practically
guaranteed as soon as we want something non-bash.




--
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

On Mon, 12 Mar 2012 01:36:12 -0700
Brian Harring  wrote:
> Also note that with the sole exception of g55
...
> and does so at the same robustness as everything sans g55
...
> G55 is the sole exception.

Interesting pattern, huh?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Rich Freeman]

On Mon, Mar 12, 2012 at 6:12 AM, Kent Fredric  wrote:
>
> There's the obvious case of compiled-binaries where that might not be
> possible, but thats definately strawman stuff and I wouldn't support
> that sort of nonsense anyway. Compiled binaries for ebuilds can gtfo.
>

Why do I feel like a similar debate must have happened on some list
back when the SMTP message terminator was worked out?  The problem is
that we're running into is the use of in-band control information.

An advantage of sticking the EAPI in the filename is that it is
completely out-of-band.  Other options like an external file or POSIX
attributes have the same advantage (with the disadvantage that they
are harder to keep in-sync or support in general).

If you want to stick the EAPI inside the file then we have to go with
one of two routes:

1.  Make the file directly interpret-able by some existing tool like
bash, xml parsers, or (gtfo) ld-linux.so.  This requires making the
EAPI in-band info, and thus if the file format changes there is risk
that any existing code that interprets EAPIs could break, to the
degree that we weren't infinitely clever in designing the spec.

2.  Make the file require pre-processing before being fed to another
interpreter.  This breaks syntax-highlighting and such, and is
generally more of a pita.  However, this allows in-file EAPI info to
remain out-of-band.  An ebuild might be an xml file with EAPI and
other meta-data, and might contain sections that get ripped out and
handed over to bash, python, or ld-linux.so to the extent that you
want to be told to gtfo.

In my thinking the option with the fewest drawbacks and the greatest
extent of future-proofing is to go with GLEP 55 and stick it in the
filename.  Every filesystem and rsync tool handles filenames, they're
impossible to separate from file contents, and every interpreter out
there ignores them.

If we don't want to stick it in the filename then either we have to
decide that whatever we come up with could break, or that we really
have to change what ebuilds look like.

Rich

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Marc Schiffbauer]

On Sunday 11 March 2012 21:08:47 Robin H. Johnson wrote:
> On Sun, Mar 11, 2012 at 12:49:11AM -0600, Ryan Hill wrote:
> > On Sat, 10 Mar 2012 20:27:06 -0600
> > 
> > William Hubbs  wrote:
> > > An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25
> > > or
> > > 
> > > >=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
> > > 
> > > sure any initramfs you create pre-mounts /usr.
> > 
> > We should really have some documentation on how to create a minimal
> > initramfs that mounts /usr (if we don't already, I haven't looked).  I've
> > never needed one until now and don't have the foggiest idea how it's
> > done.  I can't be the only one.
> 
> The quickest initramfs, assuming that ALL kernel modules you need to
> boot are already compiled into your kernel:
> genkernel --install --no-ramdisk-modules initramfs

But this will not mount /usr. At least it did not for me.
To make it work you have to 

# echo "/usr" >> /etc/initramfs.mounts

and recreate the ramdisk (genkernel ramdisk)

I had to look into the code for that as this seems not to be documented 
anywhere.

-Marc


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

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Rich Freeman]

On Sun, Mar 11, 2012 at 7:15 PM, William Hubbs  wrote:
>
> I was thinking of another news item once we are ready to go stable.
>
> What do you think?
>

I think that makes the most sense.  That news item can include links
to the documentation that gets written over the next few months.

Rich

[gentoo-dev] Lastrite: dev-ada/qtada

[Samuli Suominen]

12 Mar 2012; Samuli Suominen  package.mask:
Lastrite dev-ada/qtada as per request from yngwin.

# Samuli Suominen  (12 Mar 2012)
# Severely broken wrt bugs #227171, #286550 and #287483
# Removal in 30 days
dev-ada/qtada

Re: [gentoo-dev] RFC: virtual/shadow

[Fabian Groffen]

On 12-03-2012 11:35:43 +0100, "Paweł Hajdan, Jr." wrote:
> On 3/12/12 11:27 AM, Fabian Groffen wrote:
> > My rsync0 now spits out this message:
> > 
> >   Virtual package in package.provided: virtual/shadow-0
> >   See portage(5) for correct package.provided usage.
> > 
> > I did not forsee this happening, but each and every Prefix user now gets
> > this complaint on each and every emerge invocation.  It does not seem to
> > block any operation, but could we perhaps hold back further changes
> > until I can sort this out with Zac?
> 
> Ah, I read portage(5) now and adding a virtual to package.provided is
> indeed explicitly prohibited.
> 
> I removed it, but some further changes might be required for prefix
> (i.e. version number >= 4.1 in package.provided to satisfy the virtual),
> and I'll indeed hold back further changes in that area,
> and preferably just let you do any necessary fixes for prefix.

Thanks a lot for your swift actions!


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] RFC: virtual/shadow

[Paweł Hajdan, Jr.]

On 3/12/12 11:27 AM, Fabian Groffen wrote:
> My rsync0 now spits out this message:
> 
>   Virtual package in package.provided: virtual/shadow-0
>   See portage(5) for correct package.provided usage.
> 
> I did not forsee this happening, but each and every Prefix user now gets
> this complaint on each and every emerge invocation.  It does not seem to
> block any operation, but could we perhaps hold back further changes
> until I can sort this out with Zac?

Ah, I read portage(5) now and adding a virtual to package.provided is
indeed explicitly prohibited.

I removed it, but some further changes might be required for prefix
(i.e. version number >= 4.1 in package.provided to satisfy the virtual),
and I'll indeed hold back further changes in that area,
and preferably just let you do any necessary fixes for prefix.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: virtual/shadow

[Fabian Groffen]

On 12-03-2012 10:16:12 +0100, "Paweł Hajdan, Jr." wrote:
> On 3/8/12 2:23 PM, "Paweł Hajdan, Jr." wrote:
> > And then convert profiles to the new virtual (the relevant files; below
> > are all occurrences of sys-apps/shadow):
> 
> Because of no comments, I went ahead and checked in
> sys-apps/hardened-shadow and virtual/shadow, and now made changes in
> profiles/
> 
> Please let me know if you see any problems after those changes,
> especially related to stage generation, prefix, bsd, and uclibc.

My rsync0 now spits out this message:

  Virtual package in package.provided: virtual/shadow-0
  See portage(5) for correct package.provided usage.

I did not forsee this happening, but each and every Prefix user now gets
this complaint on each and every emerge invocation.  It does not seem to
block any operation, but could we perhaps hold back further changes
until I can sort this out with Zac?

Thanks

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Kent Fredric]

On 12 March 2012 22:48, Ulrich Mueller  wrote:
>> On Mon, 12 Mar 2012, Kent Fredric wrote:
> There's little danger if we require the EAPI specification to be in
> the first line of the ebuild. Of course the regexp should be general
> enough to account for a non-bash comment syntax.
>

There's the obvious case of compiled-binaries where that might not be
possible, but thats definately strawman stuff and I wouldn't support
that sort of nonsense anyway. Compiled binaries for ebuilds can gtfo.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ulrich Mueller]

> On Mon, 12 Mar 2012, Kent Fredric wrote:

> I just find a top-down regexp solution dangerously naive, as its
> infering that the first line that matches the regexp *is* the EAPI
> requirement field, when depending on the actual format used, that
> may not be the case.

There's little danger if we require the EAPI specification to be in
the first line of the ebuild. Of course the regexp should be general
enough to account for a non-bash comment syntax.

Ulrich

Re: [gentoo-dev] RFC: an eclass for github snapshots?

[Michał Górny]

On Mon, 12 Mar 2012 09:36:00 +0800
Ben  wrote:

> On 12 March 2012 02:27, Michał Górny  wrote:
> > On Sun, 11 Mar 2012 10:25:38 -0700 (PDT)
> > Leho Kraav  wrote:
> >
> >> On Monday, May 30, 2011 9:30:02 AM UTC+3, Michał Górny wrote:
> >> >
> >> > Right now, a quick 'grep -l github.*tarball' shows that there are
> >> > about 147 ebuilds in portage using github snapshots. This
> >> > evaluates to 83 different packages.
> >> >
> >> > The problem with github is that it suffixes the tarballs with
> >> > a complete git commit id. This means that the `S' variable
> >> > in the ebuild needs to refer to a long hash changing randomly.
> >> > Right now, the problem is handled in a number of ways:
> >> >
> >> > 1) (from app-admin/rudy)
> >> > 2) (app-emacs/calfw and suggested solution for Sunrise)
> >> > 3) (app-misc/bgrep)
> >> > 4) (app-misc/tmux-mem-cpu-load)
> >> >
> >> > What I'd like to do is creating a small github.eclass,
> >> > encapsulating a common, nice way of handling the S issue. I
> >> > guess the best solution would be to git with something like 2)
> >> > above, with the eclass providing github_src_unpack() for EAPIs
> >> > 2+.
> >>
> >> What is the current situation with this one? Every once in a while
> >> I run into a github ebuild I need to create and I am not really
> >> sure what to do with it.
> >>
> >> Right now 2) seems like the safest approach. But did anything get
> >> into EAPI?
> >
> > You mean eclass? I submitted one for review but didn't get much of
> > positive feedback on it. I'll commit it anyway soon, just let me
> > double check and do some testing.
> 
> +1 from me. I think it would be useful to have a standard way of
> handling this.

Attaching my current conceptual eclass. I've tested it with github,
gitweb and bitbucket. It won't work with gitorious but their snapshot
download mechanism is broken anyway (they like to submit 'try again
later' in plaintext).

-- 
Best regards,
Michał Górny
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

# @ECLASS: vcs-snapshot.eclass
# @MAINTAINER:
# mgo...@gentoo.org
# @BLURB: support eclass for VCS (github, bitbucket, gitweb) snapshots
# @DESCRIPTION:
# This eclass provides a convenience src_unpack() which does support
# working with snapshots generated by various VCS-es. It unpacks those
# to ${S} rather than the original directory containing commit id.
#
# Note that this eclass handles only unpacking. You need to specify
# SRC_URI yourself, and call any autoreconfiguration as necessary.
# The example does that using autotools-utils eclass.
#
# Right now, the eclass was tested with github, bitbucket and gitweb
# snapshots. Feel free to report snapshotting services which aren't
# working.
# @EXAMPLE:
#
# @CODE
# EAPI=4
# AUTOTOOLS_AUTORECONF=1
# inherit autotools-utils vcs-snapshot
#
# SRC_URI="http://github.com/example/${PN}/tarball/v${PV} -> ${P}.tar.gz"
# @CODE

case ${EAPI:-0} in
0|1) die "EAPI ${EAPI} unsupported.";; # default(), SRC_URI arrows
2|3|4) ;;
*) die "github-snapshot.eclass API in EAPI ${EAPI} not yet established."
esac

EXPORT_FUNCTIONS src_unpack

vcs-snapshot_src_unpack() {
default

# github, bitbucket: username-projectname-hash
# gitweb: projectname-tagname-hash
mv *-*-[0-9a-f]*[0-9a-f]/ "${S}" || die
}


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFC: virtual/shadow

[Paweł Hajdan, Jr.]

On 3/8/12 2:23 PM, "Paweł Hajdan, Jr." wrote:
> And then convert profiles to the new virtual (the relevant files; below
> are all occurrences of sys-apps/shadow):

Because of no comments, I went ahead and checked in
sys-apps/hardened-shadow and virtual/shadow, and now made changes in
profiles/

Please let me know if you see any problems after those changes,
especially related to stage generation, prefix, bsd, and uclibc.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Kent Fredric]

On 12 March 2012 22:09, Michał Górny  wrote:

>> or as .
>
> No, definitely not. That's not the XML style.

Sure, but these examples are just examples after all. And XML is only
being used for an example use case, but there are many  more
structured formats than XML.

Some of us are mostly just worried that the proposals as they stand
won't be resilient enough to allow a future that isn't bash.

>> Part of the point of all of this is that we shouldn't have to guess
>> what future EAPIs will look like.
>
> I'm just suggesting a way which will support a little more than
> bash-based solutions. We could also assume that if a file doesn't match
> the regexp at all, it's a unsupported EAPI.

I just find a top-down regexp solution dangerously naive, as its
infering that the first line that matches the regexp *is* the EAPI
requirement field, when depending on the actual format used, that may
not be the case.

If for example, a format is machine generated, and the EAPI
declaration accidentally comes after something that *isnt* an EAPI
declaration but by the regexp, LOOKS like one,   then the probing
mechanism will resolve the WRONG value.

And that doesn't strike me as being very resilient.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michał Górny]

On Mon, 12 Mar 2012 21:39:52 +1300
Kent Fredric  wrote:

> On 12 March 2012 21:27, Michał Górny  wrote:
> > And we could just use a good regex for that instead.
> >
> > Something like: [eE][aA][pP][iI]  [a-z0-9-+]+
> >
> > and just require users for this to be the first thing declared in
> > an ebuild. Of course, this could make problems with stuff like:
> >
> > # EAPI 4 because of foobarbaz
> > EAPI=4
> >
> > (on the other hand, in this particular case it will fetch '4'
> > anyway).
> >
> > And this will work as well with:
> >
> > 15-xml
> >
> > and
> >
> > - eapi: 15-yaml
> >
> 
> Also, remember the proposal is to read it only from the first 10-30
> lines of the file, and if you're *generating* YAML/XML , then this is
> not necessarily guaranteed.
> 
> Some generation tools emit keys in alphanumeric ordering, others
> psuedo-randomly, and the EAPI declaration line in some formats could
> easily be on the very last line of the file.

You should ensure your tool does the right thing, I'd say. XML with DTD
often requires specific element order, so such a tool is simply bound
to fail with XML.

For yaml, it's a fair point.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Michał Górny]

On Mon, 12 Mar 2012 08:30:19 +
Ciaran McCreesh  wrote:

> On Mon, 12 Mar 2012 09:27:11 +0100
> Michał Górny  wrote:
> > 15-xml
> > 
> > and
> > 
> > - eapi: 15-yaml
> 
> You're carefully concocting your examples to make it look like it
> should work.

Or I am just printing the first thing that comes into my head.

> If you go the XML route, though, the EAPI would either be in a DTD

Like .../gentoo/eapi/15-xml.dtd ? That would match my regex as well,
unless we allow dots in EAPI.

> or as .

No, definitely not. That's not the XML style.

> Part of the point of all of this is that we shouldn't have to guess
> what future EAPIs will look like.

I'm just suggesting a way which will support a little more than
bash-based solutions. We could also assume that if a file doesn't match
the regexp at all, it's a unsupported EAPI.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] Re: newsitem: unmasking udev-181

[Duncan]

Robin H. Johnson posted on Sun, 11 Mar 2012 23:14:46 + as excerpted:

> On Sun, Mar 11, 2012 at 11:03:50PM +, Duncan wrote:
>> Meanwhile, also note that there's PARTLABEL, PARTUUID and ID, that the
>> mount manpage promises to honor.  I've not used these myself, but there
>> was a thread on the btrfs list discussing GPT format and users of its
>> partition-labels (as opposed to filesystem labels), that pointed out
>> that mount honors these, since it internally uses the udev symlinks
>> mechanism to support (fs) labels, etc, so they get support for
>> gpt-partition- labels, etc, essentially "for free".

> What manpage are you reading?
> # man 8 mount |grep PART # man 2 mount |grep PART Nada.
> 
> When the blkid tool can read PARTUUID/PARTLABEL, then it will just work
> with genkernel, as we use blkid for doing that.

mount (8) under device indication:

>

Most devices are indicated by a file name (of a block special device), 
like /dev/sda1, but there are other possibilities.  [...] It is possible 
to indicate a block special device using its volume LABEL or UUID (see 
the -L and -U options below).

The recommended setup is to use LABEL= or UUID= tags rather  
than /dev/disk/by-{label,uuid} udev symlinks in the /etc/fstab file. The 
tags are more readable, robust and portable.  The mount(8) command 
internally uses udev symlinks, so use the symlinks in /etc/fstab has no 
advantage over LABEL=/UUID=.  For more details see libblkid(3).

<

As I said, it wasn't apparent to me until someone pointed it out to me on 
the btrfs list, but apparently, mount understands SOMETHING= as 
referencing /dev/disk/by-something, using those symlinks internally, so 
while the manpage doesn't specifically mention PARTLABEL, etc, according 
to that person, it "just works".  Upon seeing that claim, I reread the 
manpage, and sure enough, that meaning can be seen "between the lines" if 
you already know to look for it.

I had intended to try it, since I use gptfdisk and gpt partitions pretty 
much universally now, and referencing the PARTLABEL would have meant that 
I could for instance do a mkfs and redo my backup partitions without 
having to update fstab's labels because I could use the partlabels 
instead.  Unfortunately, when I actually checked to see what symlinks 
udev was putting in /dev/disk/by-partlabel, while indeed the gpt 
partlabels for the physical disks were there, the partlabels for the
gpt-partitioned md/raid devices were NOT, and that's what I actually 
needed, so unfortunately I couldn't try using partlabels after all.  
That's why I've yet to actually verify the claim.

At some point I'll probably verify it with a USB attached external drive, 
as it's my last-resort backup, and/or on my netbook, with only one drive 
so no raid, but I've not gotten that far, yet.


FWIW, the thread started with someone complaining that a btrfs label on a 
multi-device filesystem (since btrfs can do that) was attached to the 
filesystem, NOT the device/partition.  Various people pointed out that 
it's a filesystem label and that btrfs thus had it correct.  Meanwhile, 
on one subthread I pointed out gpt partition labels as an alternative, 
but said I didn't think Linux could actually do much with them yet.  
That's when someone else replied that it could do more than I thought, 
mount and fstab handled partlabel, and he thought the kernel root= 
parameter could take it as well.

Here's his post on gmane:

http://permalink.gmane.org/gmane.comp.file-systems.btrfs/16023

As I said, after reading that, rereading the mount (8) manpage, it /did/ 
seem to hint that it should do so even if it doesn't outright say it, 
since it specifically mentions using udev's symlinks internally.

But as I've not tried it yet I have only his post and my reparsing of 
that manpage based on it, to go on.  Is it incorrect?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Proposal: New irc data field in layman's repositories.xml file format

[Robin H. Johnson]

On Mon, Mar 12, 2012 at 08:52:20PM +1300, Kent Fredric wrote:
> On 11 March 2012 22:09, Brian Dolbec  wrote:
> >
> > eg:
> >
> > ?? ??Channel #gentoo-guis on the freenode network
> > or
> > ?? ??#gentoo-guis on the freenode IRC network, 
> > irc://irc.gentoo.org/gentoo-guis
> >
> 
> Though a freeform text field is probably better for humans, I'd
> suggest having more explicit data available as an option, ie:
> 
> Channel
> #gentoo-guis on the freenode network
+1 on this.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Kent Fredric]

On 12 March 2012 21:27, Michał Górny  wrote:
> And we could just use a good regex for that instead.
>
> Something like: [eE][aA][pP][iI]  [a-z0-9-+]+
>
> and just require users for this to be the first thing declared in
> an ebuild. Of course, this could make problems with stuff like:
>
> # EAPI 4 because of foobarbaz
> EAPI=4
>
> (on the other hand, in this particular case it will fetch '4' anyway).
>
> And this will work as well with:
>
> 15-xml
>
> and
>
> - eapi: 15-yaml
>

Also, remember the proposal is to read it only from the first 10-30
lines of the file, and if you're *generating* YAML/XML , then this is
not necessarily guaranteed.

Some generation tools emit keys in alphanumeric ordering, others
psuedo-randomly, and the EAPI declaration line in some formats could
easily be on the very last line of the file.

And then the regexp could falsely detect something in another key the
original author had not intended as an EAPI definition, but merely a
comment, ...

ie:


  This is a user comment, hurr, I hate EAPI 5 




-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Brian Harring]

On Sun, Mar 11, 2012 at 09:08:24PM -0700, Zac Medico wrote:
> On 03/11/2012 06:55 PM, Brian Harring wrote:
> > On Sat, Mar 10, 2012 at 08:06:50AM -0800, Zac Medico wrote:
> >> Yeah. Another way of putting it is that the requirement to spawn a bash
> >> process and source the ebuild adds a ridiculous amount of unnecessary
> >> complexity, in violation of the KISS principle [1].
> > 
> > This statement is incorrect.
> > 
> > Even if EAPI could be parsed via some non sourcing approach, we 
> > *still* have to source the ebuild to get the metadata for when the 
> > EAPI is supported (the vast majority of usage).  That complexity is 
> > there one way or another- we wouldn't be trying to extract the EAPI 
> > from the ebuild unless the cache was invalid/missing.
> 
> There are a couple of other cases worth considering:
> 
> 1) User downloads an overlay that doesn't provide cache. We want the
> package manager to give a pretty "EAPI unsupported" message, rather than
> spit out some bash syntax errors.

This criticsm pretty much applies *strictly to the existing 
implementation*.  It's disenguous busting it in this fashion.

EAPI as a function explicitly gives it an out before hitting any of 
that, eliminating your entire critique.  Same goes for parsing it out 
of the ebuild, or renaming the extension.


> 2) You're assuming that a package manager can validate cache for an EAPI
> that it doesn't necessarily support.

Actually, I'm not.

> That's a somewhat fragile
> assumption, given the complexities of cache validation, which involve
> verification all files that affect metadata and those files may vary
> depending on the EAPI.

This is a fair bit of handwavey bullshit.  The same "complexities of 
cache validation" we have to by default deal with for valid/supported 
EAPIs; the case for unsupported EAPIs is actually simpler than 
for supported EAPis, and up until 7ddb7d30, was likely working fine in 
portage.  Tweaking portage to restore that support is pretty easy.

Also note that with the sole exception of g55, every implementation 
has to deal with this specific issue, even g55 isn't fully exempt from 
it since in cleansing a cache, there is the open question of pruning 
cache entries for ebuilds known, but not understood by the local PM.

Either way, the algo is as follows: PM pulls EAPI from the ebuild 
(regardless of method); PM recognizes that it can't handle it- thus 
it stores EAPI:-$EAPI, and the normal cache ebuild checksumming; 
whether it be mtime, md5 for md5-dict, or whatever form new caches 
choose to use.

For attempts to load, the cache subsystem checks that validation 
before trusting the cache entry- this is in place and has been for a 
very, very long time.  This isn't anything new.

So... the entry point is the ebuild; we have checksums for it, and a 
prefixed versions of it's EAPI stored.  The sole deal breaker here is
if we were to decide to allow eclasses to set EAPI (rather than the
current "you're not supposed to, although we don't explicitly block 
it"- which could be tightened to be disallowed at the implementation 
level for EAPI>4).

The following scenarios exist:

1) PM still doesn't support that EAPI, looks at the cache/ebuild: 
checksums are the same, thus the stored EAPI is trustable, leading to 
the PM knowing it still can't process that ebuild and masking it 
appropriately.

2) PM still doesn't support that EAPI, looks, sees that the checksums
no longer match the ebuild.  Re-pulls metadata/EAPI; if the ebuild has 
been changed to a supported EAPI, continues on its way.  If not, 
stores the checksum/negated EAPI, and masks appropriately.

3) PM now supports that EAPI, looks, sees the negated eapi and 
recognizes it as one it knowns, and forces regeneration.

All of those scenarios are there, and easy enough to handle- this 
applies for the existing EAPI implementation additionally.


Now, this isn't to say that someone can't go and try to structure new 
features explicitly to defeat the existing validations.  They could.

The question here is whether or not new features would actually 
*break* that w/out intentionally going out of their way to do so (aka, 
skip the strawman arguments, actual examples required).


> > Phrasing it more bluntly: you can only avoid the sourcing step if you 
> > can isolate that the EAPI is unsupported (which is extremely rare in 
> > terms of actual user experience).  For the rest of the time (well past 
> > the 99% mark) sourcing is the immediate step following.
> 
> For the sake of being robust in all possible cases, it's just a lot
> simpler if we can obtain the EAPI simply and reliably, without spawning
> bash to source the ebuild.

This still is arguable; any performant PM is going to have to do the 
cache dance I mentioned above, or maintain an in memory list of 
ebuilds it knows it can't handle (which if you want to talk robust, 
fails miserably if the API isn't designed for sync invalidation of 
that global list).  Complexity, oh my.

Tha

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ciaran McCreesh]

On Mon, 12 Mar 2012 09:27:11 +0100
Michał Górny  wrote:
> 15-xml
> 
> and
> 
> - eapi: 15-yaml

You're carefully concocting your examples to make it look like it
should work. If you go the XML route, though, the EAPI would either be
in a DTD or as .

Part of the point of all of this is that we shouldn't have to guess
what future EAPIs will look like.

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature