Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

[Kent Fredric]

On Mon, Sep 22, 2008 at 1:04 AM, Ulrich Mueller <[EMAIL PROTECTED]> wrote:
>
> > On Sun, 21 Sep 2008, Steve Long wrote:
>
> > Vaeth wrote:
> >> let me remark that the more clever way to this is
> >> [ -n "${DOCS}" ] && eval "dodoc ${DOCS}"
>
> > [...]
> > BASH arrays will cope with *any* character apart from NUL, which
> > isn't allowed in filenames. Can you _guarantee_ the same?
>
> It seems to me that both bash arrays and "eval" are overkill here.
>
> After all, we are talking about a _default_ behaviour, and IMHO this
> should be kept as simple as possible. I doubt that there are many
> ebuilds installing files with strange names in /usr/share/doc. The few
> (if any) doing that might need a more complicated src_install anyway.
>
> My system may not be representative, but here are _no_ files
> containing spaces in /usr/share/doc:
>
> $ find /usr/share/doc | wc
>  104936  104936 7522127
>
> (Note that the number of lines and words are equal.)
>
> Ulrich
>

find /usr/share/doc/ -wholename "* *"
/usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2

And in case somebody gets space-phobic on a different directory :

find /usr/ -wholename "* *"
/usr/kde/4.2/share/applnk/Development/Web Development
/usr/kde/svn/share/applnk/Development/Web Development
/usr/share/applnk/Development/Web Development
/usr/share/doc/gpac-0.4.4-r1/ISO 639-2 codes.txt.bz2
/usr/share/lcms/profiles/sRGB Color Space Profile.icm
/usr/share/mixxx/( Lots here )


 ¢¢ ( Apps that break on spaces are embarrasing )
--
Kent

ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil [EMAIL PROTECTED]"[(2*x)..(2*x+1)]}'

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] GLEP 54 and hyphens in PV

[Kent Fredric]

On Wed, May 20, 2009 at 5:01 AM, Ulrich Mueller  wrote:

>
>
>${PORTDIR}/app-misc/foo/foo-1a_live.ebuild
>${PORTDIR}/app-misc/foo-1a/foo-1a-live.ebuild
>
> With our current versioning scheme the rule is very simple: ${P} is
> split into ${PN} and ${PV} at the last hyphen. This can be done in a
> straight forward way by regexp matching, and I would really hate to
> lose this nice property.
>
> Ulrich
>
>

$str="app-misc/foo/foo-1a_live.ebuild";
$str =~ /([^/]+)/([^/]+)/\2(.*).ebuild/
( $category, $package, $version ) = ( $1, $2, $3 )

Simple enough on a supporting language. Naive maybe, but has worked well for
me thus far.

It appears to be more a problem disambiguating from the user-input end of
the spectrum, and this scenario would be more likely to happen if for some
insane crack-fueled reason both packages were to exist. Even then,

app-misc/foo-1a  # must always resolve to "app-misc/foo-1a" due to no =
stating that it needs a version part
=app-misc/foo-1a # must always resolve to "app-misc/foo" due to the =
stating a mandatory version part.  ( =cat/pack is invalid )

-- 
Kent

Re: [gentoo-dev] g-cpan

[Kent Fredric]

On Tue, Jun 9, 2009 at 12:57 PM, Benny Pedersen  wrote:

>
> i like to use g-cpan more, but as lately it seems not to be so much stable
> with latest portage :/
>
> my question is how to make a bug on it or even if its worth doing it, is
> there a better proper way of make cpan modules into ebuilds as it was one
> time ?
>

I've just taken to DIYing it and making them suitable enough to go into the
overlay.

 http://gist.github.com/126197 , I tend to run that, then just work out the
depends by reading upstreams Makefile.PL /Meta.yaml .

Feel free to adjust to your liking.

Probably sounds a bit archaic, but I've gotten used to it, g-cpan and
everything else that's existed seemed to explode too often for my liking.

-- 
Kent

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

Re: [gentoo-dev] g-cpan

[Kent Fredric]

On Wed, Jun 10, 2009 at 11:40 AM, Benny Pedersen  wrote:

>
>
> perl 5.8.8 no go
>
> dependse on Moose
>

dev-perl/Moose : Available in gentoo
dev-perl/MooseX-Getopt : Available in perl overlay

All other deps should be in there already.
( cant remember if -X functions can be chained or not in 5.8.8 )

If you aren't using Moose yet, you might want to look into it.  (  )


> > Probably sounds a bit archaic, but I've gotten used to it, g-cpan and
> > everything else that's existed seemed to explode too often for my liking.
>
> it worked before,


It worked for me, .. for a time, then I tired of how it worked.


> but not much perl in gentoo is any longer maintained :/
>

Citation needed. modules are updated on average in gentoo the same week as
they come out.


>
> hope this will change to the better, i am still at gentoo, but if devs run
> away from it to deb/rpm systems then i have to also :/
>
> g-cpan -g Mail::SPF
>
> succes ?
>
> --
> http://localhost/ 100% uptime and 100% mirrored :)
>
>
>


-- 
Kent

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

Re: [gentoo-dev] preserve_old_lib and I'm even more lazy

[Kent Fredric]

> # revdep-rebuild --library '/usr/lib/libv8.so.3.9.4' && \
>        rm '/usr/lib/libv8.so.3.9.4'


Might even be worth patching revdep-rebuild:

revdep-rebuild --library /usr/lib/libv8.so.3.9.4 --autoclean


-- 
Kent

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

[Kent Fredric]

On 9 March 2012 06:30, Jeroen Roovers  wrote:
> On Thu, 8 Mar 2012 17:14:58 +
> Ciaran McCreesh  wrote:
>
>> Having a different, special rule for something that looks exactly like
>> lots of other things that do not have that different, special rule is
>> hardly hair splitting. This rule would have to be documented and have
>> special code to carefully enforce it. That's a big deal.
>
> Exactly like HOMEPAGE is a big deal?
>
> HOMEPAGE         Package's homepage. If you are unable to locate an
> official one, try to provide a link to freshmeat.net or a similar
> package tracking site. Never refer to a variable name in the string;
> include only raw text.

I'm not sure if that is a good example of "things that are weird like EAPI"

You can set HOMEPAGE in an eclass for instance, using anything you can
do with bash and build it out of substrings.

perl-module.eclass does just that.

[[ -z "${HOMEPAGE}" ]] && \
HOMEPAGE="http://search.cpan.org/dist/${MY_PN:-${PN}}/";

Not really comparable in entirety to EAPI.

-- 
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

[Kent Fredric]

On 12 March 2012 15:20, Rich Freeman  wrote:
> On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring  wrote:
>> Pragmatic reality, the eapi function actually would work fine.  As
>> pointed out elsewhere, bash parses as it goes- which isn't going to
>> change.
>
> Unless the ebuild isn't written in bash...
>
> How do you source the ebuild if you don't know what to use to source
> it?  How do you know what to use to source it if you don't know the
> EAPI?  Right now all the existing EAPIs use bash, but there is no
> reason the file couldn't be xml, or python, or just about anything
> else.


A convention that is often used in this scenario is to combine a
hashbang call with that specific sourcer stripping that hashbang prior
to the parse.

ie:

foo.ebuild:

#!/usr/bin/env eapi-xml-5

would send the current file ( foo.ebuild ) to the process "eapi-xml-5"
( as defined by the current $PATH setting )

This process can easily then strip the #! stanza before sending the
content to an XML parser.

( ps. while I wouldn't actually use XML, its a good example case
because standard shell-script style commenting is illegal syntax in
XML )

The benefits of this approach seem obvious, but there are also obvious
downsides.

1. PRO: Unlike /usr/bin/eapi  , this style is PMS Agnostic, and only
requires the PMS have a process named "eapi-xml-5" *somewhere* in the
system under $PATH

2. CON: Unlike /usr/bin/eapi , you're limited by what you can send it
, /usr/bin/env  eapi xml-5 would be preferable syntax imo, but it
doesn't work, because its parsed as [ '/usr/bin/env' , 'eapi xml-5' ]
which then yeilds a "permission denied" due to no  command with that
name existing.

3. PRO: There's not /much/ risk of a user trying to run it directly,
mostly because there's no +x bit

4. CON: This syntax is going to conflict with whatever language we are
proceeding, which while this caveat is dealt with by the command that
the file is dispatched to, its a lot of work getting everything else
to play ball ( editors won't understand, linters wont understand,
various other tools that work strictly with the native forms of that
language wont understand ) and this problem exists for *every* case
where the coding system we're targeting doesn't natively support
whatever "magic" indicators we're trying to stuff in the file.

5. PRO: detecting this notation being used in a file is cheap-ish ,
you only have to read 2 characters into the file to know its using
this notation.


As a result of all these, it seems to me if we ever want to support
non-bash or non-scripting sources ( ie: YAML, JSON, XML , etc ) or any
other language which doesn't support "# is a comment" , we're going to
be pretty much forced to declare the EAPI outside the file somehow.

Whether this is via the filename ( yes, I've seen that debate ) or via
some other metadata file ( which seems more poison than cure ) would
be the real issue.

Having to store this in a metadata file that maps *.ebuild to EAPI
would seem like a solution that would only increase the filesize of
portage, and slow down runtime substantially, unless of course you had
a per-repository index that sped this up and was generated during the
metadata/ generation phase.

Then $PMS could just load that file from each repository , and
assuming the cache was still valid, it could easily know the EAPI for
any .ebuild it would source in advance.

-- 
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

[Kent Fredric]

On 12 March 2012 15:24, Alec Warner  wrote:

> I will stab the next person who suggests 'xml-like ebuilds.'

State-fully coded ebuilds, while perhaps not to your liking, for some
code-types can be incredibly useful.

For example, 9/10 perl-module ebuilds don't need any code at all in
the ebuild itself, it could do most of the work via structured data,
with the  rest of the work done by an e-class.

However, bash has serious problems when you want to represent hierarchical data.


-- 
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

[Kent Fredric]

On 12 March 2012 20:08, Zac Medico  wrote:
> On 03/11/2012 11:50 PM, Kent Fredric wrote:
>> #!/usr/bin/env eapi-xml-5
>>
>> would send the current file ( foo.ebuild ) to the process "eapi-xml-5"
>> ( as defined by the current $PATH setting )
>
> All we need is a way for the package manager to probe the EAPI. Spawning
> a process to do that is just overkill.

Yeah, but if you read the rest of my message, you'll see my argument
that hinges around the fact most proposals so far tend to focus around
the fact the current format for ebuild is bash, and bash only, and  I
think it very hard to implement a language agnostic way to specify the
EAPI in a way that will work on languages where you

a) Can't use # to mark comments
b) May not even be working with the file directly, and perhaps
generating a .json file from a data-structure being serialised, and
the key named "EAPI" may be unpredictably placed near the end of the
.json file.

Case b is entirely plausible, and even realistic, because
non-script-based data-structures often don't bear importance on the
order of elements.


-- 
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] Proposal: New irc data field in layman's repositories.xml file format

[Kent Fredric]

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

This way you can put more behaviour on the display side in whatever UA
is processing the XML, for example, you could easily add support for
some GUI portage tool to add an "IRC" button on relevant packages
being displayed, that opens the IRC channel listed in the users chosen
IRC client ( as configured in the GUI's preferences ).


-- 
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

[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

[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

[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 );"

[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 : .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

[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

[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

[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] 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 );"

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] 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] Re: Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Kent Fredric]

On 15 March 2012 07:48, Duncan <1i5t5.dun...@cox.net> wrote:
> It does, especially when it's literally the case, including a /usr/etc
> bind-mounted on a tmpfs-based rootfs, that by login time, all that's
> visible of rootfs is mountpoints, nothing else, and /usr literally IS the
> "unified system resource" filesystem.

Considering this pretty much eliminates using / for anything useful,
we might as well rename "/usr"  "/c"

Even if it /is/ just to confuse the windows crowd =)


-- 
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] Undocumented and unused USE variables

[Kent Fredric]

On 17 March 2012 01:05, Christoph Niethammer
 wrote:
> Hello.


 quse -D amd64 consolekit declarative gdu kipi mudflap nptlonly pango
phonon pppd qt3support sysfs xorg

 arch:amd64: amd64 architecture

 local:consolekit:app-emulation/spice-vdagent: Use sys-auth/consolekit
to determine the master vdagentd in case of multiple running vdagentds
(highly recommended)
 local:consolekit:gnome-base/gdm: Allow proper handling of removable
media according to who is actually present on the machine.
 local:consolekit:kde-base/kdm: Enables support for authorization
using consolekit
 local:consolekit:kde-misc/networkmanagement: Enable support for
sys-auth/consolekit
 local:consolekit:lxde-base/lxdm: Enables support for authorization
using consolekit
 local:consolekit:net-wireless/bluez: Use sys-auth/pambase[consolekit]
to determine access to bluetooth devices based on whether a user is
logged in locally or remotely
 local:consolekit:sys-auth/pambase: Enable pam_ck_connector module on
local system logins. This allows for console logins to make use of
ConsoleKit authorization.
 local:consolekit:x11-apps/xdm: Enable native sys-auth/consolekit support
 local:consolekit:x11-misc/slim: Enable native consolekit support
 local:consolekit:xfce-base/xfce4-session: Enable authentication
support using sys-auth/consolekit

 local:declarative:dev-python/PyQt4: Build QtDeclarative module
 local:declarative:dev-python/pyside: Build QtDeclarative module
 local:declarative:kde-base/kdebindings-perl: Compile bindings for
x11-libs/qt-declarative.
 local:declarative:kde-base/kdebindings-ruby: Compile bindings for
x11-libs/qt-declarative.
 local:declarative:kde-base/perlqt: Compile bindings for
x11-libs/qt-declarative.
 local:declarative:kde-base/qtruby: Compile bindings for
x11-libs/qt-declarative.
 local:declarative:kde-base/smoke: Compile bindings for x11-libs/qt-declarative.
 local:declarative:kde-base/smokeqt: Compile bindings for
x11-libs/qt-declarative.

 local:gdu:gnome-base/gvfs: Enable sys-apps/gnome-disk-utility integration

 local:kipi:kde-base/gwenview: Support for the KDE Image Plugin Interface.
 local:kipi:kde-base/ksnapshot: Support for the KDE Image Plugin Interface.
 local:kipi:media-gfx/kphotoalbum: Support for the KDE Image Plugin Interface

 local:mudflap:dev-embedded/msp430-gcc: Add support for mudflap, a
pointer use checking library
 local:mudflap:sys-devel/gcc: Add support for mudflap, a pointer use
checking library

 local:pango:app-i18n/fcitx: Enable support for x11-libs/pango
 local:pango:media-gfx/fontforge: Enable pango font rendering
 local:pango:media-gfx/imagemagick: Enable Pango support using x11-libs/pango
 local:pango:media-libs/cogl: Build cogl-pango library for
x11-libs/pango integration
 local:pango:media-libs/silgraphite: Enables the pango-graphite pango module.
 local:pango:media-sound/abcm2ps: Use the pango library to render
fonts with non-latin characters
 local:pango:sys-boot/plymouth: Adds support for printing text on
splash screen and text prompts, e.g. for password
 local:pango:x11-libs/libaosd: Enable the textual helpers (requires pangocairo).
 local:pango:x11-libs/libmatchbox: Enable x11-libs/pango support
 local:pango:x11-wm/enlightenment: Enable pango font rendering
 local:pango:x11-wm/sawfish: Enable pango support

 local:phonon:dev-python/PyQt4: Build phonon module
 local:phonon:dev-python/pyside: Build phonon module
 local:phonon:kde-base/kdebindings-csharp: Compile bindings for Phonon.
 local:phonon:kde-base/kdebindings-perl: Compile bindings for Phonon.
 local:phonon:kde-base/kdebindings-ruby: Compile bindings for Phonon.
 local:phonon:kde-base/perlqt: Compile bindings for Phonon.
 local:phonon:kde-base/qtruby: Compile bindings for Phonon.
 local:phonon:kde-base/qyoto: Compile bindings for Phonon.
 local:phonon:kde-base/smoke: Compile bindings for Phonon.
 local:phonon:kde-base/smokeqt: Compile bindings for Phonon.
 local:phonon:net-im/kadu: Enables phonon audio plugin
 local:phonon:net-irc/kvirc: Support Phonon for audio output
 local:phonon:net-irc/quassel: Build client with phonon backend
