gmane.linux.gentoo.devel

Re: Re: lastpipe

Samuli Suominen — 2012-05-26T07:50:52

(Unrelated.)

Please disable HTML from your mail client when posting to Mailing List(s)

Thanks,
Samuli

Re: anybody interested in writing a Perl ebuild?

Grant — 2012-05-26T07:21:11

I just used 'g-cpan -u' to update my g-cpan ebuilds and it generated
ebuilds in /usr/local/portage/dev-perl for a whole lot of different
perl modules that I've never installed.  Has anyone seen this before?
Is 'g-cpan -u' the best way to update your g-cpan ebuilds?

- Grant

Re: Re: anybody interested in writing a Perl ebuild?

Grant — 2012-05-26T07:14:39

Good call, thanks Duncan.  I'll set that up if I ever feel like I need
to know which perl ebuilds came from g-cpan.  Right now all of my
local dev-perl stuff comes g-cpan.

- Grant

Re: anybody interested in writing a Perl ebuild?

Duncan — 2012-05-26T06:52:08

Grant posted on Fri, 25 May 2012 23:01:42 -0700 as excerpted:



Not a perl-head, but if I've been following the thread correctly...

If you manage the overlays correctly (see the earlier note about it using 
the last one in the list), you'll know based on what overlay the ebuild 
is from.  Simply create an overlay specifically for g-cpan and make it 
last in the list.

Simple enough, assuming I'm not horribly mixed up, anyway. =:^)

Re: anybody interested in writing a Perl ebuild?

Grant — 2012-05-26T06:01:42

I was thinking it would be nice to know which ebuilds came from
g-cpan, but now that I think about it I suppose it doesn't really
matter.

Thanks a lot for your help!

- Grant

Re: Re: review required by herd? (new ebuild)

Mike Frysinger — 2012-05-26T03:34:44

what Ryan said
-mike

Re: review required by herd? (new ebuild)

Ryan Hill — 2012-05-26T03:23:30

On Sat, 26 May 2012 02:33:06 +0200
hasufell <hasufell< at >gentoo.org> wrote:


It's not a requirement, except when it is.  :)

Some projects are territorial.  Games is one.  I imagine adding something
to kde, gnome, or xfce categories without contacting those guys would get you
an email.  If in doubt I usually file a bug when I'm adding a package and CC
them.  If they don't respond, I add it.

So there is no general requirement to get a review unless the project in
question has said otherwise.  When in doubt, ask.


PS. herds are groups of packages.  think sheep.  teams/projects manage
the herds.

Re: comprehensive eclass checking in repoman

Ryan Hill — 2012-05-26T03:13:04

Yeah that works.

Re: lastpipe

Dan Douglas — 2012-05-26T01:56:35

Right, performance is just a nice side-effect. It makes a number of things 
cleaner (especially if the printf in that case were replaced with something 
more complicated), and is more intuitive for beginners .

However, all involved code needs to be able to expect lastpipe to always be 
either one way or the other, not mix-and-match. This means either EAPI 6 
requires Bash 4.2, or if Bash version detection is involved, a lot of the 
benefit to lastpipe is lost. Code which can't predict the behavior has to be 
written not only as though lastpipe were disabled, but also to account for the 
possility that it is enabled to avoid name conflicts.

In that example it would mean adding an explicit subshell, or saving and 
restoring the value of "line" before/after, or putting it into a function and 
using locals, or always making sure code executed after the loop initializes 
"line" to a known state.

Re: lastpipe

Mike Frysinger — 2012-05-26T00:52:00

i don't think speed is the main motivator, but rather avoiding behavior that 
bites new people all the time:
count=0
printf '%s\n' a b c | \
while read line ; do
: $(( count++ ))
done
echo $count

w/out lastpipe, that shows 0.  w/lastpipe, that shows 3.
-mike

review required by herd? (new ebuild)

hasufell — 2012-05-26T00:33:06

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Due to bug https://bugs.gentoo.org/show_bug.cgi?id=417117
it seems the situation on this topic is unclear.

I myself don't have a problem with getting my ebuilds reviewed if the
herd requires that before I commit them and have done this already a
few times.

More eyes/maintainers means higher quality IMO.

However I didn't get a definite answer if it's actually a REQUIREMENT
to get a review by a herd, especially when you do not plan to add that
herd to metadata.xml and plan to maintain the ebuild on your own.

This seems to be especially controversial regarding games in the main
tree (I myself always join #gentoo-games anyway and discuss the
ebuilds there).

What's the official policy, so everyone can be clear about this?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPwCTCAAoJEFpvPKfnPDWz+ZUIAJuZvONQkoVHAFC+HPEdMnui
/HTcNQC04RaS3TGHo3AdNRyYczTOfK0IjtMsktL+TcKlNgXRS

Re: lastpipe

Dan Douglas — 2012-05-26T00:11:35