support. This enables sound playback in client.
 local:phonon:x11-libs/qt-qt3support: Enable phonon configuration
dialog in qtconfig

 local:pppd:net-dialup/capi4k-utils: Installs pppdcapiplugin modules

 local:qt3support:x11-libs/qt-assistant: Enable the Qt3Support
libraries for Qt4. Note that this does not mean you can compile pure
Qt3 programs with Qt4.
 local:qt3support:x11-libs/qt-core: Enable the Qt3Support libraries
for Qt4. Note that this does not mean you can compile pure Qt3
programs with Qt4.
 local:qt3support:x11-libs/qt-declarative: Enable the Qt3Support
libraries for Qt4. Note that this does not mean you can compile pure
Qt3 programs with Qt4.
 local:qt3support:x11-libs/qt-demo: Enable the Qt3Support libraries
for Qt4. Note that this does not mean you can compile pure Qt3
programs with Qt4.
 local:qt3support:x11-libs/qt-gui: Enable the Qt3Support libraries for
Qt4. Note that this does n

Re: [gentoo-dev] Change USE flags when compiling with FEATURES=test

[Kent Fredric]

On 18 March 2012 08:33, Matt Turner  wrote:
> So you run set FEATURES=test to run a package's test suite during
> keywording. Later, you emerge -vuNDa ... and portage wants to reemerge
> that package with USE=-test.
>
> Can't we avoid this somehow? I presume in the vast majority of cases
> emerging with FEATURES/USE=test doesn't actually affect what's
> installed.