Ah didn't know that. That's a solution for ebuilds anyway. How about for eclasses and user bashrc files? Does whatever EAPI setting is in effect for a particular ebuild apply to them? It isn't really worth toggling it on and off for individual files or functions in order to not break certain eclasses that conflict.


That point was reached when someone decided a custom Bash parser just for ebuilds was necessary. :)

Re: lastpipe

Ciaran McCreesh — 2012-05-25T22:33:43

On Fri, 25 May 2012 15:02:32 -0500
Dan Douglas <ormaaj< at >gmail.com> wrote:

We'll be able to turn that on in a controlled way in EAPI 6. Having
said that, if we're reaching the point where speed of bash code is
at all relevant, then ebuilds are doing something wrong...

Re: lastpipe

Katie Toreg — 2012-05-25T21:05:37

I like it. There would be plenty of time for migration considering the 4.2
requirement. Unfortunately, writing a QA check for violations would be
nearly impossible.

lastpipe

Dan Douglas — 2012-05-25T20:02:32

As many are probably aware, Bash 4.2 adds a shopt feature to enable not 
running the last command of a pipeline in a subshell (POSIX leaves it up to 
the shell to decide). Aside from being a slight optimization, it allows some 
syntactic convenience such as reduced reliance upon process substitutions and 
redundant command grouping workarounds. I believe it is generally considered 
that the lastpipe behavior is superior. zsh and ksh do this by default, while 
mksh, bash, and dash do not. Only Bash has it as a configurable option.

If it were made a policy now that ebuilds and eclasses cannot depend upon the 
subshell (for example, to set temporary positional parameters or isolate 
temporary variables), then maybe someday in the distant future this could be 
made the default, and in the meantime, an option for those with new enough 
shells. Since dependence on the subshell isn't very common, I think this 
should be feasible, and of course as a workaround all that's required is to 
wrap any such commands in pa

new qa warning: append-flags will complain about preprocessor flags

Mike Frysinger — 2012-05-25T19:04:23

preprocessor flags (e.g. -I and -D) should be added via `append-cppflags`, and 
build systems should be respecting ${CPPFLAGS}.  to enforce this a bit better, 
i'll be adding a qawarning to append-flags when it encounters flags that should 
be passed to append-cppflags.
-mike

Re: Re: Re: comprehensive eclass checking in repoman

Mike Frysinger — 2012-05-25T19:02:57

no.  while generating the manpages, the script will warn you bad comment 
blocks or unknown keywords.

$ cd /usr/portage
$ ./app-portage/eclass-manpages/files/eclass-to-manpage.sh \
eclass/*.eclass
...
alternatives.eclass:
   warning:41: alternatives.eclass: no < at >MAINTAINER found
...
gnuconfig.eclass:
   error:103: eclass not documented yet (no < at >ECLASS found)
...
leechcraft.eclass:
   warning:12: Unexpected tag in "funcvar" state: # < at >DESCRIPTION:
...
-mike

Re: Re: comprehensive eclass checking in repoman

Steven J Long — 2012-05-25T18:38:34

++ That sounds like a clean solution to me.


So, if eclass-manpages /is/ installed, then it gets used to check the 
documentation by repoman?

Why not just make it a required dependency, so it's "a new feature"? It may 
well be that people just don't know about it, and would welcome repoman a 
reminder to update eclass documentation (eg hard error if they added the 
function, overrideable error if they've edited the eclass, and warning if 
they are just using it, latter two of which could perhaps talk to pybugz.)

After all, it's their name on the commit.

Regards,
Steve.

Re: Re: comprehensive eclass checking in repoman

Mike Frysinger — 2012-05-25T16:28:23

no ... that sort of defeats the whole reason that drove this work.  we don't 
want the mere fact that one eclass inherits another to imply that it's part of 
that eclasses guaranteed API.  a lot of eclasses inherit eutils, but i don't 
think any of them should be guaranteeing that inherit which means ebuilds need 
to include it themselves if they use functions from it (like epatch).

there are a cases with split up or hierarchical eclasses (java, mysql, qt, 
php, python, xorg come to mind) where the entry point might vary, but they all 
share core eclasses that largely should not be inherited by the end ebuild.

maybe a new eclass-level keyword < at >INHERITED-API ?  it takes a space delimited 
list of eclasses that are guaranteed by the API.  so in distutils.eclass, we'd  
add:
# < at >INHERITED-API: python

and repoman would use this to build a tree of implicit funcs to allow w/out a 
direct inherit.
-mike

Re: Re: comprehensive eclass checking in repoman

Alexey Shvetsov — 2012-05-25T16:06:49

Mike Frysinger писал 2012-05-25 19:42:

May we can use eclass dep graph?

Re: Re: comprehensive eclass checking in repoman

Mike Frysinger — 2012-05-25T15:42:10

i was thinking of extending the metadata to handle this.  did you have any 
specific ideas in mind ?  i can see inheriting say distutils should not require 
people to also inherit python eclasses ...
-mike