Not so, there are a lot of things where USE="test" pulls in extra
dependencies, dev-perl/* is rife with them.

And I've seen some things where USE=test changes behaviour of the
compile phase sufficient that enabling USE=test *could* change the
code compiled as well.

But I think I see where you're comming from.

I just can't see a reasonable cover-all approach that wouldn't really
be a large nasty package-manager specific hack.

> I'd guess we'd need to be able to remove 'test' from the set of IUSE
> and have a new helper function to check if 'test' is in FEATURES?

And besides, I'll reinstall a package if so much as the MD5 changes
due to somebody adding keywording for an arch I don't use ;)

I think what would be more practical is a sane way to enable
FEATURES="" on a per-package level like USE flags in portage, then you
could enable FEATURES="test" for that one package and it would always
build that package with USE="test"

Paludis does this already via an extended use.conf syntax:

   =dev-foo/bar-1.2  flag  -otherflag  BUILD_OPTIONS: optional_tests
LINGUAS: en

Perhaps portage does this already and I'm hiding under a rock, but I
haven't seen it, and I've just cheated the system with

linguas_en

and other similar manual USE_EXPAND tricks in my package.use

-- 
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: RFD: EAPI specification in ebuilds

[Kent Fredric]

On 19 March 2012 14:12, Steven J Long  wrote:
>
> As for non-bash ebuilds, I have always agreed with antarus that they should
> simply use a different extension. Adding a new extension per source language
> is a *lot* cleaner than one per EAPI.

Ok: If we take this notion and enshrine it in stone:

If we assume Bash 4 is a seperate language from Bash 3, as its
syntax-backwards-incompatible, is it fair to suggest that for some
future EAPI which require Bash 4, that the extension change to suit?

ie:  move from .ebuild  to .ebuild4 , where '.ebuild' conveys the
format is bash, and that '.ebuild4' is bash4 only?

That way you have a forwards declaration of the syntax/file format
required to parse the file, but no declaration of the EAPI, so you're
not breaking encapsulation.

This is breaking the direct file==eapi connection, but still
maintaining a loose file<->eapi connection.

Its /sort/ of like the "one time extension change" proposal, except
its less 'arbitrary' than something like .eb , and it gives us the
future option of changing the suffix again if bash 5 comes out with
different syntax.

Then we can do

.ebuild = EAPI 0 - 4& bash >= 3
.ebuild4 = EAPI5 - 9& bash >= 4
.ebuild5 = EAPI10 - 15 & bash >= 5

Thoughts?

-- 
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: License problem

[Kent Fredric]

On 22 March 2012 03:18, Justin  wrote:
> Hi,
>
> I need some comments on following License Agreement:
>
> http://fizz.cmp.uea.ac.uk/dyndom/dyndomDownload.do
>
> QUOTE
>
> In downloading this code you agree with the following:
>
> I will not redistribute the software to others outside of my immediate
> research group. I will suggest to other interested research groups to
> contact the authors directly.
>

I'd translate that as "Gentoo can't distribute this, and *definately*
not distribute a copy of this via gentoo's mirrors"


-- 
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] About suggesting to create a separate partition for portage tree in handbook

[Kent Fredric]

On 28 March 2012 07:53, Ian Stakenvicius  wrote:
> You know, we have "Code Listing 2.1: Filesystem Example" in Section 4,
> we could always adjust that to have a /usr/portage partition in it
> (take a bit of space away from /home, or something)
>
> It doesn't recommend/require anything, but when users see it they'll
> think about it.


I'd be careful with that logic, users may just copy it without
thinking and then wonder why it doesn't work ( because they didn't do
all the other steps required to make it work such as making sure you
don't run out of space, set DIST_DIR etc etc )

-- 
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] About suggesting to create a separate partition for portage tree in handbook

[Kent Fredric]

On 28 March 2012 08:15, Sven Vermeulen  wrote:
>> Then again, Gentoo is about choice.  It just seems like we're
>> presenting users with more choices than makes sense for a newbie.  If
>> there is a choice between something that 99.99% of users will want,
>> and some ancient piece of cruft that still works and is better for
>> 0.01% of the userbase, does that really have to be in the handbook?
>
> Welcome to documentation development. The Gentoo Handbook has always been a
> difficult source for such discussions. If we truely want to provide
> information towards our users on all possible choices, you'll need a totally
> different approach.
>
> I once started (before I left Gentoo, rejoined, left again) on a "complete
> gentoo handbook" that covered much more in greater detail (you'll find the
> last version at
> http://www.gentoo.org/doc/en/handbook/draft/complete/handbook.xml) but I've
> since moved away from that. Perhaps I should work again on it...
>
> Wkr,
>        Sven Vermeulen
>


An idea is a javascripty-dynamic-slidey thing that makes more details
and advanced stuff visible to people who want it, so you can adjust
the documentation to suit your skill level.

-- 
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: location of portage tree

[Kent Fredric]

On 28 March 2012 08:05, William Hubbs  wrote:
> All,
>
> I know this has come up before, but I don't really recall what the
> specific objections were.
>
> IMO the portage directory doesn't belong under /usr at all.
> I was chatting with another developer who uses
> /var/cache/portage/{tree,distfiles}, and I'm thinking about switching my
> default setup to do this.
>
> I realize that historically the portage tree has been installed under
> /usr, but Can we consider changing this default for new installations
> and providing instructions for users for how to get the portage tree out
> of /usr?
> William
>

I think I'd rather something closer to paludis's notion, don't assume
its "portage", assume its a repository instead.


/var/cache/repositories/gentoo/*
/var/cache/repositories/perl-experimental/*
/var/cache/distfiles/*
/var/cache/packages/*

Or something along those lines. ( And definitely with the default
locations for distfiles and pkg's outside the repository tree instead
of inside it )

-- 
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: location of portage tree

[Kent Fredric]

>
> /var/cache/repositories/gentoo/*
> /var/cache/repositories/perl-experimental/*
> /var/cache/distfiles/*
> /var/cache/packages/*
>


Actually, now I think of it, repositories /might/ be suitable for
being under /db/
the repository does sort of function like a database, the tools we use
to access it treats it like one. .

And we already have /var/db/pkg   , why not /var/db/repositories  beside it?

/var/db/pkg
/var/db/repositories/gentoo/*
/var/db/repositories/perl-experimental/*
/var/db/repositories/sunrise/*
/var/cache/distfiles
/var/db/binpkg/


-- 
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: location of portage tree

[Kent Fredric]

On 28 March 2012 08:47, Alec Warner  wrote:
> The gentoo-x86 ebuild tree is not necessarily portage related.
> However I think we should paint the bike shed '/srv/tree'

I for one never developed any love for /srv  , its always seemed like
an unwanted bit of poo left behind by an unloved gremlin.



-- 
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: location of portage tree

[Kent Fredric]

On 28 March 2012 08:59, William Hubbs  wrote:
> What I was wanting to discuss mainly was that /usr/portage isn't right;
> I think we need to move that out of the /usr directory.
>
> I'm not sure what the new default should be, nor how the default should
> be decided. Maybe we just let Zac pick one?

While we're talking about things that probably don't belong in /usr/ :

src ,  esp /usr/src/linux and friends.

I know its not likely to ever change, but its always felt very very
wrong to be under /usr

I've always sort of treated /usr as if it was this big space of
"untouchable, except by package manager", and /usr/src/linux sort of
violates that sense  ( as does /usr/local/ to an extent , but its
slightly different )



-- 
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] About suggesting to create a separate partition for portage tree in handbook

[Kent Fredric]

On 28 March 2012 08:57, Richard Yao  wrote:
>
> Could we amend this to also include the benefits of ZFS and why you
> would want to use XFS or reiserfs instead of ext{2,3,4} as your
> filesystem in situations where ZFS is not yet appropriate (e.g. using it
> on Gentoo stable)? We could also include documentation on Reiser4 while
> we are at it.

Thats probably asking a bit much, I've done my experimenting with
XFS/reiserfs , the benefits aren't that substantial to be worth the
hassle of the negatives. And as for Reiser4, if there's any
documentation mentioning that I think it being simply "Don't use
Reiser4" adequate enough.

Noob Level: Just Use Ext4
Intermediate: Just Use Ext4, use Ext3 or 2 if you want more something
else, but ext4 should do the trick
Advanced: Entertain the ideas of XFS/reiser if you want, but you're
not likely going to see a *lot* of difference over ext4 on its own
partition. Not in the long term.

I used to advocate JFS, but long term experience with it taught me JFS
is fast for new file systems, and gets progressively slower over time.
The original IBM JFS had a defrag tool nobody managed to port to Linux
so JFS just gets crufty and stays that way.


-- 
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: location of portage tree

[Kent Fredric]

On 28 March 2012 20:46, Alex Alexander  wrote:
> For example, my /usr/portage/ on this system looks like this:
>
> portage/
>        tree/
>        profiles/ -> tree/profiles/
>        distfiles/
>        packages/
>        layman/
>
> it is a big improvement over the current
> distfiles-and-packages-mixed-with-tree-while-layman-wanders state :)
> --


I'd rather the gentoo tree be classed as the same tier as other
sources, ie, more like:

> portage/
>profiles/ -> repositories/gentoo/profiles/
>distfiles/
>packages/
>repositories/gentoo/
>repositories/sunrise/

At least that way the notion of overlays is less of a "3rd class
citzens, filth, scum" comparison., and ::gentoo being the "master
repository"  is just a configuration convention, not something that is
a fixed design constraint.

Fwiw, I've also long despised the layout of the distfiles directory
being a flat hierarchy, it makes the directory a festering pit of
hellspawn over time on any filesystem that doesn't have dirindex.  (
I've seriously had "ls" take up to a minute to run in that directory,
and if I've ever made the mistake of trying to tab compete something
in there  /usr/portage/distfiles/foo  is my normal muscle
memory response, and then it sits there doing nothing for a minute and
it would have been faster to just finish typing it myself =_= )

Though I don't have any solution better than a "break it into 26
subdirs by first letter" .


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] rfc: location of portage tree

[Kent Fredric]

>
> Just use categories from repos?
>
> /usr/portage/distfiles/sys-devel/gcc-1.2.tar.bz2
> /usr/portage/distfiles/sys-libs/glibc-2.3.tar.bz2
> /usr/portage/distfiles/sys-libs/zlib-3.4.tar.bz2
> /usr/portage/distfiles/zomg-soft/zomgawesomesoft-5.3.1.tar.xz
> (from zomg repo with custom zomg-soft category ;)
>
> Btw. what would happen if, ie. mc package - well, two different
> packages, one from app-misc, one from sci-libs - but lets say they have
> a brand new release 5.0 and there's mc-5.0.tar.bz2 for both of them?
>

Yeah, as admittedly rare as that might be, thats why I didn't suggest
grouping by category =)



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] rfc: location of portage tree

[Kent Fredric]

On 28 March 2012 23:04, Piotr Szymaniak  wrote:
> Just use categories from repos?
>
> /usr/portage/distfiles/sys-devel/gcc-1.2.tar.bz2
> /usr/portage/distfiles/sys-libs/glibc-2.3.tar.bz2
> /usr/portage/distfiles/sys-libs/zlib-3.4.tar.bz2
> /usr/portage/distfiles/zomg-soft/zomgawesomesoft-5.3.1.tar.xz
> (from zomg repo with custom zomg-soft category ;)
>
> Btw. what would happen if, ie. mc package - well, two different
> packages, one from app-misc, one from sci-libs - but lets say they have
> a brand new release 5.0 and there's mc-5.0.tar.bz2 for both of them?
>


AAaactually, there's a good way of doing it which could /mostly/ be
category based.

You could in a future EAPI define a variable, say DISTDIRPREFIX , the
value of which would *default* to being $CATEGORY, but could be
overridden on a per-package basis if it was deemed nessecary to do so.

So perhaps in the case of something big like Spidermonkey, which might
need a copy of Xulrunner or firefox's source code , the package
developers could set DISTDIRPREFIX to be something like "x-mozilla"
and set that same value for xulrunner, firefox, and seamonkey, and
then the "right thing" would always just work.

And if you *really* wanted to be friendly, you could test after
sourcing the ebuild if DISTDIRPREFIX was still $CATEGORY, and if not,
create a symlink

so  you'd have

dev-lang/js185-1.0.0.tar.gz   -> x-mozilla/js185-1.0.0.tar.gz   # spidermonkey
net-libs/firefox-4.0.1.source.tar.bz2  ->
x-mozilla/firefox-4.0.1.source.tar.bz2  # xulrunner
net-libs/xulrunner-2.0-patches-1.8.tar.bz2  ->
x-mozilla/xulrunner-2.0-patches-1.8.tar.bz2 # xulrunner
www-client/firefox-10.0-patches-0.5.tar.xz  ->
x-mozilla/firefox-10.0-patches-0.5.tar.xz  # seamonkey
www-client/firefox-11.0-patches-0.4.tar.xz ->
x-mozilla/firefox-11.0-patches-0.4.tar.xz # firefox
www-client/firefox-11.0.source.tar.bz2 ->
x-mozilla/firefox-11.0.source.tar.bz2 # firefox
www-client/seamonkey-2.7.1.source.tar.bz2 ->
x-mozilla/seamonkey-2.7.1.source.tar.bz2 # seamonkey
www-client/seamonkey-2.7-patches-03.tar.xz ->
x-mozilla/seamonkey-2.7-patches-03.tar.xz # seamonkey
x-mozilla/firefox-10.0-patches-0.5.tar.xz
x-mozilla/firefox-11.0-patches-0.4.tar.xz
x-mozilla/firefox-11.0.source.tar.bz2
x-mozilla/firefox-4.0.1.source.tar.bz2
x-mozilla/js185-1.0.0.tar.gz
x-mozilla/seamonkey-2.7.1.source.tar.bz2
x-mozilla/seamonkey-2.7-patches-03.tar.xz
x-mozilla/xulrunner-2.0-patches-1.8.tar.bz2

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[Kent Fredric]

On 28 March 2012 20:16, Brian Dolbec  wrote:
> On Tue, 2012-03-27 at 19:16 +0100, Ciaran McCreesh wrote:
>> But that's ok, because extensive studies have shown that the only
possible
>> reasons for putting /usr/portage on its own partition are historical,
>> since everyone has an SSD now.
>>
>
> Yeah, right.  Since I must be the only one out there that doesn't yet
> have an SSD, you'll give me (and anyone else that still doesn't) one?
> --
> Brian Dolbec 

https://en.wikipedia.org/wiki/Sarcasm

Unfortunately, when on the internet, this often transmutes into :

https://en.wiktionary.org/wiki/dick

[image: Inline images 1]

Sorry.


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] rfc: location of portage tree

[Kent Fredric]

On 29 March 2012 07:43, Aaron W. Swenson  wrote:

> So, we're all getting way off topic and discussing reorganizing the
> whole enchilada.
>
> How about we all agree or disagree on the primary point: The Portage
> tree doesn't belong in /usr.
>

+1


> I believe that it does belong under /var/cache/.
>
> =0  # Not sure , semantically it doesn't make sense as its not behaving as
a caching mechanism of any kind and would rather  /var/portage or
/var/lib/portage or something in that direction over /var/cache . I'd even
prefer /var/lib/repositories/portage over /var/cache/portage/



> We can go a bit further and make it /var/cache/gentoo-repos/portage/.
>
> That way Layman and friends can all make the move there quite simply
> without major infrastructure changes.
>
> The Portage PMS on it's next release would just do a 'mkdir
> /var/cache/gentoo-repos/portage/ && sync && rm -rf /usr/portage &&
> echo "Portage has moved"' on its next 'emerge --sync' while still
> looking in both locations for packages.
>
> I'd rather this change not be automatic, and should be driven by ENV
variables, and the new layout be a default layout for new systems, and
write an e-news article describing the default change and how to migrate to
the new layout for people who want to.


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] rfc: location of portage tree

[Kent Fredric]

On 29 March 2012 08:21, Aaron W. Swenson  wrote:

>
>
> 'Support' is the keyword here. The repositories are regenerated given
> machinesan 'emerge --sync' and can be considered as temporary as the
> packages themselves are impermanent. Further, the repository isn't
> required to persist. If somebody really wanted to be hard on our
> infrastructure, they could do an 'emerge --sync' at boot to repopulate
> /var/cache/gentoo-repos/.
>
>
Though of course, if anybody has custom stuff in say, /usr/portage/local/
which they make by hand, nuking /usr/portage will make you *Very*
unpopular.

As will I be if I have /usr/portage/distfiles under /usr/portage/  and you
nuke /usr/portage including distfiles.

I could download distfiles again, but sorry, bandwidth is not free in every
country, and neither is the time wasted by redownloading it all.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] rfc: location of portage tree

[Kent Fredric]

On 30 March 2012 17:08, Walter Dnes  wrote:

> in the install handbook gives "/usr/local/portage" as an example overlay
> directory.  I thought it was implicit that one shouldn't edit or create
> files in /usr/portage because they may be overwritten by the system e.g.
> during an "emerge --sync".  Maybe the manual needs to state this
> explicitly.  Also, /usr/local is the "standard" place to keep one's own
> software and/or global customizations that aren't handled by the package
> manager, but don't belong in one user's home directory.
>

Yeah, I don't have that layout /now/, but there was a time where one of my
systems had stuff in there, for whatever reason, and I can't recall
deciding to put it there myself. But that said, I *have* been using Gentoo
since one of the 2004.x releases ... Ah the good old days of having the
choice of NPTL ;)


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

[Kent Fredric]

On 20 April 2012 03:31, Corentin Chary  wrote:
> Add rubygems, github, gitorious, pecl, pear, bitbucket.
> All of them are handled by my remoteids.py script.
>
> ref: https://bugs.gentoo.org/show_bug.cgi?id=406287
> ref: https://github.com/iksaif/portage-janitor/blob/master/remoteids.py
>
> --- a/metadata/dtd/metadata.dtd 2010-03-02 18:52:11.0 +0100
> +++ b/metadata/dtd/metadata.dtd 2012-04-19 14:22:14.077954310 +0200
> @@ -61,7 +61,7 @@
>     
>     
>     
> -       (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran)
>  #REQUIRED>
> +       (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran|rubygems|github|gitorious|pecl|pear|bitbucket)
>  #REQUIRED>
>
>   
>
> --
> Corentin Chary
> http://xf.iksaif.net/


I suggested last week on #gentoo-perl that it might be nice to have
'cpan' and 'cpan-module'  ( or something like that ) to disambiguate 2
queryable terms. ( where 'cpan'  => 'the package name on cpan' )

For some purposes, its most convenient to use the distribution name,
and for other purposes, (ie: cpan clients) its more convenient to use
a Module name, and its not easy to translate between the two, as
Module names sometimes switch between packages  they're shipped in.

For instance, a while ago, the BioPerl module was shipped in a
distribution 'bioperl' , which has only recently been changed to
BioPerl


http://api.metacpan.org/release/_search?q=distribution:bioperl&fields=archive,author,date,download_url

http://api.metacpan.org/release/_search?q=distribution:BioPerl&fields=archive,author,date,download_url

vs


http://api.metacpan.org/module/_search?q=module.name:Bio\:\:Perl&fields=distribution,author,release



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

[Kent Fredric]

On 20 April 2012 19:46, Corentin Chary  wrote:
> On Fri, Apr 20, 2012 at 9:37 AM, Kent Fredric  wrote:
>> On 20 April 2012 03:31, Corentin Chary  wrote:
>>> Add rubygems, github, gitorious, pecl, pear, bitbucket.
>>> All of them are handled by my remoteids.py script.
>>>
>>> ref: https://bugs.gentoo.org/show_bug.cgi?id=406287
>>> ref: https://github.com/iksaif/portage-janitor/blob/master/remoteids.py
>>>
>>> --- a/metadata/dtd/metadata.dtd 2010-03-02 18:52:11.0 +0100
>>> +++ b/metadata/dtd/metadata.dtd 2012-04-19 14:22:14.077954310 +0200
>>> @@ -61,7 +61,7 @@
>>>     
>>>     
>>>     
>>> -      >> (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran)
>>>  #REQUIRED>
>>> +      >> (freshmeat|sourceforge|sourceforge-jp|cpan|vim|google-code|ctan|pypi|rubyforge|cran|rubygems|github|gitorious|pecl|pear|bitbucket)
>>>  #REQUIRED>
>>>
>>>   
>>>
>>> --
>>> Corentin Chary
>>> http://xf.iksaif.net/
>>
>>
>> I suggested last week on #gentoo-perl that it might be nice to have
>> 'cpan' and 'cpan-module'  ( or something like that ) to disambiguate 2
>> queryable terms. ( where 'cpan'  => 'the package name on cpan' )
>>
>> For some purposes, its most convenient to use the distribution name,
>> and for other purposes, (ie: cpan clients) its more convenient to use
>> a Module name, and its not easy to translate between the two, as
>> Module names sometimes switch between packages  they're shipped in.
>>
>> For instance, a while ago, the BioPerl module was shipped in a
>> distribution 'bioperl' , which has only recently been changed to
>> BioPerl
>>
>>
>> http://api.metacpan.org/release/_search?q=distribution:bioperl&fields=archive,author,date,download_url
>>
>> http://api.metacpan.org/release/_search?q=distribution:BioPerl&fields=archive,author,date,download_url
>>
>> vs
>>
>>
>> http://api.metacpan.org/module/_search?q=module.name:Bio\:\:Perl&fields=distribution,author,release
>
> Looks sane since the goal of remote-id is being able to identify the
> package upstream.
> Do you think you could patch remotesid.py to generate tags for cpan /
> cpan-modules ? Or at least give me a pseudo-algo that does the trick.
> Thanks :)
>
> --
> Corentin Chary
> http://xf.iksaif.net
>


That is sadly not straight forward.  Extracting the package name can
be straight forward if you have the URL, because the package name is
literally the same as the archive name in SRC_URI , sans version
information.

However, if you look at many perl ebuilds, you'll notice many lack
this field and we've got other things in place, so the current parsing
technique you use to detect uses of SRC_URI wont work there ( I could
be wrong, I don't fully grok your python code )

And more-over, determining the value of 'cpan-module' may be
impossible without access to the tar.gz itself, or querying the
MetaCPAN API.

Usually, upstream are sensible and have package names which closely
correspond with the module names, ie: "Dist::Zilla" is shipped in
'Dist-Zilla-$VERSION.tar.gz',  but there are many packages which dont
do this, such as this notable example:
https://metacpan.org/release/Scalar-List-Utils  , which has no modules
corresponding to the package name, and no way to divine the/a 'main'
module from the package itself. ( and this is exacerbated by packages
changing names, or package joins ( 2 packages becoming 1 via releasing
modules together ),  and package splits ( 1 package rips into 2 sets
of modules ).

Essentially, using a cpan-module as an identifier is somewhat
"forwards only" , and even then, what it will resolve to is governed
by time.

This is fine for CPAN clients, which do the resolution hot, using the
whole of CPAN as their data, if a user asks for "Foo::Bar", their cpan
client will ask a cpan server ( or regularly (hourly) updated list )
as to what package that module can be found in ( and this only returns
the most recent package, so name changes and so-forth are invisible to
the user ).

And being helpful to CPAN clients is one of the reasons we want this
value as a specifiable option in the first place. For us, its easier
to track the package name, and then when that has to change we can
manually resolve the issue

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

[Kent Fredric]

On 20 April 2012 23:21, Corentin Chary  wrote:
>
> Currently it uses SRC_URI and HOMEPAGE, but honestly it wouldn't be
> hard to use any other environment variable and to do some checks on a
> webservice.
> Anyway for tricky cases it can still be done by hand.
>
> --
> Corentin Chary
> http://xf.iksaif.net
>


If you really want to support Perl Modules, ( which theres not much
need for at present, looks like the team have gone through already for
the most part and added remote-id's where possible already ), anything
that inherits 'perl-module.eclass' has a bit of magic, in that neither
SRC_URI or HOMEPAGE is required in the ebuild, and it just gets the
package name from what gentoo is using.  We've tried to be as close to
upstream as possible for the ease of maintenance.

However, there are still exception cases, for instance, BioPerl has to
define 'MY_PN' to tell the perl-module eclass to use a different token
( and when this is present, it should be sufficient to say that that
should be the remote-id instead of the package name:
see dev-perl/Moose  # an example with neither src_uri or homepage
see sci-biology/bioperl # an example where the package name has
been forced overridden as its changed upstream

But resolving module names is much trickier, its easy-ish to map a
module name to a package using the service, but doing it the other way
round is not so straight forward, as one package can have many
modules, and its common in perl to state dependencies in terms of the
module to require, not the package its in, but there's also often a
defacto "main module".

But I'm myself still working out how to best do that with the service
, so auto-populating a "cpan-module" identifier can be left to later,
its just something I considered "useful" to have metadata wise because
that value is more useful to users.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

[Kent Fredric]

On 21 April 2012 01:34, Corentin Chary  wrote:
> Yeah, not very important, but seems to work with this patch:
> https://github.com/iksaif/portage-janitor/commit/972aff94744741e34e99f917337430d245883c48
>
> Example:
> $ python remoteids.py --diff WWW-Bugzilla Moose bioperl
> --- a/dev-perl/WWW-Bugzilla/metadata.xml
> +++ b/dev-perl/WWW-Bugzilla/metadata.xml
> @@ -3,6 +3,7 @@
>  
...
> --
> Corentin Chary
> http://xf.iksaif.net/
>

What does it to for say, Scalar-List-Utils ?  or libwww-perl ?


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] RFC: Add new remote-id types in metadata.dtd

[Kent Fredric]

On 21 April 2012 08:33, Corentin Chary  wrote:
> On Fri, Apr 20, 2012 at 9:35 PM, Kent Fredric  wrote:
>> On 21 April 2012 01:34, Corentin Chary  wrote:
>>> Yeah, not very important, but seems to work with this patch:
>>> https://github.com/iksaif/portage-janitor/commit/972aff94744741e34e99f917337430d245883c48
>>>
>>> Example:
>>> $ python remoteids.py --diff WWW-Bugzilla Moose bioperl
>>> --- a/dev-perl/WWW-Bugzilla/metadata.xml
>>> +++ b/dev-perl/WWW-Bugzilla/metadata.xml
>>> @@ -3,6 +3,7 @@
>>>  
>> ...
>>> --
>>> Corentin Chary
>>> http://xf.iksaif.net/
>>>
>>
>> What does it to for say, Scalar-List-Utils ?  or libwww-perl ?
>
> Nothing, it's one of the cases you'll have to handle by-hand.
> Another option is to parse the HTML from
> http://search.cpan.org/dist/Scalar-List-Utils/ but I'm not a fan of
> HTML-parsing.
>
> --
> Corentin Chary
> http://xf.iksaif.net
>

http://api.metacpan.org/release/Scalar-List-Utils

Will be far better an option than parsing HTML =)

And even better:

curl -XPOST 'http://api.metacpan.org/module/_search' -d '
{
"fields": [
"module.name",
"release"
],
"query": {
"constant_score": {
"filter" : {
"and" : [
{ "term": { 
"distribution":"Scalar-List-Utils" } },
{ "term": { "status":"latest"} },
{ "term": { 
"mime":"text/x-script.perl-module"}},
{ "term": { "indexed":"true"}},
{ "term": { "module.authorized":"true"}}
]
}
}
}
}
'


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] License groups in ebuilds

[Kent Fredric]

On 10 May 2012 21:39, Ulrich Mueller  wrote:
>. Are there any other licenses
> besides *GPL and FDL that would require such a file?

I'd welcome groups so we can have a "Perl_5" group. The lions share of
modules published on CPAN are licensed "Under the same license as Perl
5 Itself", which implies "|| ( GPL-2 Artistic-1 )"

And that boilerplate stanza is thus in many of the Perl Modules ebuilds.


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: RFC: Add new remote-id types in metadata.dtd

[Kent Fredric]

On 13 May 2012 07:43, Torsten Veller  wrote:
> * Corentin Chary :
>> On Sat, Apr 21, 2012 at 03:33:18PM +1200, Kent Fredric wrote:
>> >                                     { "term": { "status":"latest"} },
>> >                                     { "term": { 
>> > "module.authorized":"true"}}
>
> What does this mean?
> - "latest"? this term looks like maintenance work.
> - what is "authorized"?

"latest" means that it will fetch metadata for whatever is deemed the
most recent non-dev release, which is really the only sane option to
go for if you want a list of modules that currently pertain to the
distribution.  You could request *all* releases and then find a union
of elements ... but that would be both erroneous and very time
consuming.

> It doesn't even list "Moose" for Moose?

Its probably falling outside the initial 10 results, I forgot it did that,

> 02packages.details.txt.gz lists 72 package names for Moose-2.0602.
>

Need to bolt on a { "size": 100 }  to the query to expand how may
results it will return.

 curl -XPOST 'http://api.metacpan.org/module/_search' -d '
{
   "fields": [
   "module.name",
   "release"
   ],
   "query": {
   "constant_score": {
   "filter" : {
   "and" : [
   { "term": { "distribution":"Moose" } },
   { "term": { "status":"latest"} },
   { "term": {
"mime":"text/x-script.perl-module"}},
   { "term": { "indexed":"true"}},
   { "term": { "module.authorized":"true"}}
   ]

   }
   }
   },
   "size": 100
}

^  that | grep module.name  | wc -l   # 83

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: RFC: Add new remote-id types in metadata.dtd

[Kent Fredric]

On 13 May 2012 07:43, Torsten Veller  wrote:
> * Corentin Chary :
>> On Sat, Apr 21, 2012 at 03:33:18PM +1200, Kent Fredric wrote:
>> >                                     { "term": { "status":"latest"} },
>> >                                     { "term": { 
>> > "module.authorized":"true"}}
>
> What does this mean?
> - "latest"? this term looks like maintenance work.
> - what is "authorized"?

Oh, and authorized is just "Has this individual release been released
by a person who has been granted permission to release that module",
as per the PAUSE authentication system. ( To compare with indexed,
which can be turned on/off by the releaser with the 'no index' flags ,
to get the authorization bit the module owner has to grant your PAUSE
name rights )

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 24 May 2012 05:35, Alexey Shvetsov  wrote:
> Full clone will be about 1G or so but no more then 2. If we will drop
> changelog it will be much smaller
>

And if you use git commit signing instead of ebuild manifests,
intra-commit churn will almost be negligible. :D


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 24 May 2012 08:32, Rich Freeman  wrote:
>
> Sure.  The slow commit rate encourages careful deliberation before
> hitting the enter key, which therefore improves quality.
>
> Then, if you do make a mistake the slow commit rate means that fixing
> that mistake can take a long time, which increases the amount of pain
> our end-users run into due to the mistake, which leads to lots of
> flame wars on -dev.  That means that the guy who made the mistake is
> subjected to more public ridicule, and is less likely to do it again,
> That improves quality too.
>
> Since cvs doesn't tie together tree-wide changes in a nice way or
> allow them to be transactionally completed, individual package
> maintainers don't need to be as concerned with the big picture view.
> Now as the maintainer of libfoo the fact that somebody changed my
> ebuild without making a corresponding change in some profile is
> completely hidden from me, and I can go to sleep peacefully without
> realizing that my users are all going to have horribly broken systems
> in the morning.  Blissful ignorance of end-user suffering improves
> developer morale, and helps get rid of pesky users at the same time.
>
> cvs also makes more more aware of what is going on around me.  Anytime
> I want to work on something in parallel with the main development
> branch I get to manually merge changes in, which keeps me aware of my
> place in the world.  That means that I'm less likely to build nice new
> features, which means fewer bugs, which improves quality, and may even
> drive away users as an added bonus!
>
> See, cvs is really the wave of the future!
>
> Rich
>




This CVS stuff sounds a bit too uppity and unstable to me, sounds like
we should go back to the tried and true code collaboration by
date-stamped tarballs of the tree which are centralised once a week to
a master tarball.



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 24 May 2012 09:48, Michael Weber  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/23/2012 11:14 PM, Dan Douglas wrote:
>> On Wednesday, May 23, 2012 04:47:04 PM Robin H. Johnson wrote:
>>> 2. rsync generation is NOT going away. Users will still be using
>>> it.
>
> First, I'd stick with the current rsync to spread the tree (mirror
> work and mirrors+regular rsync users shouldn't notice any backend
> switch at all).
>
>
>> Would users have a way of gaining read-only access? This would be
>> EXTREMELY helpful.
> Sure, this would be possible like any other git checkout
> (layman-git-overlays, github.com, etc.).
>
> Please compare (browsing source and access description)
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/
> http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git
>
>
> - --
> Gentoo Dev
> http://xmw.de/
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk+9W0EACgkQknrdDGLu8JADaQD+KC6cLJ5LqpNrKkNEBT1kAvJW
> xn+ZcfcMGJzc8GPyQZAA/jKug+5/DlDAHVGBIjAJOi9xf4EFqroL4eyPY8SD2neh
> =dvFZ
> -END PGP SIGNATURE-
>


I think there should most definitely be an official github mirror of
the main tree, just a "read-only" mirror from githubs perspective.

Just how to best do the mirroring is the question

a) Replicate to github when a user does 'push' with a server-side push hook?
  ( Downside: if github goes down, gentoo devs will see it when
they push, and pushing takes longer because the output from the
replicated push is delivered to the original dev )

b) Daemonized hook that monitors for changes in the master repo, and
replicates commits to github after each push

c) Tie it with the rsync tree building system so every time the tree
is built for rsync clients, the master is replicated to github.


Also, this should obviously be force-pushed, so any branch rebases on
the master repo are replicated to the github mirror properly.
-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] anybody interested in writing a Perl ebuild?

[Kent Fredric]

On 24 May 2012 19:01, Grant  wrote:
 Verifying ebuild manifests
> !!! A file is not listed in the Manifest:
> '/usr/local/portage/dev-perl/DateTime-Format-RFC3339/DateTime-Format-RFC3339-1.0.5.ebuild'
> !!! A file is not listed in the Manifest:
> '/usr/local/portage/dev-perl/DateTime-Format-Atom/DateTime-Format-Atom-1.0.2.ebuild'


Why this is occuring is strange.

For each module it complains is "not in the manifest",

cd $packagedir
repoman manifest

ie:

cd /usr/local/portage/dev-perl/DateTime-Format-RFC3339/
repoman manifest

This should

a ) Re-attempt downloading the source tar.gz from cpan if its not
already downloaded
b ) update the Manifest file for both the source tar.gz and the
problematic ebuild.

if something goes wrong while doing repoman manifest, then please
report that error.

( g-cpan should do this any-way, but seeing why repoman manifest
fails, if it fails, should help diagnose the issue )

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] anybody interested in writing a Perl ebuild?

[Kent Fredric]

On 24 May 2012 19:01, Grant  wrote:
> I've never had very good luck with g-cpan.  I thought there were a lot
> of dev-perl ebuilds in portage for CPAN modules and that g-cpan was
> for those that hadn't been added to portage yet?

Yes, to an extent. Also, if you haven't already, check out the
perl-experiemental overlay, which has a much, much larger collection
of Perl Module ebuilds.

Its not as well maintained as the main tree, but its not bad IMO*

you might get lucky and somebody might put it in the tree for you if
g-cpan doesn't want to work.

* biased, I do a large amount of that =p




-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Do we need games group and all that game prefixes?

[Kent Fredric]

On 21 May 2012 04:26, Michał Górny  wrote:
> Hello,
>
> In today's MythBusters™: do we actually need the whole ugly-awful
> mangling games.eclass does for games? By that I mean:
> - installing games in random pre-/postfixes rather than standard FHS-y
>  locations,
> - changing ownership and permissions of all the files.
>
> Do we really need all of this poor man's 'you shall not play our
> games'? I don't think we're using anything like /usr/office & office
> group, or /usr/random-programs-i-dont-like.
>
> Random obscurity only makes things harder. And proves no point unless
> we're going to ensure that all web browsers, ssh clients and other
> applications in danger of being used to play games. And while we're at
> it, why don't we just take the computer away and work on paper sheets?
> Oh wait, someone could play tic-tac-toe on it...
>
> So, my proposition is: finally drop that. Install games in regular
> prefixes, like all other apps. Don't pollute systems with unnecessary
> security perimeters which don't provide any real benefit.
>
> Any comments?
>

It wouldn't be so bad if it was done once, in one module, perhaps
"games-env" or similar and all games depended on that, instead of the
current scenario, where each and every games package does magic to set
up the right env bits. ( including creating profiles/groups if they
don't already exist, and stuffing paths in $PATH for all users even if
they're not in the games group, which causes bugs with git ... )

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




-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 25 May 2012 00:05, Dirkjan Ochtman  wrote:
> On Thu, May 24, 2012 at 1:43 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> In that regard, git is nothing like for instance svn, where branches come
>> at a much higher cost, as does merging between them.
>
> That's wrong. SVN branches are just about as cheap as git branches,
> although merges used to be much more painful. I'm not sure how good
> merging in recent SVN is.

Cheapness ... maybe in binary disk utilization ( need an actual
comparison here I think ), but in cognitive overheads, I'd argue git's
branching system is definitely cheaper.  Going from Git back to SVN,
the mentality of "copy a directory and you have a new branch!!!" seems
a bit crazy.

And switching between branches in-place at a fixed disk location is
definitely cheaper ( mentally at least ) than SVN.

I hope I never have to use svn switch again :/
-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 25 May 2012 03:02, Ralph Sennhauser  wrote:
> On Thu, 24 May 2012 16:40:02 +0200
> Michał Górny  wrote:
>
>> d) Talk with github folks to add our repo as 'mirror'.
>
> Can we keep the master on Gentoo hardware please.

Definitely.  But having a mirror on github will increase forkability,
and will make it much faster for people to get started on
contribution.

When the user has their tree up to how they want it, they can either
send a pull request to another gentoo dev who also has a fork on
github, or send a link to the commit via some medium ( bug tracker ? )
, and some dev can just add that as a remote, and merge/cherry-pick
the commits they want..

In my books, github is mostly a marketing and ease of access platform
that streamlines the ability for people to get started contributing
and facilitate easy distribution of changes back to upstream.

But this is mostly side topic.

CLEAN CUT++

If there are problems with it, we can address those when we know what
they are, not when we're inventing problems that might not actually
exist due to conjecture.

I haven't encountered any "real" problems yet in size or performance
constraints with perl-experimental  . Sure, its not portage, its only
~800 packages vs portages 15000 , but it should be a somewhat
reasonable synthetic workload.

Side note: I assume, that there is, a way, if you *really* need it, to
copy all the new git commits back to the cvs tree if something
critically broken in git turns up so bad it has to be dropped. I think
it unlikely, but knowing there is a way to "go back" would give much
reassurance.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] anybody interested in writing a Perl ebuild?

[Kent Fredric]

On 25 May 2012 03:05, Grant  wrote:
> DateTime-Format-RFC3339

Ah. The dreaded v-strings.

You'll note: http://cpan.metacpan.org/authors/id/I/IK/IKEGAMI/

That there is a "v" before the version specifier in the problem dist,
and the portage ebuild has not factored this into the equation, and is
looking for DateTime-Format-RFC3339-1.0.5.tar.gz when it should be
looking for DateTime-Format-RFC3339-v1.0.5.tar.gz

If you can edit the ebuild source to solve this issue, and then re-run
repoman manifest, that might help. But at least we now know what is
happening wrong with g-cpan.

In editing, you'll be wanting to look for varibles ( mostly in SRC_URI
and I think S )  which use "${PV}" and change it to use "v${PV}"
instead.


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

>
>
> ...is this something we (as the developer base) WANT non-dev's to be
> able to do??  I would expect we'd want the tree to still be treated as
> read-only-not-modifyable by the rest of the gentoo/linux community,
> otherwise we're going to have a rather large mess on our hands
> (multiple forks of the main tree != a uniform main tree + overlays,
> the way it does now)

Yes, we want them to.

There is still going to be a "master" authoritative tree, forks of
that tree will exist for the purpose of adding new ebuilds to the
master tree / bumping existing packages.

If your worry is "There are copies of gentoo /usr/portage out there
that aren't GIT HEAD" , then stop worrying, as thats already the case.

As soon as somebody modifies a file in their local /usr/portage, that
happens, and as soon as a users portage tree gets older than 1 hour,
that happens.

And if your worry is "But they could be replicating it in that form",
then don't worry, they could already be doing that,  nothing is
stopping people from re-providing  their full (tweaked) /usr/portage
via rsync to others.  In fact, if you're running in a network with a
network master, you're doing that to an extent.

But those sources are not official, and have no utility outside
development/private use scenarios, and thus, don't compete with
overlays directly.

Sure, you *could* make something like an overlay by forking gentoo
master and then maintaining that, but it would be impractical, and
you'd be better off using a plain overlay ( less noise ), or using
that fork for the purpose of getting things in master.

You /could/ do a long-lived public maintained fork, and then you'd be
Sabyon / Funtoo.

Doing this has its own difficulties, but I think long term, enabling
this is good:

Sabyon/Funtoo can fork gentoo on github, and then any improvements
made on their forks, gentoo can easily steal back, and its easier to
track the differences between them.  Win/Win in my books.

Summarised:

Yes, its a good idea.
No, we shouldn't try stopping them.
Actually, really can't stop them, its already happening, Git will just
make the workflow better on top of it.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] anybody interested in writing a Perl ebuild?

[Kent Fredric]

On 25 May 2012 07:22, Grant  wrote:
>
> EAPI="2"
>
> MODULE_AUTHOR="IKEGAMI"
>
> inherit perl-module
>
> DESCRIPTION="Parse and format RFC3339 datetime strings"
>
> LICENSE="|| ( Artistic GPL-1 GPL-2 GPL-3 )"
> SLOT="0"

add this:

MODULE_VERSION="v${PV}"

just before the inherit line and that *should* do the trick.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] comprehensive eclass checking in repoman

[Kent Fredric]

On 25 May 2012 07:47, Mike Frysinger  wrote:
> -mike

Were it me, I'd have a tool that scrapes the eclass files's
documentation and emits a .json file which repoman can then optionally
use for consistency checks.

Mostly because I don't like the idea of repoman re-probing all the
eclasses every time you check an ebuild, and would like a way of
consistency checking an ebuild and seeing what metadata it produced
without needing to see it through the eyes of "repoman full" on a
consuming ebuild.

My 2c
-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] comprehensive eclass checking in repoman

[Kent Fredric]

On 25 May 2012 08:28, Zac Medico  wrote:
>
> I expect that reading and validating the cache is probably not going to
> be much faster than just parsing the eclasses over again.
> --

Unless, you don't care if the cache is out-dated because the cache is
optional / the syntax checking is optional, and its only made
available when you generate it manually.

And considering how fast eclasses change, I doubt you'd need to
regenerate it often. Though how much time it takes to parse and stuff
really needs to be properly benched, its more that there is an
intermediate state that can be inspected by human eyes instead of a
lot of magic going on



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

[Kent Fredric]

On 25 May 2012 09:00, Aaron W. Swenson  wrote:

> I do believe git pull-requests should go through Bugzilla. A
> pull-request is the equivalent to bump requests, patch fixes, and all
> sorts of stuff that we already handle through Bugzilla. Bugzilla also
> contains our history.

+1

>
> If they happen to be needing to be pulled from github, that's fine.
> Definitely convenient for the contributor.
>
> We'll also need to clearly document how the pull-request is to be
> generated. (I vote for requiring signed pull-requests. [1])
>
> github should not be our central point of contact. We have b.g.o for
> that. github should be on the fringes as a tool that we can use if we
> want to.
>

+/-1 : Not sure, for new people, it should definitely be the go-to way
to do things.

But people who are regular contributors ( which we want to encourage )
will feel slowed down if they have to open a bug report for every
change.

And I can see github facilitating "proxy maintainers" much better.

If a proxy maintainer has another gentoo person who all their changes
get proxied through, the proxy maintainer and the gentoo dev could
both have forks on github, and the proxy maintainer could send their
pull requests to their proxy to vet and merge, somewhat like Linus'es
Generals model.

> [1]
> http://git-blame.blogspot.com.ar/2012/01/using-signed-tag-in-pull-requests.html
>
> - - Aaron
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iF4EAREIAAYFAk++oYEACgkQVxOqA9G7/aC1WgD/V33WU0Cvc/po2Evrrjk6fM4d
> IHt8FtD21rKfyrxmCeQA/A7t/nCJOA5UURm2ILAraPLWu598G8bKV7RNKtRKrqhQ
> =MVyV
> -END PGP SIGNATURE-
>



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - Handling Pull Requests (Was: clean cut or git-cvsserver)

[Kent Fredric]

On 25 May 2012 09:14, Alexey Shvetsov  wrote:
> In gentoo git tree all git commits will be signed by commiter gpg keys (and
> this will be requerd!)
>
> Aaron W. Swenson писал 2012-05-25 00:00:

Something that still confuses me about commit signing that I haven't
seen answered: How does a signed commit work with rebasing? I don't
see any flag to allow rebase to sign commits rebased, and rebasing
*does* change the commit fundementally in ways I'd expect to void any
signature.

Sure, you may not want rebasing in the master, but I sure as hell want
to use it in a branch. People who maintain a long-parallel-merge
history instead of rebasing their branches are on my personal shitlist
=p.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 25 May 2012 13:21, Alec Warner  wrote:
>
> So I'm a bit confused. Is GitHub open source?
>
Your confusion begets more confusion:

Whether or not Github is open-source seems orthogonal to whether or
not we use it, as github is a website, a service, and there are a few
such websites, of which, github appears to be the defacto most-popular
one.



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 25 May 2012 18:12, Ulrich Mueller  wrote:
>
> Actually, Alec's question is not so far-fetched. The Gentoo Social
> Contract says that Gentoo will never depend upon a piece of software
> unless it is open source.
>

Though in the case of github, gentoo is not "depending upon it".
Github could die in a ball of fire, and it wouldn't change the core
development, it would only change the development for the people who
elected to use github.

Anyone can use any git platform that competes with github, be it
bitbucket, gitorious, or a private git server they created.

Github is just a convenient go-to service for many.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] anybody interested in writing a Perl ebuild?

[Kent Fredric]

On 25 May 2012 18:16, Grant  wrote:

>
> That did it, but there's more trouble.  g-cpan strikes again?
>
 Configuring source in 
 /var/tmp/portage/dev-perl/local-lib-1.008004/work/local-lib-1.008004 ...

For local-lib, you're best trying using the copy in the
perl-experimental overlay.  If that doesn't work either, then why the
sandbox violation is occurring needs looked at.


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] anybody interested in writing a Perl ebuild?

[Kent Fredric]

On 25 May 2012 20:52, Grant  wrote:
> I switched local-lib from the g-cpan one to the perl-experimental one
> and all is well as far as installation all the way through
> Net-Braintree.  Thank you very much for sticking with me on this guys.
>
> May I ask why you force the g-cpan category to dev-perl?

Using that category solves many issues in advance, ie: if you
generated an ebuild locally, and then we provided a maintained copy,
portage would just switch from one to the other seamlessly where
needed without you having to modify all ebuilds that depend on it.

ie:

if a package was installed in perl-gcpan/ instead ( which used to be
the case iirc ), you then have:

  perl-gcpan/foo : DEPENDS dev-perl/bar
  perl-gcpan/baz : DEPENDS perl-gcpan/foo

And if you want to cede development of "foo" to an overlay/gentoo,
you'd have to change perl-gcpan/baz to point to perl-gcpan/foo
instead.

With the packages all in dev-perl, no such changes are required.

>
> To what extent is running ebuilds from perl-experimental a safe endeavor?

It should be reasonably safe, but If you want to be sure, I advise
enabling tests.

---[ /etc/portage/package.env ]---
dev-perl/* perlmod.conf
-

---[ /etc/portage/env/perlmod.conf ]---
FEATURES="${FEATURES} test"
--

And this will at least give you the same level of assurance as you
would get if you were installing the packages with a CPAN client.

We do our best to make the overlay stable somewhat, but it will always
be somewhat less important than the main tree

> Should Net-Braintree or any of the ebuilds I had g-cpan trouble with
> be eligible for inclusion in the main tree or perl-experimental?

I've it on my mental TODO list, just a lot of other things I'm behind
schedule in updating atm.

> Thanks again,
> Grant
>



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 07:52, Alexey Shvetsov  wrote:
>>
>> What would git signing work with rebased commits? Would all of them
>> have to be signed once again?
>
>
> Commits itsels still will be signed


Do you know how git does this? Do you have experience/information you
can cite as to that this works?

Commit signing seems poorly documented at present, and I've been
looking at the git internals, and it would *APPEAR* that the content
that is signed is the blob of text you normally get when you

   git cat-file -p $SHA1

And indeed, if you  git cat-file -p $SHA1 > file, extract the
SIGNATURE part into its own file (removing the leading spaces), and
remove the "gnupg" section from the commit headers,   gpg --verify
$sigfile $file   # tells me I have a good signature.

Just I haven't worked out what happens when the SHA1 of the 'parent'
header changes, which *will* change if the rebase is anything other
than a fast-forward.

If that SHA1 changes, the gpg signature will surely fail?


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 07:58, Rich Freeman  wrote:
> On Thu, May 31, 2012 at 3:33 PM, Michał Górny  wrote:
>> What would git signing work with rebased commits? Would all of them
>> have to be signed once again?
>>
>
> The whole point of rebasing is to throw away history (which is either
> good or bad based on your perspective).
>
> So, if 14 devs spend 3 years and 2000 commits working on something in
> a branch, and I commit it to master using a rebase, then all you'll
> see in the master history is that rich0 committed 20k lines of code to
> master on May 31st, and that would be signed by me.
>
> I think that rebasing before merging is a pretty typical workflow
> anyway - when you submit a patch to Linus, he doesn't really care that
> you spent six months tweaking it - he just is getting a big blob of
> code that either works or doesn't.  Does all that sub-history really
> matter?  You could always push the branch to the repository if you
> wanted to keep it on the side.
>
> Rich
>

I think you're conflating "rebasing" and "squashing commits".

You should rebase a long commit sequence and squash pointless fixup
commits, and to make the commit sequence logical and ordered, possibly
divided by logical changes that one may wish to later revert. ( That
way, backing out a problem is simply reversing that commit and
applying the reversal patch )

You should not rebase for the purpose of squashing an entire history
of changes into a single scattered commit.

Rebasing is more to make the history itself linear and non-complex,
as when walking backwards through history, there being 2 parallel
histories that generated a merged commit can be confusing for humans,
so eliminating the parallel histories is one of the primary purposes I
advocate use of rebase for.

Squashed commits are a handy feature of rebase, but I wouldn't want to
see an entire overlay squashed into the main tree as a single squashed
commit.

Another bad reason for squashed commits: if you're getting rid of the
Changes files, you'll have no history on anything if you just group
long histories into a single commit. None.



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 08:26, Duncan <1i5t5.dun...@cox.net> wrote:
> William Hubbs posted on Thu, 31 May 2012 14:54:50 -0500 as excerpted:
> Of course, if all the official overlays are converted to git branches of
> the main tree... but won't they still require rebasing as they've already
> been pushed?  (This assumes your workaround idea doesn't work.  If it
> does, great!)
>

End users will still want to work with overlays that are not merged
with the main tree, not merely git branches.

Its foreseeable that there will be git branches that /track/ overlays
and exist as an integration pipeline for content from the overlays
joining core gentoo, but end users will not want to use that.

For the simple reason of course, that as soon as you want >1 overlay,
portage's way of doing it with separate repositories is far more
effective.

You don't want each user to have to maintain an octopus merge between
all the branches they want to have commits from ;)

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 14:49, Rich Freeman  wrote:
> On Thu, May 31, 2012 at 5:52 PM, Kent Fredric  wrote:
>> Just I haven't worked out what happens when the SHA1 of the 'parent'
>> header changes, which *will* change if the rebase is anything other
>> than a fast-forward.
>>
>> If that SHA1 changes, the gpg signature will surely fail?
>
> Rebasing doesn't modify past commits - it creates new ones and the
> past ones are no longer in the history of the current head.  So, it
> doesn't break the old signatures so much as discard them.  You would
> need to create new signatures in their place, presumably from whoever
> performed the rebase.


Hmm, thats annoying. Almost makes me wish it was the trees that were
signed, not the commits.

Although, I probably could brew up a prototype resigning tool ( based
on Git::PurePerl ,... when they accept and publish my changes ) , just
would be problematic because simply the act of signing a past commit
means the SHA1 of the commit itself is different, so all successive
commits after a re-signed commit will change and also need to be
rebased and re-signed.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 20:16, Dirkjan Ochtman  wrote:
> Can you elaborate on why the cleaner history a no-merge policy
> enforces is a good thing? I actually think that seeing merge commits
> might clarify the history; it can be valuable to see that some mistake
> was made in a merge instead, but you can only see that if there's an
> explicit merge commit.
>
> I should note that I come at this from the Mercurial side, where the
> immutability of (public) history has historically carried more value
> than on the git side (and related to that, rebase-like tools were less
> integrated until relatively recently).
>
> Cheers,
>
> Dirkjan
>

One of the perk of fast-forward only histories is merge problems don't happen.

If a commit sequence isn't fast-fowardable, then the submitter has to
rebase it, and a rebased history is a guaranteed clean merge.

It also puts the onus on making the patch sequence mergable on the
contributor of that patch sequence, by forcing them to resolve
conflicts before they can submit their branch for inclusion, and this
is good, because they understand their own changes best, and are the
best person to decide how to deal with conflicts.

The best example of this is 2 people contribute behaviourally
identical code, with different syntax .

In the case of a merge, the person performing the merge has to decide
which one to take, and they might not be the best person to do so. (
And historically, it can be confusing if you look at the parents of
the merge, and find the 2 competing implementations, of which only 1
is relevant )

If you request that a branch is rebased before it is integrated, then
this problem solves itself in a way.

Whoevers implementation gets in the tree first gets in, and then the
second person rebases their branch on top of that.

In the process of performing the rebase, the second person will
discover the precise commit on their side that introduces a conflict,
and be able to decide if they need to replace the existing code
anyway, or if they need to destroy their own code.

And when they're done, their entire commit series should be sane and
logical as if the first persons code was there in the first place
before the second person even started coding.

a--->b--->c>d--->e--->f
    |  \|/
\--->x--->y>z

Essentially, in this diagram, if d and y are different, but
equivalent, they will cause a collision when merge Z is performed.

By performing a rebase of  the second branch, the logical order becomes

a--->b--->c>d--->e--->f--->x--->y--->z

And when the rebaser is applying "y", they will notice it is likely
redundant, and the history will become

a--->b--->c>d--->e--->f--->x--->z

And in both the merge and rebase examples, z will be the same, just
the cognitive overhead of understanding "what the hell happened" in
the latter case is simpler, as the biggest delta between any 2 commits
will be 1 commit worth, whereas in the merge case,  there will be a
huge delta  between the commit before the merge, and the commit after
the merge, and looking at the merge itself diff-wise, you'll be
comparing the aggregate result of 2 entire branches worth of commits,
as opposed to only comparing one small and simple commit with another.


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 1 June 2012 22:54, Rich Freeman  wrote:
> On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric  wrote:
>>
>> Hmm, thats annoying. Almost makes me wish it was the trees that were
>> signed, not the commits.
>
> I think it is the tree that is signed, but that changes too.

Nope, at least not as far as I can tell, and I just implemented commit
signature verification >_>

> Rebasing re-applies the same diff to the new head to give you a new
> set of commits.  When you apply the same diff to a different parent
> you end up with a different tree, so the tree signature won't be the
> same either.

Not nessecarily. Given that :

 a file with a given content has a fixed SHA
A tree is just a list of these SHA's , and that in turn is referenced
by SHA, so if 2 commits have identical file content, their 'tree' sha
will be the same ( in theory ).

So that means, if you perform a rebase, assuming the filesystem looks
the same as it did before the rebase, it will have the same SHA1 for
the tree, regardless of the process of how it got to be that way.

The only SHA that has to change is the 'parent',

( Demonstration here: https://gist.github.com/2851330 , note I have 2
commits with the same tree sha, and the tree sha only really refers to
one file 3 times as all the empty files have same sha  )

But unfortunately, with a rebase, even if the trees don't change, if
the history order changes, the commits themselves have to change due
to the "parent" sha needing to change ( yes, I know commits are
immutable in reality, and they don't change, but are duplicated and
the duplicate is given the new sha , but the effect is still the same
, because those unreferenced commits will eventually get reaped )


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 2 June 2012 00:42, Rich Freeman  wrote:
> On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric  wrote:
>>
>> Nope, at least not as far as I can tell, and I just implemented commit
>> signature verification >_>
>
> I've been trying to find an example of a signed commit, but can't find
> one anywhere, so it is hard to tell what it is doing without going
> through the git source carefully.  If you have an example of a signed
> commit feel free to send it to me.
>
> Note that I am NOT interested in the output of any git operation (such
> as git log --show-signature, git show, etc) - these are all processed
> and do not reveal what is actually going on.  I want a copy of the
> actual file containing the signature.  If the signature is embedded in
> the commit then I want the file in the objects directory tree that
> contains the commit.  They're just compressed text files (though it is
> a bit of a pain to decompress them).

"git cat-file -p $sha" is as close as you can get to commit objects
without needing to write your own decompressing wrapper.  But it gives
the same results.

Here is a sample signed git commit ( sans compression ) :

https://gist.github.com/2852363

Line 5 to 21 are where the GPG signature is stored. ( Git uses the
leading space on all the lines of the GPG sig to indicate that its
part of the signature, line 22 does not lead with a space, so that
line is after the GPG signature.  Line 22 also is empty, which ends
the "header" section of the commit, and there starts the "comment"
section.

If you don't believe me that "git cat-file -p $sha" is reliable, here
is a simple script that has no git internals in it , its just Zlib
decompression : https://gist.github.com/2852411

perl /tmp/deflate.pl .git/objects/66/50c09ad7b2a62e28476e639654443015ac5945

And that re-emits exactly the same thing : https://gist.github.com/2852363

And if you want to do that yourself, here's that object in compressed
form base64 encoded https://gist.github.com/2852436


> The filesystem WON'T look the same after a rebase.
>
> quick example (operations done in this order):
>
> file in commit A in master:
> 1
> 2
> 3
> 4
> 5
>
> file in commit B in a branch off of master:
> 1
> 2a
> 3
> 4
> 5
>
> file in commit C in master:
> 1
> 2
> 3
> 4a
> 5
>
> if you merge master into the branch you'll end up with a new commit D
> whose parent is B that looks like:
> 1
> 2a
> 3
> 4a
> 5
>
> if instead you rebase master into the branch you'll end up with a new
> commit D whose parent is C that looks like:
> 1
> 2a
> 3
> 4a
> 5
>
> The history for the branch will no longer contain B.  If there were 14
> commits B1..14 you'd end up with 14 commits D1.14 that each contain
> the line 4a.  None of them would use the same trees as B1..14, and
> they can't use the same signatures as a result, even if only the tree
> was signed.   As far as the new history was concerned, line 4a was
> there before the branch was started.

It all depends really on how you do the rebase, if the changes in the
rebase shadow all the competing changes , or the changes are shadowed
out before the rebase, the rebase will be the same afterwards, just
with a different history.

ie:

  root -> a -> b -> c -> d( backout of c )

If you had started a branch off "b", and then rebased that branch on
top of d, the tree would be in the exact same state, but the history
would have changed.

And likewise, if the change was :

  root -> a -> b -> c -> d -> e

And you started a branch at b, with commits m, n, o, p , changing the
same lines c, d and e changed,
and when you rebased, you opted to let the changes in m, n, and o
replace the changes in c, d and e,
( which has the same effect as if you had deleted c , d and e, except
they're still there in the history ), when you move the branch from b
to e, the last commit of that branch (p) will still be the same.

The rebased commits m, n, and o will be different to what they were
when they were on "b", because now they're not only making changes vs
"b", but they're also replacing code added in c, d, and e.

Sure, this only happens in certain circumstances, and usually when it
happens, its because you want it to happen , but it does happen, and
its quite useful sometimes.

( essentially, x + y + z == x can be true, as long as z = -y  )


> At least, that is my understanding of rebasing.  Again, I'm a bit of a
> git novice, but I never really grokked git until I saw a presentation
> that didn't start with commands, but instead started out with just
> walking through the actual structure of the repository.  Once you grok
> the COW model I find it 

Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 2 June 2012 03:12, Andreas K. Huettel  wrote:
>> "git cat-file -p $sha" is as close as you can get to commit objects
>> without needing to write your own decompressing wrapper.  But it gives
>> the same results.
>
> Now, does the "signed data" also contain the parent sha?
>
> If yes, our discussion about rebasing is moot, because a rebase will in every
> case destroy previous signatures.
>

Yes. Which basically means, you *cannot* have both

a) rebase only merges
and
b) every commit must be signed

as policies.

At very best, I think either
a) a future git might support signed rebases ( ie: replacing existing
signatures with new signatures in the name of the person performing
the rebase )
or
b) somebody could write a wrapper that provides signed-rebase support
until git get around to implementing it natively.

and even then, you're going to lose original signing info ( Though,
thats no worse than the signer of the manifest file changing every
sign )


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 2 June 2012 03:39, Rich Freeman  wrote:
> On Fri, Jun 1, 2012 at 9:25 AM, Nicolas Sebrecht  wrote:
>> So, like explained before your concern is clearly out of the current
>> discussion. Importing commit history from Overlays is not supported and
>> will probably never be. Gentoo doesn't forces (and doesn't want to)
>> overlays maintainers to use Git.
>
> I'm not sure that git even supports this, unless the overlay is a
> complete clone of the entire gentoo-x86.git repository.
>
> I think the way git operations work is by finding common parents in
> the history of two heads, and then moving forward from there.  If you
> have two completely different repositories then they never will have a
> common parent.

You can however merge dissimilar histories with no common parents if
you know what you're doing. It does warn you, but it still lets you do
it.

> Plus, even if it did work, to rebase the overlay on the gentoo-x86
> repository you'd have to import the full gentoo-x86 tree into it.
> Then you'd have to push EVERYTHING in your overlay into gentoo-x86.  I
> don't think you can just push individual files from one tree to
> another.

Yeah, selectively pulling in files with histories however is hard,
I've occasionally been fussed enough to create temporary copies of
branches, and then iterate over their history so the history is
reduced to changes only for a small selection of files, but its
largely lots of work, and I can't remember how to do it every time I
go to do it -_-

Its reasonably straight forward to cherry-pick commits in though.

> From what I've seen the various methods out there which do involve
> moving only part of one branch into another basically involve a LOT of
> history manipulation or are really no different than just copying the
> files into the branch and adding them, losing all history in the
> process.
>
> I'm not sure how important all that history preservation actually is -
> the overlay would still possess it.  If we did want to preserve it
> then the only practical option I see is to have the overlay start out
> as a clone of gentoo-x86 and keep around all the non-overlay packages,
> which then means that anybody using the overlay will get all those old
> gentoo-x86 packages as part of their portage tree.  Plus you still
> have the rebase+gpg-signatures=fail issue.
>
> Rich
>

Myself, I'd be inclined to do something like this:

1. Have an integration branch on gx86
2. Select a package or packages to migrate to gx86 from an overlay
3. create a branch in the overlay that only contains the history with
regard to those packages.
4. copy the branch to a local checkout of gx86, and then rebase it on
top of the integration branch
5. then delete it from the overlay.

But the exact part of "Create a branch that contains only the history
of those packages" is the part I need to get down to an art .

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 2 June 2012 03:53, Rich Freeman  wrote:

> git-rebase is just a shell script, that ultimately just calls
> git-commit as far as I can see, which means that implementing
> re-signing is just a matter of adding the appropriate parameters, or
> use default configuration (assuming it doesn't already do this).
>
> Rich
>

Oh that makes it slightly easier, I didn't realise it was just a blob
of bash doing all that O.o

grep -nR 'git commit' git-rebase*
git-rebase--interactive.sh:152: warn "  git commit --amend"
git-rebase--interactive.sh:441: git commit --amend --no-post-rewrite || 
{
git-rebase--interactive.sh:484: do_with_author output git commit
--no-verify -F "$squash_msg" ||
git-rebase--interactive.sh:491: do_with_author git 
commit
--no-verify -F "$fixup_msg" ||
git-rebase--interactive.sh:496: do_with_author git 
commit --no-verify -e ||
git-rebase--interactive.sh:699:  git commit --amend
git-rebase--interactive.sh:703:  git commit
git-rebase--interactive.sh:723: do_with_author git commit --no-verify
-F "$msg" -e || {
git-rebase--merge.sh:30:if ! git commit --no-verify -C "$cmt"
git-rebase--merge.sh:32:echo "Commit failed, please do 
not call
\"git commit\""


Throwing '-S' in there liberally aught to do the trick.



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

On 2 June 2012 04:33, Robin H. Johnson  wrote:
> On Fri, Jun 01, 2012 at 10:45:48AM -0500, William Hubbs wrote:
>> Overlays are completely separate repositories. There is nothing stopping
>> an overlay from using git right now even if the main tree isn't using
>> git. They just work in their git repositories until they are ready to
>> commit something to the main tree, then they move the changes to the
>> main tree.
> What about overlay repositories that elect to be a branch of the main
> tree via git?
>
> Do we call that forbidden usage?

You can't practically use any overlay foolish enough to publish these
repositories for end user consumption.

Its just a silly idea. There's no problem with having overlays cloned
into a branch as a step towards it hitting mainline, but overlays
being distributed to users as main tree branches is just a silly idea.

 Mostly, because end-users will still have ::gentoo via rsync, and the
load of cloning a git repo of ::gentoo will be too much for the
average user, doing that just to get an overlay is exhaustively
execessive vs the current mechanism we have for overlays, and it comes
at a penalty at being not as good as overlays in that you can't easily
have >1 of them.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: Re: Re: [gentoo-dev] Re: Portage Git migration - clean cut or git-cvsserver

[Kent Fredric]

> Only in your local history. The push to the central repo would only send
> the commits in the active chain to your branch HEAD.

Any commits that are rebased, and then replicated somewhere after that
rebase, will be stripped of their signatures by the rebase process.



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Git braindump: 2 of N: developer interaction (merge co-ordinators)

[Kent Fredric]

On 3 June 2012 09:46, Robin H. Johnson  wrote:
 If there are enough "Alice" developers, is it a possibility that Bob
> will never have a chance to get his commit in?
>
> All this requires, is that in the time it takes Bob to do 'git pull',
> Alice manages to do 'git push' again.
>
> Alice can thus deprive Bob of a fair chance to get his commit in.
> Bob becomes an unhappy developer and gives up.

There's an easier solution here:

Bob pushes to a branch or to a public repo ( ie: github ) , and then
contacts Alice ( or somebody else ) who pulls their changes into the
tree on their behalf.

Its not "ideal" but better than nothing. And certainly better than
being stuck on SVN where this case is virtually guaranteed and with no
viable workarounds when it is encountered.



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] RFC: PROPERTIES=funky-slots

[Kent Fredric]

On 24 June 2012 05:16, Alec Warner  wrote:
>>
>> That's covered in the devmanual and in the user documentation, so
>> there's no need to repeat it here.
>
> http://devmanual.gentoo.org/general-concepts/slotting/index.html
> http://devmanual.gentoo.org/general-concepts/dependencies/index.html#slot-dependencies
>
> I don't think the documentation forbids what these developers are
> doing. I think you implemented a nice heuristic for your users in your
> resolver that used to work because slots had a typical set of users
> cases and the heuristic performed well in those cases.
>
> Now people are occasionally using slots in a different way and your
> heuristic penalizes those cases. That sucks, but you might have to
> actually change your resolver because I don't think 'funky-slots'
> properties is going to garner much adoption. It just appears that the
> heuristic you used to use isn't helpful anymore (or has too any false
> positives, or whatever.)
>


It seems to me that the defacto understanding of slots is that given 2
slots for one package, one slot will be a natural upgrade from another
competing slot, assuming a slot that is a version progression.

This makes sense for most packages.

However, it seems slots are in some cases being used for purposes
other than natural version progressions, and representing siblings
instead of child/parent , and in such case, its not logical to want to
install a different sibling simply for having a different sibling
installed.

So the request is to have some sort of metadata to optionally convey
the intent of what the slot "means", where the defacto method would be
"They're versions,  if X > Y then X is a natural upgrade from Y, and
is slotted for transition and similar reasons" , which would indicate
to UA's that if they have Y, and X becomes available, that they will
want to install X.

And there would be the alternative(s), "Funky slots" , where slots
DONT indicate version progression, and so should *not* be 'upgraded'
to from alternative slots.

Logical place to store such information to me seems 


-- 
Kent

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

http://kent-fredric.fox.geek.nz

[gentoo-dev] Feature Request/RFC : "Elective" virtuals

[Kent Fredric]

I was doing a fresh Gentoo install today, following the manual, and it
appeared to me that the manual suggests to install a "logger" and a
"cron", and gives some defacto suggestions.

However, the available packages that provide this facility(s) are not
overly obvious from a portage standpoint.

The best index I can find presently for a list of things that provide
these facilities are virtual/cron , and virtual/logger , and only then
by perusing the source.

And if you tell somebody to install "virtual/cron", you'll get the
first thing in the ||( ) list, not an elective choice of which to
install.

It makes sense to me that there are some circumstances, where it makes
sense to, instead of simply picking the first match, present the user
with the option of one of them ( somehow ).

ie:   emerge -pv virtual/cron  could, instead of the current behaviour
of installing vixie-cron,show a list with the non-chosen alternatives:

What we presently get is this:

[ebuild  N ] sys-process/vixie-cron-4.1-r12  USE="pam -debug
(-selinux)" 0 kB
[ebuild  N ]  virtual/cron-0  0 kB

Where it might be nice to instead give:

[ebuild  N ] sys-process/vixie-cron-4.1-r12  USE="pam -debug
(-selinux)" 0 kB
[ebuild  ? ] sys-process/cronie-1.4.8  USE="inotify pam" ( virtual/cron )
[ebuild  ? ] sys-process/dcron-4.5  44 kB ( virtual/cron )
[ebuild  ? ] sys-process/fcron-3.0.6-r1  USE="pam -debug
(-selinux)" LINGUAS="-fr" 540 kB ( virtual/cron )
[ebuild  ? ] sys-process/bcron-0.09  57 kB ( virtual/cron )
[ebuild  N ]  virtual/cron-0  0 kB

As a way to show that vixie-cron is being chosen as the default, but
there are other things that can optionally provide that virtual too.

(* important: dependent children of the alternatives should not be
computed or displayed, as this will only add confusion, not to mention
headaches, as all the above crons have blockers on each other to stop
them being installed together )

This is the "Simplest" option I could think of that made it more "User
facing" that these virtuals exist to provide a given feature using a
mechanism of the users choice.

You could take this further and make an interactive choice system,
which was only presented in certain conditons, ie: if the ||( )
condition was not already satisfied, or if the users command indicated
they want to choose virtuals themselves:

   emerge --virtuals=auto  # current behaviour
   emerge --virtuals=pick-missing # interactive choice only if the
conditionals are not already satisfied
   emerge --virtuals=pick-specified # interactive choice only for
virtuals listed on the invocation line
   emerge --virtuals=pick-all # interactive choice every time

Theres possibly other avenues I haven't thought of that might also be useful.

The pick interface could be something like

virtual/cron  can be provided by one of the following
1) sys-process/vixie-cron (4.1-r12): Paul Vixie's cron daemon, a
fully featured crond implementation
2) sys-process/bcron (0.09): A new cron system designed with
secure operations in mind by Bruce Guenter
3) sys-process/cronie (1.4.8): Cronie is a standard UNIX daemon
cron based on the original vixie-cron.
4) sys-process/dcron (4.5): A cute little cron from Matt Dillon
5) sys-process/fcron (3.0.6-r1): A command scheduler with extended
capabilities over cron and anacron
 choice[1]:

*( list taken liberally from eix -c  )

Then the documentation could be updated to simply tell the user

  emerge --virtuals=pick-specified virtual/cron virtual/logger

And they could then just use the defaults ( by pressing enter ), or
choosing their favourite.

Also, perhaps "Virtuals" is a poor name for what mechanism I am
describing. There are potentially many things that want an elective
process like this on many packages, but it seems a mechanism more
prevalent in virtuals. Especially as this facility is mostly provided
by the "USE" mechanism in most other places.  However, in VIRTUALS
where you have a list of mutually exclusive alternates, a long list of
USE flags with one of them defaulted via IUSE seems bad.  Not to
mention, the mechanism for displaying what each individual USE flag
will get you is a bit messy at present. ( Being, you have to invoke
some other portage command, and this requires you finding applicable
documentation for that command, to work out how to query what each
individual USE flag means , and then run a different command for each
package you want to consider to see its description )


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] euscan GSoC project - requesting feedback

[Kent Fredric]

On 27 June 2012 19:51, Federico "fox" Scrinzi  wrote:
> The main question is: what would you like to have on this dashboard?
> Currently (in the development version) there's the possibility to login
> and watch/unwatch packages/categories/herds/... and see the watched
> stuff in the account dashboard. We're planning on implementing a
> weekly(?) custom newsletter based on the packages you're watching, which
> features would you like?
>
> The project repo for the GSoC is here: https://github.com/volpino/euscan
>
> Thanks!
>

For the most part it seems to get upstream / portage versioning right,
but occasionally you get miss-matches for some reason.

It would be nice to allow to provide some mapping mechanism that
existed on the overlay itself to inform euscan how to map upstream
versions to downstream ones, but implementing that would be far too
complex I feel.

Instead, it would be nice to have a mechanism in the interface to set
a "Upstream version is" value for each package if euscan can't tell.

Ie:

http://euscan.iksaif.net/package/dev-perl/HTML-TreeBuilder-LibXML/

Upstream is 0.71 , portage is ( normalised ) to 0.710.0 , and these
are in fact the same version. So in 0.710.0 , it would be nice to be
able to set the upstream version manually to 0.71 so that euscan no
longer reported it as outdated.

http://euscan.iksaif.net/package/dev-perl/Authen-SASL-Cyrus-server/

0.13 == 0.13-serve

http://euscan.iksaif.net/package/dev-perl/Module-Extract-Namespaces/

0.140.200_rc == 0.14_0.2

http://euscan.iksaif.net/package/dev-perl/Math-BaseCnv/
http://euscan.iksaif.net/package/dev-perl/XML-Tidy/

1.8 == 1.8.B59BrZ
1.8 == 1.8.B2AMvd

( Upstream for those 2 packages have a versioning scheme tantamount to
intolerable cruelty.
https://rt.cpan.org/Public/Bug/Display.html?id=60275 )

http://euscan.iksaif.net/package/dev-perl/Perl-Critic-Moose/
0.999.2_rc == 0.999._002

http://euscan.iksaif.net/package/dev-perl/aliased/
0.300.100_rc == 0.30_0.1

http://euscan.iksaif.net/package/dev-perl/EV/
4.110.0  == 4.11


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: euscan GSoC project - requesting feedback

[Kent Fredric]

On 29 June 2012 17:32, Duncan <1i5t5.dun...@cox.net> wrote:
>
> EUSCAN_VERSION=0.71
>
> I don't know how difficult that would be for euscan to pickup on, but
> since this would have no bearing on actual package behavior, only on
> euscan, I'd guess it shouldn't require going thru the formal PMS process,
> tho specifying it well enough to know whether it can be a function or
> must be a straight variable assignment, etc, as well as whether quotes
> are required or not, would be useful, and that's normally part of the PMS
> process so at least getting input from them would be useful.
>
> Alternatively, define some formula that can be placed in the package's
> metadata.xml.  That's perhaps a better functionality match (we're talking
> about metadata, after all), but getting a formula that can deal with all
> the corner-cases is likely to be more difficult (and take longer) than
> simply specifying a variable to be defined for each ebuild that euscan
> can't immediately get correct.

The problem is with this approach, some devs will want to set
EUSCAN_VERSION automagically using mangling $PV

As it is, we *already* have something equivalent to EUSCAN_VERSION for
things derived from perl-module.eclass, MODULE_VERSION=

Its not 1:1 identical to the intent of EUSCAN_VERSION, MODULE_VERSION
is only really required in the generation of SRC_URI , but because of
this, there is a loose MODULE_VERSION <-> distfile mapping, and a much
looser $PV <-> MODULE_VERSION association.

Sure, its fine for MODULE_VERSION to be made by mangling $PV, but the
problem is that the *reason* people mangle $PV to make MODULE_VERSION
is so they don't have to update MODULE_VERSION manually when bumping
the package.

Adding a non-bash non-$PV-manglable field EUSCAN_VERSION field will
possibly make manually incrementing this value a mandatory thing.

Not to mention, if it turns out to be "wrong" on the EUSCAN index,
some dev has to drop the change into the repository, do all the
manifest updating and commit signing and pushing it to CVS nonsense,
when really, its metadata only relevant to euscan, so its really in
the wrong place to start with.

Having it handled as an exception list on the euscan would be much
tidier, and the path from noticing the problem to solving the problem
becomes substantially shorter.



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] euscan GSoC project - requesting feedback

[Kent Fredric]

On 30 June 2012 00:13, Corentin Chary  wrote:

> It's already the case:
> https://github.com/iksaif/euscan/blob/master/pym/euscan/handlers/cpan.py
> but my mangling functions are probably broken in some cases. If
> somebody with a better knowledge of CPAN versionning scheme could fix
> them it would be great !
>
> Thanks,

The thing is there isn't a true versioning scheme for CPAN, just a
defacto one agreed upon by the community.  There are several
versioning schemes in employ, but the mechanics of each are rather
messy, and then  you have some lovely fellow like pip come along and
put garbage in their version, and we have to handle it manually.

For the most part though, people use "sensible" versions of a very few
basic varieties, and we downstream normalise these smattering of
varieties into a single form to make everything nice and tidy.  Its
still a work in progress migrating older ebuilds to our new
normalisation scheme, but its getting there.

And we do have a tool that will convert /most/ CPAN versions into
portage versions, which works as long as upstream are sane:

dev-perl/Gentoo-PerlMod-Version

Which relies on another perl module 'version.pm' (
virtual/perl-version ) which handles most the real dirty work of
normalising things, and we just do a bit of post-processing of that to
make it nicer for us ( mostly stripping leading 0's in digit groups,
and mapping the upstream 'developer release' hints ( ie: -TRIAL  or
_01 components ) to the _rc  suffix.

If you wanted to you could call that script, or delve into the guts of
it and version.pm and try understand how it works, but you could be
there a while.

But we're unfortunately going to *always* need a way to correct
versions, because upstream occasionally produce bogus nonsense
versions that don't even make sense. ( ie: making versions go
backwards and expect it to work, but it does, because the cpan indexer
takes whatever was most recently uploaded ... or something like that.
)


-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Feature Request/RFC : "Elective" virtuals

[Kent Fredric]

>
> Perhaps it would be best to tell users that if they'd like to see the
> possible choices they can run ie 'qdepends -r virtual/cron'
>

Quite, perhaps it could be a seperate mechanism, it would just seem
that for virtuals that just provide a list of alternatives, having a
seperate package that gives the *choice* of one of those alternatives
seems like redundant code. ( Most virtuals are simple non-exclusive
ors, so the packages that satisfy them can all be installed
simultaneously,  however, there are a few virtuals that are inherently
exclusive-ors, as all the dependents exclude each other )

Perhaps it could be an additional metafield, upon which the choice of
one of several choices could be presented to the user by using a
different tool.

All packages which have an "alternatives" mechanism like this could
then also be indexed and the user could then only enter the selection
process with a  separate tool which is a wrapper for portage.

I'm not sure if it makes sense or not to make it as an eselect
submodule that lets the user make choices and then have something else
apply them, or a dedicated tool; ie:

eselect alternatives list  # list all the "things" that have
dependents that are mutually exclusive choices
eselect alternatives set cron --auto # selects vixie-cron
eselect alternatives set cron cronie
emerge -uvatDN @changed_alternatives

Or something like that.

You could drive it of course using external metadata not bundled with
the virtual's themselves, the benefit being you avoid the need to trip
the whole change process for virtuals and stabilisation, but the
downside is of course possible desynchronisation of  choice metadata
with choices that are available via the virtual.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

[gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND

[Kent Fredric]

Firstly, we already have a ^^(  ) syntax for REQUIRED_USE , "one of,
but not more than one of".

However, to my knowledge, we don't have such for ebuilds.

Sure, there are ways of implementing this in ebuilds without this
notation, but they're a bit messy.

For instance, we seem to find the need for something like this in perl
virtuals,

|| (  =dev-lang/perl-$A  =perl-core/foo-$B )

However, this current form has its limitations:

1. If =perl-core/foo-$B  was previously installed, satisfying the
condition, and =dev-lang/perl-$A becomes installed, perl-core/foo-$B
then gets ignored, but its still left installed, and not cleaned.

2. Due to the nature of how perl works, any version installed from
perl-core/ will "shadow" the version installed by dev-lang/perl , so
that, despite the virtual being satisfied, the version of the code you
get is unsatisfactory from time to time. ie:

  dev-lang/perl-5.10  might provide  'quux-1.2.3'   , as will
perl-core/quux-1.2.3

If you were previously on perl-5.8 , ( which only shipped quux-1.1 ) ,
and had installed =virtual/perl-quux-1.2.2 ,  you would have to
install =perl-core/quux-1.2.2 to get "quux-1.2.2"

Along comes 5.10, and quux-1.2.3 , so we release   virtual/perl-quux-1.2.3

   || ( =dev-lang/perl-5.10  =perl-core/quux-1.2.3 )

^^ this does what we want most of the time, if you can install
perl-5.10, just do that to get quux 1.2.3, otherwise, install
quux-1.2.3 from perl-core .

However, in the above case, what happens is virtual/perl-quuux-1.2.3
is installed, which is satisfied by '=dev-lang/perl-5.10" , and
portage is happy with that.

And then you do 'perl -e 'use quux 1.2.3' # and it barfs saying 1.2.2
is still installed, which it is, because perl-core/quux-1.2.2 is still
installed, overshadowing the more recent one provided by dev-lang/perl

Ideally, what we want here is ^^(  ), or something like it, so that if
the earlier part is satisfied, latter parts are then removed.

You *can* represent the same logic with other mechanisms, but its much
much more complex to do so.

|| (
  (
=dev-lang/perl-5.10
!perl-core/quux-1.2.3
  )
  (
   !dev-lang/perl-5.10
   =perl-core/quux-1.2.3
  )
)

And I *think* that will do the right thing, I really have no idea.

The other approach of course is to make the blockers happen in
dev-lang/perl and perl-core/quux , but this has its own problems.

For instance, =dev-lang/perl *cannot* specify which versions of
perl-core/quux can and cannot be installed.  Because its not *perl*
that is trying to define what version is installed, but the virtual.

And perl-core/quux can't really block perl , because the whole point
of perl-core/quux is to be installed on perls other than the ones it
was shipped with.


^^(  ) seems to nicely help solve this problem, and it seems like an
oversight that we have OR , AND , and NOT  dependency rules, but not
XOR.

P.S. Blame Patrick for this message.

-- 
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] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND

[Kent Fredric]

On 3 July 2012 19:08, Ciaran McCreesh  wrote:
> On Tue, 3 Jul 2012 15:44:04 +1200
> Kent Fredric  wrote:
>> Firstly, we already have a ^^(  ) syntax for REQUIRED_USE , "one of,
>> but not more than one of".
>
> A user has a and b installed. c depends upon ^^ ( a b ). The user tries
> to install c. What happens?

I'd expect that the user would have to remove one of ( a b ), the
natural choice would be to remove b, a taking precedence.

> --
> Ciaran McCreesh



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )

[Kent Fredric]

On 3 July 2012 20:24, Michał Górny  wrote:
>
> --depclean?

eix Module-Metadata
[I] perl-core/Module-Metadata
 Available versions:  ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9<---
not unmasked by --autounmask
 Installed versions:  1.0.6(15:59:00 06/26/12)
 Homepage:http://search.cpan.org/dist/Module-Metadata/
 Description: Gather package and POD information from perl
module files

[I] virtual/perl-Module-Metadata
 Available versions:  ~1.0.3 ~1.0.4-r2 ~1.0.5 1.0.6 (~)1.0.9-r1
<- Unmasked by --autounmask
 Installed versions:  1.0.9-r1(09:37:51 07/02/12)
 Description: Virtual for Module-Metadata

perl-Module-Metadata-1.0.9.ebuild

   RDEPEND="|| ( =dev-lang/perl-5.16* ~perl-core/${PN#perl-}-${PV} )"

It appears yes, --depclean *will* reap perl-core/* in this scenario  (
portage 2.2.0_alpha114 )

Just I don't tend to use --depclean an awful lot. Usually, I don't
expect to have to use --depclean to avoid a somewhat "broken" system.

>
> Doesn't perl-cleaner handle perl upgrades for this? And the tested
> ABI_SLOTs should help with that too.

ABI_SLOT may be able to help, but the problem is that installing
perl-core/foo-1.0 on perl-5.10 which ships foo-2.0 , is 100% fine.

It will just shadow the 2.0 version with the 1.0 version, and assume
"that is what you want", while the virtual is trying to convey "That
is not what we want".

And perl-cleaner doesn't have any code to handle this scenario last I
checked.  You can't even work out what is the "right" installation
scenario without first knowing "what do installed packages want". If
"installed packages want version foo to be smaller than 2.0" then
perl-core/foo-1.0 being installed on perl-5.10 is "Fine" . For this,
they would depend on "
> This is a really fragile approach, and is mostly a workaround
> to the real issue. You want to say «I need *only* one of my
> dependencies satisfied» while you actually get «if I'm installed, then
> let every my dependency in those blocks actually block each other».
>
> That's just impossible to achieve. Think of ^^ ( foo bar ). When
> the package gets installed, foo is installed and bar is not. Then you
> want to emerge bar. What should happen?
>
> a) you want portage to refuse to do that. Why would it? AFAIU this
> would no longer be a problem actually.

Given

C = " ^^( a b )"  and you had "A and C" in your world, and you wanted
to install B, portage would tell you that to do that, you would have
to remove either A or C.  ( Yay, the communicative property of XOR :D
)

> b) you want portage to do that. But you just forced it unmerge it? It
> will install the previously made binary package and it's back...

I can't parse this statement. Sorry :/

> c) you want portage to unmerge foo because the dep will now be
> satisfied by bar. Wait... unmerge perl?

No, perl would never be removed, not unless the ^^( )  was simply

  "^^(  perl  foo )"

In practice, it would be "^^( =dev-lang/perl-5.16*  =foo-5.0 )" which
would  mean

a) remove foo
b) downgrade/upgrade dev-lang/perl

of course, I have noticed a fly in my ointment, in that this logic
would mean this blocker could be avoided by down/upgrading foo, which
is precisely what we want to avoid. So its back to the drawing board.


If we were to discard what we currently know about dependencies for a
moment, a dep spec of


perl-Foo-5.0:

   if ( =dev-lang/perl-5.10.0 ) {
 block versions of perl-core/Foo that are not 5.0
 # Because if somebody wants to install perl-core/Foo-5.0 in
perl-5.10 , thats fine, its pointless, but its fine
 # because perl-core/Foo-5.0 'provides'  Foo-5.0, as does
perl-5.10, so this is satisfactory behaviour
   } else {
install perl-core/Foo-5.0 and only perl-core/Foo-5.0
# Because something has stated that it "wants" Foo-5.0 for some reason,
# So we must deliver it at all costs. If its not shipped in
perl, then we provide it.
   }

It would be nice to be able to just say  "Fine, how about we just
always install from perl-core/".

Which hits the road block as soon as upstream release dev-lang/perl
with Foo-5.01 , and Foo-5.01 is not available on CPAN. ( Sometimes its
a 'dev' release, other times its not ) .

Better approaches welcome.

I have thought of scrapping the virtuals entirely and handling it so
that things depend on perl-core/* instead, and perl-core can just
dynamically decide at install time whether or not it needs to no-op (
and sometimes perl-core/* will need to hard depend on perl and just
install nothing ).

This seems a simpler approach until you consider the problem of "How
do we determine dependencies for this ebuild".

Messy. :/

With API_SLOTS I guess we can (maybe) have api-slot conditional
SRC_URI and DEPEND values,

# Not real code, just pesudocode
SRC_URI=" ! API-Perl-5.10 ? ( . ) "

DEPEND=" ! API-Perl-5.10 ? ( . ) "

Or some shit like that.

If we're really really keen, we might be able to throw it together
with some USE_EX

Re: Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )

[Kent Fredric]

On 4 July 2012 02:16, Michał Górny  wrote:
>> I have thought of scrapping the virtuals entirely and handling it so
>> that things depend on perl-core/* instead, and perl-core can just
>> dynamically decide at install time whether or not it needs to no-op (
>> and sometimes perl-core/* will need to hard depend on perl and just
>> install nothing ).
>>
>> This seems a simpler approach until you consider the problem of "How
>> do we determine dependencies for this ebuild".
>
> Do you actually need to do that? All those ebuilds will depend on perl
> with minimal version number necessary for the package to build.
>
> If perl is older, the package will be built normally. If perl is newer,
> the package will install a no-op. It's fine unless you consider
> downgrading perl. But thinking about it... any upgrade or downgrade of
> perl breaks all the modules anyway.

The problem occurs in a few edge cases, which, fortunately don't
happen often. Usually its when packages appear as new additions to
dev-lang/perl.

ie: When AAA is added to perl, on perls older than 5.something
have to install all of AA's deps . ( Which are ussually provided
by perl anyway, so its not a problem ). But if *2* things are added
between perl releases and one depends on the other, ie: AAA and BBB
are added to perl 20,  installing them on perl 15 will require you to
install BBB before installing AAA.

Granted I can't think of any modules that do exactly this off the top
of my head, but its something to think about.  ( Perhaps some things
like CPANPLUS and other things that are miles ahead of the perl
verision and have external deps ), but fair to say, I think a module
that can

a) sometimes install code from CPAN

but

b) has no DEPENDS on other perl modules ( because you want to have no
depends if it is going to just no-op )

Is a recipe for disaster.

And the more I think about doing it with USE_EXPAND/USE flags with
1-flag-perl-perl-version[1] the more It feels like it would be a
bigger nightmare than what we're currently doing. What we're doing
works atm, just it has the annoying quirks that come up from time to
time, notably more around perl  releases, and these quirks slowdown
stabilizations.

*1 : ( though they've tended away from changing versions of  bundled
libs with maintenance releases these days so its not so much a visible
problem if we stick to the Majors, it can still happen that the
version of a module can change between releases, and somebody could
plausibly depend on the more recent of the 2 versions )

> If a newer perl provides the particular module, all its dependencies
> have to be satisfied in perl anyway. So it will just pull more
> 'virtuals'.
>
> --
> Best regards,
> Michał Górny



-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )

[Kent Fredric]

On 4 July 2012 02:16, Michał Górny  wrote:
> a) || ( a b ) should be || ( b a ), to actually state what perl does,

I don't really see how that would help much, if anything, I get the
impression that would

1) needlessly install "b" even when it could be satisfied by a instead
( ie: before both a & b  are installed )
2) be more inclined to keep a than it currently does
3) Probably not help in the situation I had above with

=perl-core/Module-Metadata-1.0.6  ( stable , 1.0.9 is masked by ~ still )
=virtual/perl-Module-Metadata-1.0.9( --autounmasked from ~ )
=dev-lang/perl-5.16.0  ( --autounmasked from ~ )


As after installing perl-5.16.0, the || (   )  is again satisfied,
rending the system somewhat broken, but having to wait for --depclean
before it comes right.

But I'm possibly wrong somewhere, I may have fundamentally
misunderstood how || (   ) works.

On 4 July 2012 02:16, Michał Górny  wrote:
> b) perl should be modified to work like our deps specify.

That's probably the most difficult task of all, I think you'd have to
shred modules out of perl and hand package them into perl-core/
packages for that, and then never install them as part of perl,
despite the fact some of perl won't even build without some of those
modules in its tree ( so you have to remove them during install ), and
thats the start of all sorts of fun bootstrapping things I wont touch
dipped head-to-toe in antiseptic.




-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND

[Kent Fredric]

On 4 July 2012 05:56, Ciaran McCreesh  wrote:
>
> But whether or not a and b can be installed together sounds an awful
> lot like a property of a and b, not of c.

Its just when C is really something abstract, ( a virtual ) provided
by both possibly a & b, and b doesn't know a even exists till after
the fact, and vice versa, that solving the problem in a & b becomes
messy.

If you solve it in one side ( in my example, perl-core ) you end up
having a lot of weird conditional logic trying to work out src_uri,
dependencies, and whether or not to actually do anything.

If you solve it on the other side ( in my example, dev-lang/perl ) ,
you end up having perl specify what versions of the abstract notion
can and cannot be installed, instead of the abstract notion specifying
what is *needed* and there is a resolution required to provide that.

if a package specifies : " =virtual-Foo-5.0 " , that means "I want the
Foo.pm version 5.0, I don't care how you get it, get it".

Only the virtual can convey *how* to get that.

ie: perhaps =virtual-Foo-5.0  can only be satisfied by installing
dev-lang/perl-5.10  ( its not in any other Perl, or on CPAN )
or perhaps =virtual-Foo-5.0 can be satisfied by installing
perl-core/Foo-5.0 on any perl

And there are dozens of packages that ask for "Foo-5.0" , and the only
other altnative we had before we had the virtual/perl-* family, was to
ignore the dependency entirely   and hope for the best, or depend on a
minimum perl we know had it ( which is a different minimum perl than
what upstream specifies, because upstream assume you can install
things from CPAN , and/or depend on the nearest match that *is*
available via perl-core/* , risking the possibility that it will
install a version from CPAN that is to become outdated by a future
perl release, but you'll keep installed anyway, giving the shadow
effect again.

Essentially, the problem at the bottom of this, is Perl Modules depend
on each other by components in distributions ( the modules ), not the
distributions themselves. Its merely convention that distributions
have a name and version that is the same of a module also contained in
that distribution.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] About forcing rebuilds of perl modules

[Kent Fredric]

On 1 July 2012 05:12, Ian Stakenvicius  wrote:
> Do all packages need to be rebuilt when some of these use flags
> change?  Maybe auto-appending those particular flags (ithreads, debug)
> to IUSE and putting them on the dev-lang/perl dep is all that'll be
> needed, if this is the case.


Not all packages need rebuilding, but *every* package with XS parts
need rebuilding, as code built with DEBUG/ITHREADS enabled will not
execute on perls with different DEBUG/ITHREADS options. ( And as a
preventative measure, they're installed in entirely different dirs )

 @INC:
/etc/perl
/usr/local/lib64/perl5/5.16.0/x86_64-linux   <- binary
/usr/local/lib64/perl5/5.16.0
/usr/lib64/perl5/vendor_perl/5.16.0/x86_64-linux  <-- binary
/usr/lib64/perl5/vendor_perl/5.16.0
/usr/lib64/perl5/5.16.0/x86_64-linux <-- binary
/usr/lib64/perl5/5.16.0
.

.

( At least, the dir name switching used to be a thing, I can't see it
in the code anymore so I could be wrong, I don't tend to twiddle those
USE flags often )

Also, it would appear that in some cases ( ie: dev-perl/Mouse ) , they
don't install any binary code , but the .pm files themselves are
installed into the x86_64-linux folder, which, if that path is removed
from @INC when you rebuild perl with different USE flags, will break
them, despite not having any binary code.

But either way, if "SlotABI" is supposed to convey "A change that can
occur to a package that means other packages that were built on it
need to be rebuilt" , then this is something we need.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] About tests needing internet connection to run

[Kent Fredric]

On 8 July 2012 00:38, Pacho Ramos  wrote:
> After reading:
> https://bugs.gentoo.org/show_bug.cgi?id=424719
> https://bugs.gentoo.org/show_bug.cgi?id=397973
>
> Looks like there is not consensus about how to handle this cases,
> probably a PROPERTIES variable for this would help :-/
>
> Any ideas on this kind of issue?

I've been handling it on the perl-experimental overlay by specifying
SRC_TEST="network"

SRC_TEST is a perl-module.eclass variable that controls weather or not
to run the packages inbuilt tests.

Its not anywhere in official capacity, but I think my approach is
sane-ish somewhat, just needs better native support in my opinion.

https://github.com/kentfredric/perl-experimental/blob/eclass-moretests/eclass/perl-module.eclass#L283

I think it would be nice to mask packages by their test failure
expectancy, for instance, mask packages that the tests are known to
fail on, or have tests turned on for all packages except packages
where failures are expected from tests. ( There are a few packages
which will always fail tests apparently, and it would be nice to
indicate as such in the ebuild ).

This way you can also probably opt for:
a) installing only packages which don't require network for their tests
b) only testing packages which don't require network for their tests

I've also thought it might be nice to have a way to enable testing
every time I install a ~amd64 package, instead of having a wide
spectrum "all or nothing" approach.





-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] euscan GSoC project - requesting feedback

[Kent Fredric]

On 10 July 2012 13:28, Jeroen Roovers  wrote:
> On Tue, 10 Jul 2012 00:04:15 +0200
> Agostino Sarubbo  wrote:
>
>> I proposed to have an 'integration' between euscan and pybugz.
>
> Sounds superficially like a giant security hole / spam gateway. What
> kind of integration are we talking about?
>
>> In this manner everyone can file a version bump request via euscan.
>> What do you think about?
>
> If the false positives go down significantly, we wouldn't need
> interested users to "report" version bumps - you could automate that
> all the way, and publish links to the bugs already reported.
>
> But couldn't we more simply and securely implement publishing a
> hyperlink from euscan's pages to the bugs.g.o form that fills out some
> of the required information in advance? That way it's everybody's
> personal bugzilla accounts that are responsible for the spam, and we
> might more easily find duplicates.
>
> Speaking of duplicates, the way subsequent version bump requests for
> subsequent versions (in different SLOTs, mind you) are usually treated
> now is that the later bugs are marked as duplicates of the former and
> that the former bug's Summary is updated to show the currently best
> version(s). If we're going to stick to that, we *definitely* need a way
> to catch out duplicates.
>

This is verging on that oft requested thing that Gentoo could do with,
a sort of task queue for regular and repeated tasks that can be
described in one line and aren't worthy of a full bug.

  ie:  Version Bumps, stabilisation requests, generic repeated
transformations ( ie: make the metadata better, etc )

Things that if they really needed a full blown bug could be
cross-linked with bugzilla, but wouldn't need be the default option.

Though, thats really an entirely different discussion, I'm just
teasing the subject so ideas brew and the discussion eventually turns
up.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] ROMs category suggestion

[Kent Fredric]

On 22 July 2012 16:12, Doug Goldstein  wrote:
> I've got a few ROMs to add to the tree and some which are already in
> the tree if people have a suggestion where they should live. Short
> list:
>
> ipxe
> openbios
> seabios
> sgabios
> vgabios
>
> --
> Doug Goldstein
>

I just noticed that the sys-firmware category has been added to the
categories file, but no corresponding directory in portage exists yet.

I understand this is a temporary thing, and the only thing that
notices that there is this discrepancy is software I've written (
https://metacpan.org/source/KENTNL/Gentoo-Overlay-1.0.2/lib/Gentoo/Overlay.pm#L135
).

It doesn't warrant the shenanigans of a full bug report,  ( And I have
no idea how one would categories this sort of bug ), just I dislike
the inconsistency of there being a directory listed in the categories
file without also having that directory in existence.

( This bug is really all CVS's fault, the directory is created, but
its empty -> marked as dead )


In short, "Yay, thanks for sys-firmware, I look forward to it not
being an empty category"

Just I would have hoped that this category hadn't been created until
there was something ready to put in it =)

-- 
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] ROMs category suggestion

[Kent Fredric]

On 23 July 2012 08:48, Rick "Zero_Chaos" Farina  wrote:
> A fair point, suggestion retracted.  I'm on board with sys-firmware as
> well, but I do see some advantage of the current way of putting the
> firmware in the category of what it is for...

If you wanted, you could do something like x11-drivers/ do , and have
a standard of adding a little subcategorization:

 sys-firmware/video-ati

Or something of that sort. You'd be having to sacrifice downstream
package name not being identical to upstream though. But Lots of the
ones I  see listed could be generalised like that.

See, translate this into the new scheme:

media-sound/alsa-firmware
media-tv/cx18-firmware
media-tv/ivtv-firmware
media-tv/linuxtv-dvb-firmware
media-video/isight-firmware-tools
net-dialup/isdn-firmware
net-wireless/acx-firmware
net-wireless/ar9271-firmware
net-wireless/atmel-firmware
net-wireless/b43-firmware
net-wireless/bluez-firmware
net-wireless/ipw2100-firmware
net-wireless/ipw2200-firmware
net-wireless/libertas-firmware
net-wireless/linux-wlan-ng-firmware
net-wireless/prism54-firmware
net-wireless/rt2860-firmware
net-wireless/rt2870-firmware

sys-firmware/sound-alsa
sys-firmware/tv-cx18
sys-firmware/tv-ivtv
sys-firmware/tv-linuxtv-dvb
sys-firmware/video-isight-tools
sys-firmware/dialup-isdn
sys-firmware/wireless-acx
sys-firmware/wireless-ar927

... etc.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

Re: [gentoo-dev] Re: ROMs category suggestion

[Kent Fredric]

On 26 July 2012 19:32, Michał Górny  wrote:
> But you are aware that this is *upstream* naming?
>
> Similarly, ati-drivers (which is not upstream naming :P)
> and nvidia-drivers don't follow the suite.

I wasn't aware of that, but thats beside the point I was trying to
make. Its just a mechanism that allows an appoximation of a 3-tier
system without needing a 3-teir system.

ie:  sys-firmware/video/ati   approximated as sys-firmware/video-ati ,
which seems slighly better than the competing ways of doing it like:

firmware-video/ati-firmware
firmware-video/ati

and any category name with "Firmware" in it, will result in lots of
redundant names exposed to users/deps if the package /also/  has
firmware in the name.

There's also the other thing to consider, and thats there's a lot of
hardware related stuff that is similar to firmware in a way, but also
totally devoid of a central category for it. Namely, kernel level
drivers. ( Which are not /that/ far removed from firmware, considering
that you can compile firmware into kernels and they're of similar
levels of necessity ).

We may as well suggest sys-hardware/and put things like tp_smapi
and prism54-firmware all in that one category.

In essence, the rationale behind having a sys-firmware category for
all firmware, but no sys-drivers category for all device
drivers/modules seems an oversight.


But I think however you do it, the absence of a 3-tier system hamstrings you.

net-wireless/prism54-firmware   ->
Alternatives:
  sys-firmware/prism54-firmware
  sys-firmware/prism54
  sys-firmware/wireless-prism54-firmware
  sys-firmware/wireless-prism54
  firmware-wireless/prism54-firmware
  firmware-wireless/prism54
  sys-hardware/prism54-firmware
  sys-hardware/wireless-prism54-firmware
  hardware-wireless/prism54-firmware


net-dialup/hsfmodem ->
   Alternatives:
  sys-driver/hsfmodem
  sys-driver/dialup-hsfmodem
  sys-hardware/hsfmodem
  sys-hardware/dialup-hsfmodem
  hardware-dialup/hfsmodem


The perk of *not* having 'firmware' in the category name means you can
put drivers in the category as-is, and add firmware to the category
as-is, without needing to have redundant information. In a
sys-hardware/* hardware-$class/*  layout, things without "-firmware"
are assumed kernel drivers , and things with -firmware are known as
firmware.


-- 
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] UTF-8 locale by default

[Kent Fredric]

On 31 July 2012 05:33, Michael Orlitzky  wrote:
> On 07/30/12 12:28, Michał Górny wrote:
>>
>> My point here is that you want the thing to change. So you first try to
>> convince people here to change. We practically did a small survey here
>> and in the result we didn't agree on doing the change.
>>
>> So you're saying we should do another survey on another group, hoping
>> that this time the result will be on your side.
>
> We didn't do a survey, we asked,
>
>   "Is there a reason for not using at least en_US.UTF-8 as a "sane"
>default value?"
>
> Unsurprisingly, the responses contained reasons for not using
> en_US.UTF-8 as the default.
>

I think its a shame that :

1. the current handbook way to change timezone is manually editing a file.
2. the handbook doesn't mention `eselect locale`
3. `eselect locale list` is useless if you have *all* locales available to you.
4. `eselect locale` can only set the LANG variable.
5. that eselect doesn't have an interactive mode yet.

Why? because this problem could be made simpler by providing a way to
use a recommended locale for your timezone, which is likely to yield a
more sane default for that timezone.

It would also make it easier to validate the value the user chooses
for their Timezone value.

Consider:

eselect timezone list
 # all level 1 timezones + groups , ie: like ls /usr/share/zoneinfo
eselect timezone list  America/
# contents of /usr/share/zoneinfo/America
eselect timezone set America/Chicago
# /etc/timezone is updated to  'America/Chicago'
# /etc/localtime is replaced with /usr/share/zoneinfo/America/Chicago
eselect locale set --all auto
# LANG and LC_* are set using the values defined as "default" for
America/Chicago
eselect locale set --ctype auto
# Only LC_CTYPE is autopopulated.
eselect locale list
# 600 items because you have a vanilla locale.defs
eselect locale list --timezone
# shows a list of LOCALE values for the current TZ, with the one that
would be used as default first/marked up differently
eselect locale list en
# shows english locale options
eselect locale set --ctype en_US.utf8


The benefits of setting these locales this way are obvious to me at
least, you can set locales to a value that is sensible automatically.
You also can validate a users choice of locale and provide feedback,
such as, you can list non-installed locales, and then tell the user if
thy try to use a locale that isn't installed yet they need to update
locales.def

The only way I can suggest something better, would be an interactive
locale setter, something like 'tzselect' , except sets timezone *and*
locale information, with the ability to automatically update
locales.def and add new locale definitions and regenerate the locale
database.

This way, you could have a selection process more like this:

https://gist.github.com/3240866

#? 1

The following information has been given:

United States
Eastern Time

Therefore TZ='America/New_York' will be used.
Local time is now: Thu Aug 2 17:33:17 EDT 2012.
Universal Time is now: Thu Aug 2 21:33:17 UTC 2012.
Is the above information OK?
1) Yes
2) No
#? 1
Your Current locale settings are:

LANG="POSIX"

The recommended settings for your locale are :
LANG="en_US.utf8"
LC_CTYPE="en_US.utf8"

Do you wish to change your locale settings at this time?
1) No
2) Yes - Use recommended settings
3) Yes - Configure locale interactively.

At least this way, the effort required to configure your system into a
very good logical UTF8 default is trivial.

-- 
Kent

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

http://kent-fredric.fox.geek.nz

[gentoo-dev] eutils.eclass / EPATCH_EXCLUDE defined wrong?

[Kent Fredric]

I was goofing around trying to get current dev-vcs/git- building
by skipping the CVS patch ( which is applied with epatch ) and I had a
bizzare amount of time working out how to get it working.

Looking at the source of eutils.eclass '  # Let people filter things
dynamically ' suggests to me that this field is for use by a end user
via package.env and friends.

However, every time I ran emerge, the 'environment' file simply
suggests that EPATCH_EXCLUDE was ="" .

Looking elsewhere in eutils.eclass, I spied a forced initialization of
EPATCH_EXCLUDE, which implicitly means you can't actually use this to
exclude patches outside .ebuild

Commenting this line out, yielded the result I had been expecting, the
CVS patch being skipped .

I only thought I could  do this because I used something like this
once upon a time with net-im/psi- and thought it was just "normal"
to be able to disable patches if I really wanted to. ( But I see now
they acheive this by copying MY_EPATCH_EXCLUDE to EPATCH_EXCLUDE in
the .ebuild ).

So, is this variable guarded against user tampering intentionally? It
sure beats hacking the ebuild.

( Side note, what would also be nice is some sort of warning if things
you set in package.env are getting totally ignored. But thats a hard
problem )

-- 
Kent

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

http://kent-fredric.fox.geek.nz