Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses

[David Leverton]

On Friday 14 March 2008 07:14:23 Rémi Cardona wrote:
>   - the gnome2 eclass now has a pkg_preinst, if you do multiple
> inherits, make sure that gnome2_pkg_preinst is called too. The
> _games_eclass_ is one of those.

Maybe worth adding a dummy to the current version of the eclass so that 
ebuilds can be updated now, instead of suddenly all at once as soon as the 
new eclass is committed?

>   - if you use functions from the gnome2-utils.eclass, things may not
> work as expected. The _xfce_eclasses_ are on that list.

Are you referring to the need to call gnome2_gconf_savelist in pkg_preinst if 
the ebuild/eclass wants to use the gconf functions?  What I said above goes 
here as well.

A couple of things that aren't specific to the new eclass, but I noticed them 
while checking:

> #gnome2_pkg_prerm() {
> #   gnome2_gconf_uninstall
> #}

Should this really be commented out?  If so, might be worth adding a comment 
explaining why - it's not clear whether it's disabled because it's broken, or 
not necessary, or whether ebuilds are expected to call gnome2_gconf_uninstall 
explicitly if they need to.

> # Path to gconftool-2
> GCONFTOOL_BIN=${GCONFTOOL_BIN:="${ROOT}usr/bin/gconftool-2"}

> # Path to scrollkeeper-update
> 
SCROLLKEEPER_UPDATE_BIN=${SCROLLKEEPER_UPDATE_BIN:="${ROOT}usr/bin/scrollkeeper-update"}

Those aren't going to work with cross-compilation (which isn't well-supported 
by the current ebuild format, but best to be future-proof), since the 
executables in ${ROOT} won't be able to run on the build machine.

> export GCONF_CONFIG_SOURCE=$(${GCONFTOOL_BIN} --get-default-source)

I confess I don't know much about gconf, but that looks as though it'll always 
return a path in /, not ${ROOT}, so it'll install the schemas in the / 
database.
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses

[David Leverton]

On Friday 14 March 2008 12:14:39 Petteri Räty wrote:
> David Leverton kirjoitti:
> > Maybe worth adding a dummy to the current version of the eclass so that
> > ebuilds can be updated now, instead of suddenly all at once as soon as
> > the new eclass is committed?
>
> And break a bunch of ebuilds to stable users. No thanks.

Hmm?  I don't see how this would break anything... unless you mean that 
exporting the dummy function would overwrite one that actually does something 
important, but that's easily worked around by not exporting it until the 
ebuilds are fixed, as far as I can tell.  In any case, not doing anything 
until the new eclass is committed is going to break ebuilds until they're 
updated to call the new function, whether stable or ~arch.
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses

[David Leverton]

On Friday 14 March 2008 12:20:15 Rémi Cardona wrote:
> David Leverton a écrit :
> > Maybe worth adding a dummy to the current version of the eclass so that 
> > ebuilds can be updated now, instead of suddenly all at once as soon as the 
> > new eclass is committed?
>
> Good idea, I'll see what I can do there.

Just to be sure you saw my other message, be careful not to overwrite a useful 
pkg_preinst function defined in some other eclass, until the ebuilds are 
updated to call both.  It should be OK to not export it for now, until 
everything is fixed.

> > SCROLLKEEPER_UPDATE_BIN=${SCROLLKEEPER_UPDATE_BIN:="${ROOT}usr/bin/scroll
> >keeper-update"}
> >
> > Those aren't going to work with cross-compilation (which isn't
> > well-supported by the current ebuild format, but best to be
> > future-proof), since the executables in ${ROOT} won't be able to run on
> > the build machine.
>
> With Gnome 2.22 (app-text/rarian specifically), scrollkeeper-update is
> just a script (that's even just a no-op if I'm not mistaken). So all
> this scrollkeeper cruft will just become irrelevant as time goes on.

OK, but it's still an issue for gconftool-2 (I /think/ it should be OK to call 
the one in /, as long as you can persuade it to operate on the data in 
${ROOT}.

> >> export GCONF_CONFIG_SOURCE=$(${GCONFTOOL_BIN}
> >> --get-default-source)
> >
> > I confess I don't know much about gconf, but that looks as though it'll
> > always return a path in /, not ${ROOT}, so it'll install the schemas in
> > the / database.
>
> IIRC, the path returned in --get-default-source should contain $ROOT
> because gconf was installed using $ROOT. So it should be safe.

Again, maybe my lack of gconf knowledge is showing and I'm misunderstanding 
you, but using ${ROOT} to install a package shouldn't affect how it behaves 
at runtime (since you can build a binpkg and install it multiple times to 
different ${ROOT}s).  What happens if you enter the chroot and run 
gconftool-2 --get-default-source there?  It should return just /etc, 
not /chroot/etc.

> So far, no one has complained :)

Well, it seems like the sort of thing that could easily go unnoticed.  Not 
many people are going to know or care if they have schemas installed for an 
application that they don't have in /, and I would think most applications 
would react gracefully if their schema is missing.

> Thanks a lot for your review.

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

Re: [gentoo-dev] escaping variables in sed expressions

[David Leverton]

On Tuesday 15 April 2008 12:14:57 Marijn Schouten (hkBst) wrote:
> There are several option to handle this. I could use a less common
> delimiter or I could escape it: ${D//_/\_} instead of ${D}. I could use a
> sed expression that doesn't suffer from this problem (thanks to dleverton):
>
> sed -ne '\_^prefix = /usr/local_!{p;d}' -e "iprefix = ${D}" -i Makefile

Just to clarify, I didn't think of escaping when I suggested this.  Escaping 
is probably cleaner, and certainly easier to understand.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?

[David Leverton]

On Friday 30 May 2008 13:22:15 Diego 'Flameeyes' Pettenò wrote:
> The only thing that can be broken by using --as-needed is code that
> assumes the order in calling the .init sections of a set of shared
> objects. Such an order is not only changed by --as-needed usage but by
> any other change in the loading mechanism. It is strictly related to
> glibc at this point as far as I can tell.

It's not just the order, it also breaks things that rely on the .init section 
being called at all to register themselves with the core application 
(with --as-needed, the .so doesn't get loaded in the first place, so it 
doesn't get a chance to run anything).

> It's interesting to note that Microsoft _did_ think of this problem when
> designing the .NET framework, and they answer is ensuring just that the
> static constructor will be called (right) before any static method or
> attribute is referenced and (right) before any object of the given class
> is istantiated. They don't get otherwise an absolute order in which
> static constructors are called.

That's /an/ answer, but it doesn't provide all the functionality that static 
objects in C++ have.
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?

[David Leverton]

On Friday 30 May 2008 17:29:49 Diego 'Flameeyes' Pettenò wrote:
> This really is backward, solution-wise: you expect the "core
> application" to know enough of the plugins to link them together, but
> not enough to call their init functions...

Why should it call their init functions, when a static object with a 
constructor can do the job just fine?
--
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] RFC: --as-needed to default LDFLAGS (Was: RFC: Should preserve-libs be enabled by default?)

[David Leverton]

On Saturday 31 May 2008 11:14:33 Luca Barbato wrote:
> Ciaran McCreesh wrote:
> > Fact: the underlying issue is a libtool bug.
>
> Wrong, it isn't just that, --as-needed and libtool are unrelated.

The issue that as-needed tries to solve is libraries being linked to binaries 
or other libraries that don't use said library directly.  While it's true 
that libtool isn't the only cause, it does produce by far the most.

> > Fact: as-needed does not fix this bug. It attempts to work around it.
>
> Wrong, --as-needed does exactly what is supposed to do, precise
> bookkeeping.

It does do what it's supposed to do, unfortunately "what it's supposed to do" 
isn't the right thing in all cases.  And it's not "precise", it simply uses a 
different criterion that's better in some cases and worse in others.

> > Fact: as-needed breaks standard-compliant code.
>
> Wrong, --as-needed breaks disputable code that happens to be
> standard-compliant by a specific read of the standard. The fact the
> specific code is something wrong from the security/style/maintainability
> point makes it a bonus.

No-one's given any reason why it's "disputable", worse "style" or 
less "maintainable", other than "it doesn't work with --as-needed", quite a 
circular argument.  As for "security"... please show evidence, or I'll have 
to assume that that's just desperate FUD.

> > Fact: fixing the libtool bug would give all the benefits purportedly
> > given by using as-needed, without the drawbacks.
>
> Wrong, fixing libtool gives other benefits, so it's worth trying to fix
> it as well. The new autotools and proper usage of them makes life easier
> so it's worth improving on this side.

I really don't see what you're trying to say there
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Lastriting dev-libs/libffi (replaced by USE libffi in gcc itself)

[David Leverton]

On Thursday 05 June 2008 19:21:24 Albert Zeyer wrote:
> Are you sure that Squeak really depends on libffi?
>
> I just compiled it (squeak-3.9.7) fine without having libffi on my
> system and with disabled libffi USE-flag.

According to my reading of the code, it doesn't use libffi on x86-linux, 
ppc-linux and ppc-darwin, but does on all other platforms.  In any case, it 
should be fine with the libffi in gcc, it's just a case of the maintainer 
finding time to update the ebuild.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Monday 09 June 2008 11:28:03 Josh Saddler wrote:
> Let's change all that hideous, barely readable multiple brace/bracket
> abuse into something more human-readable, shall we?

Please explain why angle brackets are readable but braces aren't.

> 
> bunch o'neat code
> 

Wow, you mean we just type in "bunch o'neat code" and the GuideXML processor 
magically figures out what we want and does it?  That's amazing, you've 
really convinced me!  I'm sure we'll have this checked into the repo in no 
time.

> Thanks for playing; you lose.

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

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

[David Leverton]

On Wednesday 11 June 2008 12:11:33 Brian Harring wrote:
> Effectively, we've watched it essentially progress into a standard
> that effectively only the paludis folk are adherent to (if in doubt,
> ask portage folk, my sending this mail is indicative of the pkgcore
> standpoint)- it's about time the council comment upon it in light of
> the general view.

Paludis isn't completely compliant either.  Not sure what you're referring to 
about portage and pkgcore... if you mean kdebuild, then a) the Council has 
decided that that won't be part of the official approved version, and b) PMS 
only describes what kdebuild is, it doesn't say that any package manager has 
to implement it.  As long as it's not being used in the main tree, that's up 
to the package manager maintainers, and what they think is most beneficial to 
their users.

If you mean something else, feel free to file bugs, it could well be just an 
oversight.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Wednesday 11 June 2008 14:20:55 Luca Barbato wrote:
> Bernd Steinhauser wrote:
> > And that wasn't the point. He pointed out, that there is an issue, that
> > hasn't been caught because of missing tests.
>
> That may or may not exist

Since at least one ebuild has already been modified specifically to work 
around the bug, I'd say it's pretty real.

> > It really doesn't matter how it is specified. You have an implementation
> > of it and should make sure, that this implementation works.
>
> Seems to works well enough for people using it.

Unfortunately, that's not really saying much.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
> David Leverton <[EMAIL PROTECTED]> wrote:
> > Since at least one ebuild has already been modified specifically to
> > work around the bug, I'd say it's pretty real.
>
> For those of us trying to play along at home, which one is this?

http://tinyurl.com/4w4t69
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 12 June 2008 08:36:18 Markus Ullmann wrote:
> After investing more than two hours to just read the Mails that popped
> up yesterday regarding this stuff, I'd say we can't really take this
> serious. The PMS maintainers were withholding information on
> compatibility issues they've seen.
> As such we can't be sure this will pop up again in the future and so I
> strongly suggest dismissing this as something official for gentoo.

Ciaran already explained about that, but even if you don't agree with the 
reasoning, that's no reason to shut down a project that will benefit Gentoo 
as a whole.

If you have a problem with the content of PMS, then as I already said, please 
file bugs or send patches.  As the history shows, we are willing to change 
Paludis and PMS to match Portage behaviour, when we become aware of any 
discrepancies.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 12 June 2008 18:14:21 Mike Frysinger wrote:
> he was told to remove kdebuild-1 from the repo and this has yet to happen

I just checked the April meeting log, and while I admit I didn't read every 
word from start to finish, all I could see was that kdebuild couldn't be in 
the final, official version.  In particular, you yourself wrote:

22:36  i generate the pms for reference.  it better not include 
anything that hasnt been approved.

It looks like that isn't the default in current git, but it's trivial to fix 
if that's what people want.

If I missed something in the log, or if this was discussed somewhere else, 
please let me know.

> TeX isnt a format that integrates with Gentoo.  should just convert it to
> docbook and be done with this garbage.

I would think that anyone proposing such a disruptive change at this point 
should either give a damn good reason or do the work themselves, preferably 
both.  I can't even figure out what "integrates with Gentoo" means, let alone 
decide whether it counts as "damn good".  (And if you're suggesting DocBook 
as an alternative, it can't possibly mean "is the same as all the other 
Gentoo documentation".)
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 12 June 2008 22:21:48 Wernfried Haas wrote:
> Agreed, if this is the way PMS is done, we should either get rid of it
> or do it differently.
> The current status as presented here is inacceptable.

Could someone please explain what's wrong with PMS, other than "needs moar 
XML" and "I hate the people doing it"?
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

2008/6/13 Duncan <[EMAIL PROTECTED]>:
> In this instance, it's the "pulling teeth" to get info on a claimed known
> bug from PMS folks on pkgcore, while at the same time, complaints about
> the non-clarity of PMS is met with remarks (by the same group of people)
> of (paraphrased) "filed a patch yet?"

In the case of the pkgcore bug, there was an objective statement of
the fact that a bug existed, including simple instructions for
reproducing it (which were dismissed by a certain person claiming he
had already done so and found no bug  - clearly a lie).  In the case
of PMS, we have vague ad-hominems - not even "complaints about the
non-clarity", which in any case would be highly subjective, but just a
shrill "inacceptable".

> The problem is that this hasn't been the only case.  There's a pattern.
> It /frequently/ takes a day or two's worth of mails to get any decent
> info out of this paludis/PMS lead, with him claiming it should be
> obvious, but it's not, and while even the slightest criticism the other
> way is met with filed a patch yet?

The pkgcore was (or should have been) highly obvious to anyone who had
so much glanced at the offending code.

> It's not just pkgcore either, it's two of the three current PMs having
> problems, with the "One True Way" that everyone with any sense must
> /surely/ see is superior (or so it seems the thought is) gets filed a bug
> (or patch) yet if met with any criticism as well, from the same folks
> that it's like pulling teeth from to get any info from them.

I can't even parse this sentence.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Friday 13 June 2008 03:20:23 Brian Harring wrote:
> 1) http://bugs.gentoo.org/show_bug.cgi?id=171291
> metadata/cache (hence labeled flat_list cache format) mtime
> requirements.

The current spec attempts to handle things as well as possible on the package 
manager side.  If you'd like it to be restricted more, then please provide 
precise details along with reasoning.

> 2) http://bugs.gentoo.org/show_bug.cgi?id=196561; changing (within
> eapi0) the behaviour of ~ operator.  Currently, portage ignores any
> revision for ~, pkgcore gives the finger if you try combining ~ with a
> revision (it's not a valid atom), paludis follows the PMS rules;

As the bug says, there has been at least one ebuild in the past that appeared 
to expect the PMS behaviour, but it's gone now.  We can change the spec to 
match portage, but we'd like a repoman check to make sure people don't start 
doing it again.

> 3) good 'ole mr -r0 and the issues it triggers,
> http://bugs.gentoo.org/show_bug.cgi?id=215403
> initial dev thread,
> http://archives.gentoo.org/gentoo-dev/msg_de84ebd5116546518879e266bf60f32b.
>xml relevant flaws ignoring this issue induces:
> http://archives.gentoo.org/gentoo-dev/msg_f98bab69d67bd4132917be0eb04e8f3e.
>xml
>
> Spawned by a rather odd commit from rbrown flushing out a user visible
> breakage for pkgcore users, it also flushed out PM incompatibilities
> in handling of PVR/PR; specifically since -r0 has *never* been used in
> ebuild names, all ebuilds have been written assuming PVR lacks -r0.
> What was the end result of this rather obnoxious (ebuild dev viewable)
> variance?

I'm not quite sure exactly what you're requesting here... to ban -r0 entirely?  
I still don't see the point in doing that in the spec - tree policy, fine, 
but package managers have to deal with similar issues anyway in other parts 
of the version syntax.

If you want the description of PVR changed, then please file a new bug giving 
details, as Ciaran already asked.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Friday 13 June 2008 11:10:46 Nirbheek Chauhan wrote:
> Interesting to note, however, that Paludis doesn't accept inline
> comments, and this behaviour predates PMS.

There's a reason for Paludis not accepting them, and the same reason applies 
to the question of allowing them in PMS or not, therefore PMS doesn't allow 
them.  There's no evil conspiracy here, just pure logic.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Friday 13 June 2008 11:18:53 Nirbheek Chauhan wrote:
> Wait, what?
>
> "Where possible" ?

You'd prefer us to do impossible things too?

> PMS is supposed to be a specification which is as close to Gentoo's
> Official Package manager's behaviour as possible while (preferably)
> leaving out deprecated behaviour. But right now you're saying:
>
> "We're writing a spec that's somewhat like Portage, but where it
> breaks Paludis, we prefer to get Portage to change it's behaviour
> instead. Don't crib about this however. We could just have easily have
> created a whole new spec which broke Portage completely."
>

No, we're saying nothing of the sort.  Please feel free to browse the history 
and see where we've changed both Paludis and PMS to match Portage, when we 
become aware of differences - preferably before posting such nonsense in 
future.

> PS: An example of something in PMS that is different from Portage:
> inline comments are disallowed. The only reason I can think for doing
> this is to not make Paludis change it's behaviour.

Fortunately you don't have to think, you can just read Ciaran's explanation.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Friday 13 June 2008 11:23:29 Nirbheek Chauhan wrote:
> On Fri, Jun 13, 2008 at 3:49 PM, David Leverton
> > There's a reason for Paludis not accepting them, and the same reason
> > applies to the question of allowing them in PMS or not, therefore PMS
> > doesn't allow them.  There's no evil conspiracy here, just pure logic.
>
> Then I believe we would all like to know the reason why.

The same reason the Ciaran already explained in this very thread.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Sunday 15 June 2008 15:42:28 Peter Volkov wrote:
> For example, currently, PMS team does not include anybody from portage
> team - official PM team and thus this team can't represent Gentoo
> interests.

The Portage team is perfectly welcome to contribute if they wish.  zmedico is 
on the alias, although he seems to have been focussing on working on Portage 
itself.  genone, from what I've seen, seems to be indifferent at best to the 
idea of PMS.

I'm curious as to why you think the actively contributing members of the PMS 
team aren't acting in Gentoo's interests, though.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 19 June 2008 04:09:26 George Prowse wrote:
> In the end, PMS is just a way for them to spread their own agenda

Lies and FUD.

> maybe it would be best for all if paludis and it's developers were to
> concentrate on making paludis for a different distro. Trollix may be a
> good place to start... 

Oh look, speaking of agendas
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 19 June 2008 01:23:33 Chris Gianelloni wrote:
> Considering that the "most recent official release" is 2008.0_beta2, I
> don't see where you have a point, at all.

http://www.gentoo.org/proj/en/releng/#doc_chap5

"The latest release of Gentoo Linux is:

"Gentoo Linux 2007.0 for Alpha, AMD64, HPPA, IA64, MIPS, PPC, S390, SH, SPARC, 
and x86 architectures. "

2007.0 is also the first version listed at 
http://www.gentoo.org/main/en/where.xml

The point is to avoid breaking Portage versions that users might reasonably be 
using, even if only briefly.  Do you really expect /all/ users doing a new 
installation to choose the scary beta instead of the nice safe release?  
Perhaps we all know that the beta is better because it's so much more up to 
date.  Maybe it's even just as stable, if not more so (I wouldn't know, I 
haven't tried it).  But as long as it's labelled "beta", at least some people 
are going to avoid it in favour of 2007.0, and breaking the tree for those 
people such that they can't upgrade is unacceptable.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Packages broken by phase ordering change

[David Leverton]

On Thursday 19 June 2008 02:21:24 Chris Gianelloni wrote:
> It seems that everything these days is an EAPI scope change.

Everything change that has the potential to break existing packages, or to 
make new packages incompatible with existing package managers, is an EAPI 
scope change.  That is the very purpose of EAPI.

> Perhaps if you spent a little more time doing something more constructive
> than being an asshat on the lists, PMS would have been approved long ago.
> Of course, that doesn't mesh well with your apparent need to be a complete
> dick to people, so continue on with the status quo.

This thread was entirely technical until now.  Are such attacks really 
necessary?
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 19 June 2008 08:41:34 Luca Barbato wrote:
> > The point is to avoid breaking Portage versions that users might
> > reasonably be using, even if only briefly.  Do you really expect /all/
> > users doing a new installation to choose the scary beta instead of the
> > nice safe release?
>
> What about those who do not update since 1.0? how could they survive the
> havoc?

Is avoiding a beta version of something moderately important (like, say, 
installation media) really equivalent to not updating for over five years?

> Trying to make HUGE MONSTERS of little corner case is the favorite sport
> of Ciaranm and crew, be it a "beta" tag, an obscure feature some
> developers may like for tracking live sources (and the user should not
> use), possible fut{ure,ile} changes in the ebuild format.

Please take the ad hominems elsewhere. 
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 19 June 2008 08:44:41 Luca Barbato wrote:
> Chris Gianelloni wrote:
> > On Fri, 2008-06-13 at 12:22 +0200, Luca Barbato wrote:
> >> Care to share the logic and wise reasoning ?
> >
> > [ "${IDEA_ORIGIN}" != "Ciaran" ] && die
>
> I tend to agree.

The reason has already been explained multiple times, kindly stop with the 
personal attacks and silly conspiracy theories.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 19 June 2008 08:46:02 Luca Barbato wrote:
> David Leverton wrote:
> > On Thursday 19 June 2008 04:09:26 George Prowse wrote:
> >> In the end, PMS is just a way for them to spread their own agenda
> >
> > Lies and FUD.
>
> No

Yes.

> ...are you issuing a press release for exherbo?

What the hell does Exherbo have to do with anything?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Removing .la files...

[David Leverton]

On Thursday 19 June 2008 08:51:15 Luca Barbato wrote:
> We could either pick a week and do a major ebuild update to remove .la
> files when unnecessary or just append a notice about revdep rebuild.

How do you decide when they're unnecessary?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Removing .la files...

[David Leverton]

On Thursday 19 June 2008 10:36:12 Luca Barbato wrote:
> 1 getting static libraries (pkg-config replaces this use)

Not for library consumers that use libtool but not pkgconfig.

> 2 load plugins using libtool support

Why only plugins?  What's to stop an application from loading a "normal" 
library using libtool's dlopen wrapper (perhaps so it can fail gracefully if 
the library is missing, for example)?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Removing .la files...

[David Leverton]

On Thursday 19 June 2008 11:39:44 Luca Barbato wrote:
> Corner cases as usual...

What's that supposed to mean?
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: Removing .la files...

[David Leverton]

On Thursday 19 June 2008 13:08:09 Rémi Cardona wrote:
> David Leverton a écrit :
> > Not for library consumers that use libtool but not pkgconfig.
>
> I'd be in favor of having a _default_ configuration for Gentoo where
> static binaries are never built except for some key packages (mainly for
> rescue situations).
>
> That way, in a dynamic-lib only system, libtool will expand -l to
> .so. Simple and easy.
>
> As Diego and others have been on a crusade to make sure that system libs
> are used instead of bundled libs, static libs should also be outcast.

I wouldn't be opposed to that, as long as there's a way to override it for 
people who need to.

> > Why only plugins?  What's to stop an application from loading a "normal"
> > library using libtool's dlopen wrapper (perhaps so it can fail gracefully
> > if the library is missing, for example)?
>
> Nothing per se, but I have yet to see any FOSS application dlopen() gtk+
> or libpng.
>
> *None* of the binary distros out there ship .la files by default. Those
> come with -devel packages. Proof that they are (almost) never needed.

Well... the point is that removing them is a (potential) incompatibility with 
the package as shipped by upstream.  As with the previous point, I suppose I 
could tolerate doing it by default, as long as users can choose to install 
them if they need.
--
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 19 June 2008 14:02:13 Nirbheek Chauhan wrote:
> The point is that their replies to the mailing list waste a lot of
> time and energy since people will *always* reply to them.

Replies?  On a mailing list?  Whatever is the world coming to?

> I completely agree. They should stop pushing it in everyone's faces.
> We all know PMS exists. When the developer community thinks it's
> ready, council will approve it.

Who's "pushing it in everyone's faces"?
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 19 June 2008 14:19:32 Nirbheek Chauhan wrote:
> On Thu, Jun 19, 2008 at 6:40 PM, David Leverton
>
> <[EMAIL PROTECTED]> wrote:
> > On Thursday 19 June 2008 14:02:13 Nirbheek Chauhan wrote:
> >> The point is that their replies to the mailing list waste a lot of
> >> time and energy since people will *always* reply to them.
> >
> > Replies?  On a mailing list?  Whatever is the world coming to?
>
> http://en.wikipedia.org/wiki/Contextomy

I really don't see what context in your original post could change the meaning 
from "oh noes, too many posts, it must be a flamewar11!"  If you'd like 
to clarify, I'd appreciate that very much.

> > Who's "pushing it in everyone's faces"?
>
> Oh great, then I don't expect any more threads about PMS from the authors
> :)

Posting threads about PMS is not the same as "pushing it in everyone's faces".  
This is the appropriate list to discuss PMS issues, as far as I'm aware.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 19 June 2008 14:52:01 Nirbheek Chauhan wrote:
> "oh noes, too many posts with the same 3 people replying everywhere
> and spreading their minority irrelevant opinion as though it really
> mattered! What a gargantuan waste of time and energy11!~"

If you disagree with people's opinions, then you should try to convince them 
otherwise, not say "minority, STFU".

> I mean, you guys don't have *any* control over how Gentoo works
> anymore. No one wants you all around. More than enough people have
> wasted their time and energy on you. Far more people have stopped
> coming onto #gentoo-dev. People who contribute far more than you guys
> have unsubscribed from the gentoo-dev ML. You guys have made even more
> people *leave the project*.

If people can't tell the difference between flaming and disagreeing, that's 
their problem.
-- 
gentoo-dev@lists.gentoo.org mailing list

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

[David Leverton]

On Thursday 19 June 2008 18:06:17 Jeroen Roovers wrote:
> In this case the attacks seem to be targeting a person who has been
> attacking an entire ~300 person project for a few years now.

Is it considered acceptable to attack someone as long as the attacker thinks 
they deserve it?

> I honestly don't see how you are contributing to this project in general,

Well, I'm no vapier, but I have filed the occasional bug, submitted the 
occasional patch, that sort of thing.

> or in particular how you intend to contribute to this project by protecting
> ciaranm against this project.

21:28 < dberkholz@> jmbsvicetto: bheekling did an outstanding job of stepping 
in on that thread and one or two others. he's setting a great role model for 
what the rest of us should do
21:30  let me read the mails again.
21:30  I guess peer-directed intolerance for bad behaviour is 
really the ideal solution for this
21:30  skim*
21:33  dberkholz: hmm, I can't find any mesage from bheekling on 
the -dev ml. Different name on the from address?
21:33  
http://archives.gentoo.org/gentoo-dev/msg_4211dc4054de30f2ff52f6f8a2e2466e.xml 
might be it
21:33 <  rane > Nirbheek
21:34 < dberkholz@> yeah, that's him.
21:34  (name is right, this might be the thread dberkholz is 
referring to)
21:34 <  rane > or sth like that
21:34 <  rane > no idea if it's his real name
21:34  thanks
21:34 < dberkholz@> the specific post i had in mind was a wikipedia reference 
to flames and personal attacks
21:35 <  rane > yeah, this new idea of people telling others they are 
behaving like jerks
21:35 <  rane > it looks like it worked
21:35  Indeed
21:40 <  rane > silent majority stepping in and kicking ass
21:40 <  rane > a great idea indeed
21:47  Maybe we can have a won't-tolerate-bad-behaviour 
pledge. :P

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

Re: [gentoo-dev] Gentoo Council Reminder for August 7

[David Leverton]

On Tuesday 05 August 2008 16:16:25 Alec Warner wrote:
> That being said you are free to chat to Zac about the changes

We've already spoken to him about the changes several times, and it's quite 
clear that he either can't or won't understand why it's bad to make 
incompatible changes without thinking of the consequences or telling anyone 
else who might be affected, leaving them to find out months later when their 
users complain about their systems being broken by an ebuild that relies the 
secret new behaviour.

He didn't even give an explanation of why the change is needed; just that it's 
more consistent, which is true but certainly not a valid reason to break 
things, and that he "didn't consider it to be especially noteworthy", 
indicating that he should perhaps start thinking things through more 
carefully in the future.

Re: [gentoo-dev] Gentoo Council Reminder for August 7

[David Leverton]

On Tuesday 05 August 2008 20:45:33 Ben de Groot wrote:
> It really baffles me that some developers are forcefully retired for
> anti-social behavior, but are not consequently banned from the places
> where they display this behavior, such as our MLs and IRC channels.

I'm not aware of any ex-developers who were forcefully retired and who display 
anti-social behaviour.  Please explain, giving concrete examples of such 
behaviour and reasons why you think it qualifies as "anti-social".

Re: [gentoo-dev] [RFC] New PROPERTIES="live-sources" setting for ebuilds?

[David Leverton]

On Wednesday 06 August 2008 07:37:26 Joe Peterson wrote:
> You are trying to say it's a 'live' ebuild (i.e. it gets the sources from a
> live source) - that's all.  The locking issues are a technical detail

No, the locking issues are the whole point.  There are other reasons to want 
the package manager know that an ebuild is live, yes, but they're fairly 
independent of the locking and so should be indicated separately.

Consider what happens if/when we move the scm eclasses to do their own 
locking, for example: the ebuilds using them are still "live", but the 
mutually-exclusive unpack behaviour on the package manager side is no longer 
necessary or desirable.  We can't just drop the behaviour from the package 
manager entirely at that point, because not all the eclasses will necessarily 
be updated at the same time (especially ones in overlays).

On the other hand, people sometimes use the scm eclasses to fetch a particular 
revision, rather than "the latest".  Ebuilds doing this still need the 
special parallelism handling, but they shouldn't be handled as "live" in 
other ways (such as automatic periodic rebuilds).

Re: [gentoo-dev] Re: Retirement

[David Leverton]

2008/8/11 Alec Warner <[EMAIL PROTECTED]>:
> Many folks are happy at the current pace of development.  I imagine
> these two folks were frustrated at the lack
> of new features in the ebuild spec that were readily available in
> kdebuild-1 and decided to move on.  More power to them I say.

I'm pretty sure that's the least of their worries.

Re: [gentoo-dev] Gentoo Council Reminder for August 7

[David Leverton]

2008/8/14 Donnie Berkholz <[EMAIL PROTECTED]>:
>> Why aren't fired developers banned from the channels where they
>> displayed this behavior?

Isn't this one effectively withdrawn?  I asked yngwin which devs he
was referring to, and he said there weren't any, so is there anything
left to discuss?

Re: [gentoo-dev] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

[David Leverton]

On Monday 25 August 2008 20:36:34 Zac Medico wrote:
> > Zac Medico <[EMAIL PROTECTED]> wrote:
> >> Looking at the dependencies of kde-base/kde, it seems like it would
> >> be eligible to exhibit the "virtual" property.
>
> I'm inclined toward "virtual" since it's more brief and I think it
> might strike a chord with more people because of their familiarity
> with the "virtual" category and old-style PROVIDE virtuals. We'll
> have to see what others have to say.

kde-base/kde isn't like a new- or old-style virtual.  If you want it to be 
used for metapackages and things too, calling it "virtual" would be 
confusing.

Re: [gentoo-dev] [RFC] EAPI 2 Draft

[David Leverton]

2008/9/4 Zac Medico <[EMAIL PROTECTED]>:
>  * The 'unpack' helper function recognizes ;sf=tbz2 and ;sf=tgz
>   extensions, for interoperability with gitweb.
>
>  * SRC_URI supports a syntax extension which allows customization
>   of output file names by using a "->" operator.

Is it useful to have both of these?  The former seems awfully
specialised for a general format like ebuilds, and can be replaced
with

COMMIT="1234..."
SRC_URI="http://git.example.org/?p=foo.git;a=snapshot;h=${COMMIT};sf=tbz2
-> foo-${COMMIT}.tar.bz2"

Re: [gentoo-dev] [RFC] EAPI 2 Draft

[David Leverton]

2008/9/5 Zac Medico <[EMAIL PROTECTED]>:
> Both approaches are essentially equivalent but it's a little simpler
> for ebuild writer if they don't have to customize the output file name.

But is it so much simpler as to justify adding a special
gitweb-specific hack to the package managers?

Re: [gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

[David Leverton]

On Monday 08 September 2008 08:48:23 Vaeth wrote:
> But it doesn't do this well

Those of us who have actually been using it say it does.

Re: [gentoo-dev] EAPI-2

[David Leverton]

On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote:
> Tobias Scherbaum wrote:
> > Luca Barbato wrote:
> >> I don't see any problems with it.
> >
> > +1
> >
> >   Tobias
>
> +1

Since this latest version hasn't generated any noticeable disagreement, could 
the Council please formally vote on it at the next meeting?

Re: [gentoo-dev] Making built_with_use die by default with EAPI 2

[David Leverton]

On Saturday 20 September 2008 18:15:27 Alexis Ballier wrote:
> I can think of checks like:
> - foo is a dep/rdep of bar
> - foo has a "plugin like" architecture
> - bar will "work" with minimal foo
> - most people will expect some features in bar that come with foo's
> plugins
> - we might want to display warnings for the most useful features
> - having useflags in bar for each of foo's useflags doesn't seem wise

If you mean something like

built_with_use cat/foo coolfeature || ewarn "bar will be more useful if 
you rebuild cat/foo with USE=coolfeature"

then you can use

has_version 'cat/foo[coolfeature]' || ...

instead.

> By the way, how will the --missing option of built_with_use be handled
> by eapi 2?

Not at all.  

Re: [gentoo-dev] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[David Leverton]

On Wednesday 15 October 2008 10:33:22 Steve Long wrote:
> Here you go (this is on an old machine, so you'll get much quicker times if
> you try this at home):
> [EMAIL PROTECTED] ~]$ echo "$( #!/bin/bash
> P='some-crap/god-i-hate-asshats'

I do hope that that isn't directed at anyone in particular.

> for ((i=0;i<10;i++)); do echo /usr/share/doc/${P}/examples > /dev/null;

> real 11.25

> real 9.24

So that's what, on the order of 20 microseconds faster for each iteration?

This is a purely stylistic issue, same as the braces with variable expansions.  
You're free to write your own code however you like, but harassing other 
people to do things your favourite way with no practical benefit is just 
going to annoy everyone. 

Re: [gentoo-dev] Re: Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

[David Leverton]

2008/10/15 Steve Long <[EMAIL PROTECTED]>:
> Though, given your tone, I don't think you are feeling harrassed; perhaps
> you're just feeling defensive about your trap boo-boo?

Er, I'm not aware of anyone even trying to tell me that I'm wrong with
anything I've ever said about trap.  If you mean not being able to use
trap ... ERR instead of explicit dies, and you know of a way to make
it work nicely with existing bash versions, then by all means post it
to the bug.  Otherwise, I really have no idea what you're on about.

Re: [gentoo-dev] Flags to punt (including: kerberos USE flag)

[David Leverton]

On Saturday 01 November 2008 02:44:50 Josh Saddler wrote:
> emboss - Seriously. Who needs the European Biology Open Software Suite
> on a *desktop* oriented system?

That flag is only used by a few sci-biology packages, so if you don't have any 
of those installed, it doesn't matter whether the flag is on or off.  IIRC 
the argument for having it on was that the majority of people who /do/ use 
those packages will want it.

I suppose one could say that it should be set in IUSE or profile package.use 
instead, but IMHO, if there are enough packages using it to justify making it 
a global flag in the first place, and all of them need the same default, it 
makes sense to set the default globally (*cough*ocamlopt*cough*).

Re: [gentoo-dev] [PMS] Add RESTRICT="distcc" capability

[David Leverton]

On Saturday 01 November 2008 20:57:17 Gordon Malm wrote:
> I'd like to get "distcc" added as one of the FEATURES we are able to
> RESTRICT.

Regardless of whether it's a good idea or not, does it fix all the known 
issues if the ebuild sets DISTCC_HOSTS="localhost" in the environment?

Re: [gentoo-dev] Flags to punt (including: kerberos USE flag)

[David Leverton]

On Monday 03 November 2008 04:29:34 Nirbheek Chauhan wrote:
> Why not use EAPI=1 for those ebuilds and turn the flag on by default?

Well, as I said, it seems more sensible to me to set the default once, instead 
of once for each ebuild.  I don't particularly care, though, just making sure 
people know why it was there in the first place, and if they still want to 
change it, so be it.

Re: [gentoo-dev] Please review: function epunt_la_files for eutils.eclass

[David Leverton]

On Friday 14 November 2008 14:25:30 Alexis Ballier wrote:
> Moreover .la files are good when you want to link statically to some
> library because they carry the needed information; they should be
> punted only when said library provides a good alternative (like a .pc
> file with correct libs.private field).

Even if the .pc file exists and is fully correct, removing the .la file still 
breaks any application that links statically and relies on libtool to deal 
with library dependencies, rather than using pkg-config (and there's no 
reason why an application /shouldn't/ do that - after all, it works perfectly 
with the library as upstream released it).  Maybe we think it's worth the 
effort to tweak the application's build system (there probably won't be all 
that many applications that need it, after all), but this /is/ an 
incompatible change to the library, and if we're going to do it, we should at 
least be aware of what we're doing.

Re: [gentoo-dev] USE dependencies

[David Leverton]

On Sunday 04 January 2009 16:48:38 Nirbheek Chauhan wrote:
> On the contrary, the reverse of what you say is true. A simple grep of
> the tree showed that:

In how many of those ebuilds would the long form be
use1? ( cat/pkg[use2] )
rather than
use1? ( cat/pkg[use2] ) !use1? ( cat/pkg )
?  Obviously I didn't look through all the hits, but the former seems quite 
common, and any possible shortcut would only save a few characters.

Re: [gentoo-dev] x-modular.eclass: A modified approach to EAPI support

[David Leverton]

On Sunday 08 March 2009 05:22:03 Donnie Berkholz wrote:
> FYI, using EXPORT_FUNCTIONS before inherit, as this patch caused
> x-modular.eclass to do, is broken in current portage releases. Zac said
> he would change this to be consistent with the lack of any ordering
> restriction in the PMS. Thanks to Tomáš Chvátal for tracking down this
> tricky bug!

Better to ask for PMS to be clarified.  All existing package managers do 
EXPORT_FUNCTIONS in more or less the same way, so changing it shouldn't 
happen without an EAPI bump.

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

[David Leverton]

2009/4/1 Mike Frysinger :
> If you have something you'd wish for us to chat about, maybe even
> vote on, let us know !  Simply reply to this e-mail for the whole
> Gentoo dev list to see.

I would like the Council to discuss the matter of Portage repeatedly
changing behaviour in ebuild-visible ways without an EAPI bump or even
an announcement that anything changed.  Notable examples include .lzma
support in unpack (bug 207193), the change in pkg_* phase ordering
(bug 222721) and the preservation of timestamps during merge (bug
264130).  It is quite frustrating to spend considerable effort
determining Portage's behaviour and matching it in Paludis, only to
find a few months later that Portage changed and now users are getting
broken packages if not broken systems because ebuilds are starting to
rely on the new rules.

(The /really/ hilarious part is that certain people then accuse /us/
of being "uncooperative" and "not caring about compatibility".)

This needs to be dealt with if Gentoo is ever going to take the idea
of PMS, or indeed EAPI itself, at all seriously.

Re: [gentoo-dev] EAPI-3 draft: slot operator support

[David Leverton]

On Thursday 09 April 2009 19:06:16 Nirbheek Chauhan wrote:
> > dev-lang/python
>
> So, wait, you want to depend on specific slots of python and keep them
> around, and manage all their related bugs? Isn't that exactly the
> opposite of what python upstream suggests, and *ALL* distros do?

If you install a Python library for Python x.y, even if the library itself can 
support other versions, then the installed package depends on Python x.y, 
period.  Using := is simply acknowledging that fact.  It doesn't mean you 
have to keep x.y around for all time, but it does mean that the package 
manager knows what needs to be reinstalled before x.y can safely be removed.

> @preserved-libs. More generic, a low-level catch-all for library
> breakages, and more convenient for users (rebuild as and when
> possible, not *right now* lest everything break).

More generic?  @preserved-libs knows about Python now?  And the whole point of 
slotting is that you can keep old versions installed, so you don't need to 
rebuild dependent packages "right now".

Re: [gentoo-dev] `paludis --info' is not like `emerge --info'

[David Leverton]

On Sunday 10 May 2009 04:23:25 Nirbheek Chauhan wrote:
> 1. It was a paludis bug, of course paludis --info came in handy (are
> you trying to jest? ;p)

It's most likely not a Paludis bug; do you really think that no-one's ever 
tried to compile Qt4 on amd64 with Paludis until now?  I'm guessing a 
misconfiguration, but we'll have to wait for the real paludis --info output 
(NOT emerge --info, because that doesn't say anything about the Paludis 
configuration) to be sure.

> 2. You found it useful because you knew the syntax, and where to look
> for what -- it is relevant to you. Not to everyone else

It's useful and relevant if and only if it contains information that helps 
diagnose the problem.  In the likely event that it's a misconfiguration, that 
applies to paludis --info, but probably not emerge --info, unless he made the 
same mistake with both.

> 3. Also, last comment on the bug:
>
> "The emerge --info and paludis --info I reported above are from the wrong
> machine.  I'll update the results on Monday when I get back to the correct
> machine.  It is a Xeon W5580 cpu which should be compiling as x86_64.  I
> believe the bug is real.  Sorry for the confusion."
>
> Oops? =p

If anything, that's a point in favour of tanderson's argument.  If the --info 
the user had posted had been right, then both the paludis and emerge output 
are equally useful, because they both indicate that it isn't an amd64 system 
at all.  On the other hand, if it turns out that on the correct system, 
Paludis is misconfigured and Portage isn't, then only paludis --info will 
help.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild

[David Leverton]

On Sunday 10 May 2009 09:58:22 Ryan Hill wrote:
> On Sun, 10 May 2009 02:00:17 -0600
>
> Ryan Hill  wrote:
> > You can't test FEATURES in an ebuild.  It's portage-specific.
>
> Actually, am I right?

Yes.  (http://bugs.gentoo.org/show_bug.cgi?id=239671#c10 gives a better 
approach for this particular problem.)

> There's a crapload of stuff in the tree doing 
> things like this and worse with FEATURES.

Welcome to Gentoo.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild

[David Leverton]

On Sunday 10 May 2009 13:47:45 Ben de Groot wrote:
> What do you expect? He's an exherbo dev, only here to criticize Gentoo
> and gloat over its perceived failings.

It's pretty hilarious that you think you know anything about me.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild

[David Leverton]

On Sunday 10 May 2009 14:02:48 Nirbheek Chauhan wrote:
> It's even more hilarious that you expect to "fix" Gentoo's problems by
> bitching about them.

Same to you as I said to yngwin.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-cdr/cdrdao: ChangeLog cdrdao-1.2.2-r3.ebuild

[David Leverton]

On Sunday 10 May 2009 14:02:57 Ben de Groot wrote:
> Just your activity on Gentoo channels (IRC, ML, etc), which is what my
> assessment is based on.

Nothing I've ever done anywhere, in Gentoo channels or elsewhere, in any way 
implies that I'm "only here to criticize Gentoo and gloat over its perceived 
failings."

Re: [gentoo-dev] The fallacies of GLEP55

[David Leverton]

On Thursday 14 May 2009 19:06:51 Patrick Lauer wrote:
> For quite some time (over a year, actually) we've been discussing the
> mysterious and often misunderstood GLEP55.
> [http://www.gentoo.org/proj/en/glep/glep-0055.html]

We agree on the latter adjective, if nothing else.

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

I wonder where people get this strange delusion that only Windows uses file 
extensions for anything?

> Here's just some of the theories in support of GLEP55 that have been thrown
> at me, and a few words to show how they are not really issues:
>
> "You need to know the EAPI to parse the ebuild to find the EAPI"
> Obviously that's not true, because somehow we manage at the moment.

Because we haven't yet introduced any changes that would break it.

> And if one does a small restriction (which doesn't restrict current
> behaviour because all in-tree ebuilds currently fit within this limitation)
> it becomes trivial again:
>
> Let EAPI be defined as (the part behind the = of) the first line of the
> ebuild starting with EAPI=
>
> As long as ebuilds remain shell-like this is not much of a restriction,

It's an arbitrary, magical restriction that doesn't follow from the general 
rules of the language that ebuilds are written in - you said it 
yourself, "shell-like".   "printf -v EAPI 1" is perfectly valid shell (at 
least if we decide to allow bash 3.1 features), and has the same effect 
as "EAPI=1" under the rules of the shell, but it's not compatible with your 
new rule.

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

With GLEP 55 it's naturally invalid, and can't possibly be assumed to be 
valid.  If you keep the assignment-like syntax but disallow it in eclasses, 
it's an extra weird restriction.

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

And people say Gentoo users are ricers... the whole speed argument is a 
strawman, relevant only to the extent that we don't want to make things 
noticeably slower than they are already.  You claim that GLEP 55 does that, 
but this claim seems to be based on the assumption that without it there 
would be no need to parse the filename in any way, which clearly isn't true.

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

The same thing happened when EAPI itself was introduced.  EAPI support was 
committed to Portage in late September 2005, but the first new EAPI in 
mainstream Gentoo was introduced in early October 2007, just over two years 
later.  That's clearly not an argument for rejecting a compatibility 
mechanism.

It's also not necessary to start putting EAPI in the filename as soon as it's 
approved.  The Council could easily state that "once we need to make a change 
that requires a stronger mechanism than EAPI is currently, we'll do it like 
this" - no need to reject it, or keep "maybe"ing it for eternity.

Of course, there's at least one GLEP 55-scope change that people want already, 
to the extent that they're making up hacks to work around the lack of it, 
namely per-package eclasses.  I would hope that everyone agrees that a 
package manager-supported mechanism would be far preferably (I know that 
vapier does).

> "We want to change the versioning rules!"
> Why do you want t

Re: [gentoo-dev] The fallacies of GLEP55

[David Leverton]

On Friday 15 May 2009 02:42:33 George Prowse wrote:
> Having countered those four points I guess you agree with the other five
> then. Over 50% success rate (by your definition) is hardly being
> ignorant or trolling

In that case we can assume that Patrick agrees with all my counterpoints, 
since he hasn't responded to my email at all.

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

[David Leverton]

On Friday 15 May 2009 21:06:13 Steven J Long wrote:
> In practical terms, this is a useless proposal. It rightly got trashed
> last year.

No, it did not get "trashed", despite some people's attempts to make their 
side sound more popular than it really is.  Some people like the idea, some 
don't, and people have put forward various arguments in both directions.  If 
it were really as widely hated as you claim (presumably with the implication 
that the people who still support it are horrible and evil for even thinking 
about it) then it wouldn't still be under discussion.

Re: [gentoo-dev] The fallacies of GLEP55

[David Leverton]

On Saturday 16 May 2009 10:27:51 Marijn Schouten (hkBst) wrote:
> How is it possible to do these things encoded in the filename?

For the export example, it's just a matter of using a different bash syntax 
from what the magic regex expects, which is completely irrelevant if it goes 
in the filename instead.  For the versionator one, you would change the 
extension at the same time that you changed the version, removing the need to 
modify the file contents.

But the point isn't that we want to be able to do those things.  The point is 
that if the EAPI is in the filename, it's blatantly obvious that it has to be 
static, but adding strange and unintuitive restrictions on which shell 
constructs can be used is, well, strange and unintuitive.

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

[David Leverton]

On Saturday 16 May 2009 13:14:23 Duncan wrote:
> I mean, for the longest time, the main (among many) boosting claim seemed
> to be that the speed difference between in-file and in-filename made the
> former prohibitive in practice.

No, performance was never the point of GLEP 55.  People like to talk about it 
because, as we all know, Gentoo is for ricers, but it's not relevant and 
never has been, except to the extent that we don't want to make performance 
worse than it is now.

> The argument was originally made that a simple highly specified EAPI=
> declaration in the file itself was too restrictive of all the ways it
> could be specified now -- until it began to be pointed out every time the
> argument was made that the filename method was very similarly
> restricted.

No, no-one has ever claimed that the restricted EAPI= method is bad because 
they /want/ to be able to set it using weird bash tricks.  The problem is 
that, if it appears as a bash assignment you /can/ set it using weird bash 
tricks, and making the PM's own parsing accept a subset of what can happen 
when the ebuild /is/ eventually sourced is going to make a mess.

> I'd argue no, it's no more unintuitive than any other format definition
> choice.  It's the basic format definition, using the long accepted method
> of "magic values" at a "magic location" to define the format version.
> That's very basic definitional, restricted only to the degree necessary
> for practical application of the definition.  Therefore, it's not
> unintuitive, or at least, certainly no more so than arbitrarily defining
> it to be in the filename instead, because "intuitive" now gets defined by
> the format definition at an extremely basic level, well below the level
> at which all the "intuitive or not" fancy stuff gets addressed.

"The format definition at an extremely basic level" is bash, which has no such 
restrictions.

For comparson, another alternative that some people have suggested is putting 
it in a specially formatted comment.  This avoids the issue I mentioned 
because bash doesn't try to parse those at all, so the only rules are those 
that specify what format the comment should be in.  On the other hand, this 
isn't backwards compatible with current package managers.

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

[David Leverton]

On Sunday 17 May 2009 08:29:31 Patrick Lauer wrote:
> I thought we had agreed that (1) with GLEP55 you have to source the ebuild
> anyway (whereas the other proposal allows to just parse it to get at the
> EAPI value) and (2) you can cache it sanely so that performance isn't the
> issue?

You don't /have/ to source the ebuild to get the EAPI for GLEP 55.  That 
section is only there to cover corner cases that some people wanted to be 
well-defined, and it could easily be removed if the consensus is that that 
isn't a problem.  On the other hand, it could equally well be added to 
whatever alternative solution you might suggest.

Consider the case where you have a foo-1.2.ebuild-4, and in the contents of 
the file it sets EAPI=5.  What should that mean?  There are three 
possibilities that I can think of:

1) It's illegal, don't do that.  Then there's no need to source the file to 
find the EAPI, because the corner case should never happen, and if it does, 
the behaviour can be left undefined.

2) It's legal, and the ebuild has EAPI 4.  Then there's no need to source the 
file to find the EAPI, because the EAPI in the filename always wins.

3) It's legal, and the ebuild has EAPI 5.  This requires sourcing the ebuild 
to find the EAPI, and it's what GLEP 55 currently says.

Now consider the alternative fixed-format "^EAPI=" suggestion.  What if we 
have a foo-1.2.ebuild, that sets EAPI=4 at the top, and then sets EAPI=5 
further down?  What should that mean?  The same three possibilities apply 
here as in the GLEP 55 case.  If you think it should be illegal, or that it 
should mean EAPI=4, then there's no need to source the ebuild just to find 
the EAPI.  If you think it should mean EAPI=5, then you do need to source the 
ebuild, exactly the same as in GLEP 55.

Either way, this isn't a valid reason to choose the fixed-format alternative 
over GLEP 55, because the same concerns do or do not apply to both.

Re: [gentoo-dev] GLEP 55 updated

[David Leverton]

2009/5/17 Ben de Groot :
> Ciaran McCreesh wrote:
>> On Sun, 17 May 2009 23:17:57 +0200
>> Ben de Groot  wrote:
>>> 2. "Add new global scope functions in any sane way"
>>> This is a valid use case, as seen by the eapi-2 update. But the way
>>> this is currently handled by portage (advising to upgrade the package
>>> manager) works. So I don't see a need to change the file extension for
>>> this reason.
>>
>> It means we can't start using those new global scope functions until
>> we're sure that everyone's going to be upgraded, because users get
>> extremely upset if they start seeing that kind of message.
>
> Isn't that a given anyway? I think the way eapi-2 was introduced into
> the tree wasn't particularly problematic.

I think there might be a misunderstanding here. Ciaran means functions
provided by the package manager that ebuilds can call during metadata
generation, for example built-in versionator-like functionality, not
new phase functions like src_prepare and src_configure.

Re: [gentoo-dev] Re: GLEP 55 updated

[David Leverton]

2009/5/18 Steven J Long :
> David Leverton wrote:
>
>> 2009/5/17 Ben de Groot :
>>> I think the way eapi-2 was introduced into the tree wasn't particularly
>>> problematic.
>>
>> I think there might be a misunderstanding here. Ciaran means functions
>> provided by the package manager that ebuilds can call during metadata
>> generation, for example built-in versionator-like functionality, not
>> new phase functions like src_prepare and src_configure.
>
> Ugh. Firstly versionator is a piece of bloated crap that should have died a
> long time ago; all it does is stop Gentoo newbs learning the basics[1] of
> their implementation language, which leaves them open to nonsensical
> arguments about printf -v (glad you finally learnt that one, btw.)

Yes, it should have died a long time ago, that's why we're talking
about adding equivalent built-in functionality.  Please try to keep
up.  (And it's always amusing to see your bizarre delusions about what
I do and don't know.)

> Secondly, please explain fully and clearly, but concisely, why we can't
> simply state that EAPI=NN allows the ebuild to use the EAPI functions in
> global scope.

Because by the time the package manager knows the EAPI and is in a
position to provide the appropriate functions, the ebuild will have
already tried to use them.

> Bear in mind that you have to deal with the case of the mangler which can
> get EAPI from an ebuild without sourcing, as portage currently can, I
> believe.

Interesting

> Relaxing that restriction strikes me as much saner than relaxing all the
> other restrictions which make interoperability easier.
>
> (Frankly, I'm amazed at having to state that to people trusted to write a
> specification. Follow up to -project on this point please, as it's about
> process, not technique.)

You're amazed that people trusted to write a specification don't
already know what "strikes you as much saner"?  Believe it or not, the
world does not revolve around you and your opinions.

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

[David Leverton]

On Sunday 24 May 2009 21:40:57 Steven J Long wrote:
> Hmm way to go putting thoughts in my head that aren't there.

Yes, that sums you up quite nicely.

Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

[David Leverton]

On Monday 01 June 2009 05:25:06 Jorge Manuel B. S. Vicetto wrote:
> Hello fellow developers and users.
>
> Nominations for the Gentoo Council 2009/2010 are now open for the next
> two weeks (until 23:59 UTC, 14/06/2009).

I would like to nominate dirtyepic, as he has repeatedly shown himself to be 
quite sane and competent.

Re: [gentoo-dev] [RFC] [EAPI=3] Add approprietly prefixed values of IUSE_* variables to IUSE

[David Leverton]

On Sunday 05 July 2009 03:33:54 Arfrever Frehtes Taifersar Arahesis wrote:
> I would like to suggest that values of IUSE_* variables (whose names end
> with values of USE_EXPAND variable), after prefixing with lower-cased names
> of appropriate variables included in USE_EXPAND, should be automatically
> added to IUSE variable.

USE_EXPAND is set in the profiles, so it can't be used during metadata 
generation.

> It's a zero-cost feature implemented in the attached patch, so including it
> in EAPI=3 (after temporary unlocking of list of features of EAPI=3)
> wouldn't delay implementing support for EAPI=3 in Portage.

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

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

[David Leverton]

On 7 March 2012 21:07, Alexis Ballier  wrote:
> As i understand it, $PM will need to try the regexp tingy on any ebuild
> anyway, guess the EAPI then source the ebuild with the right sourcer
> to get the real EAPI and compare it.

Not exactly... the idea with proposal 2) is that the header comment
becomes the One True Way to set the EAPI, so it wouldn't be "guessing"
as such, and ebuilds wouldn't be allowed to change it during sourcing
any more than they can redefine PV or the like.  As mentioned, 2b)
still risks a mismatch between the header and the assignment, but
hopefully that would be temporary and the assignments could be dropped
eventually.  (And I'd suggest that the header EAPI is still considered
authoritative if present - the mismatch check should probably be a
hard error, or if not it should generate a warning and use the header
value.  There should be minimal if any risk of this changing behaviour
for any existing ebuild, since existing ebuilds almost certainly won't
match the chosen header syntax.)

As for my opinion, I would prefer 2a), or 2b) as a second choice.
IMHO it's much simpler and cleaner to come up with a strict,
well-defined header format than to try and work within (an arbitrarily
restricted version of) bash syntax.

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

[David Leverton]

On Mar 8, 2012 3:29 PM, "Zac Medico"  wrote:
> Something like DEPEND="foo bar" is also valid bash, and yet we don't
> allow that either because "foo bar" does not contain valid dependency
> atoms.

There's a bit of a difference between caring about the value of a
variable and caring about what syntax was used to assign it

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 14 March 2012 18:56, Zac Medico  wrote:
> Whatever the arguments may be, the whole discussion boils down to the
> fact that the only people who seem to have a "problem" are those that
> have a separate /usr partition and simultaneously refuse to use an
> initramfs.

I wonder if it might help to go through the benefits of having a
separate /usr, and see whether they still work when /usr is mounted by
initramfs.  Hopefully that would either demonstrate that the initramfs
approach is fine, or reveal a concrete problem with it so we can start
talking about solutions.

(For the record, I don't have a separate /usr, but mainly because when
I've been setting up machines I've been too lazy to either 1) figure
out how much space to allocate to each partition, or 2) learn how to
use lvm so I don't have to worry so much about getting it right the
first time.  I'd prefer for the option to stay available, but not as
strongly as some people do.)

To start us off, the benefit that I'm mainly interested in (for
potential future use, as stated above), and I realise this is probably
pretty far down the list overall, is that OpenRC can run fsck at
shutdown instead of boot for non-/ filesystems, so as long as / is
small there won't be huge boot delays.  I imagine using initramfs
wouldn't affect this, as by the time the system's shutting down it
shouldn't matter how /usr got mounted originally.  It might be
affected if fsck etc got moved to /usr as has been mentioned, but if
that happened OpenRC would probably have to be modified to remount it
readonly at shutdown rather than unmount it, and presumably that would
allow the fsck to occur.

Would anyone else like to continue with their own favourite
separate-/usr reason?

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 14 March 2012 21:04, Greg KH  wrote:
> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> and /bin/ into /usr/ it makes even more sense.  See the /usr page at
> fedora for all of the great reasons why this is good.

My point was examine, in detail, whether separate-/usr-with-initramfs
has any disadvantages compared to separate-/usr-without-initramfs.
Either it has, in which case we have a concrete argument against
requiring initramfs (albeit possibly one that can be fixed), or it
hasn't, which should hopefully convince at least some people to accept
it.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 14 March 2012 22:51, Greg KH  wrote:
> Oh, that's simple, separate-/usr-without-initramfs will not work and
> will not be supported :)

See, it's this "we're doing it this way because we know best and we
say so" that upsets people.  I'm trying to encourage everyone to get
to the core reasons for having a separate /usr in the first place (not
all of which are guaranteed to be mentioned on any specific wiki
page), and logically analyse the potential disadvantages of using an
initramfs in each situation.  It may turn out that there are no
disadvantages after all, but the analysis is still important, not only
to make sure that "we"'re making the right decision, but also to
persuade everyone else that it's the right decision.

> Again, the fact that it works for some people today is pure luck, and
> odds are, it really isn't, but it's really hard to determine this given
> that the init system they are using doesn't provide a good feedback loop
> for this type of thing.

Maybe it would be worth improving the init system to do so?  Or maybe
it wouldn't because using an initramfs is easier and has no drawbacks,
but see above.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 14 March 2012 23:44, Greg KH  wrote:
> Oh, and somehow "consensus" will work?  No, sorry, it will not.

No, logical analysis will, as I said in the rest of my post which you
conveniently ignored - either we conclude with evidence that there are
no issues, which should settle the matter for reasonable people, or we
discover that there are, in which case they have to be dealt with one
way or another.  I really don't see how anyone can object to that,
unless they're worried they won't like the result

> How about the basic FACT that today, such systems do not work

This is debatable at best.  You can keep screaming "but bluetooth
won't work!" until you're blue in the face, but that's not relevant at
all to people who don't use bluetooth.

> and are not supported by a wide range of packages we support today.

Isn't such support being removed by the same people who keep arguing
that it's already not supported?  That's like cutting half your
employees' pay, and then insisting that you have to choice but to cut
the other half's pay as well, in order to be fair.

> Yes, some people are "lucky" in that their systems don't have those
> packages, but others are not.  The simple "I use a bluetooth keyboard"
> is one such example.

People who only have a bluetooth keyboard can set their systems up in
such a way that it works, just like how people who have / on lvm can
set their systems up in such a way that that works.  That's not in
itself a reason to force it on everyone.

> It is strange to watch people somehow think that if they complain
> enough, or feel strongly enough, something is going to change here to
> make this basic fact go away.

If by "the basic fact" you mean that plenty of people are quite happy
doing what's worked just fine for years, then yes.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 14 March 2012 23:47, Zac Medico  wrote:
> It's more about what we're _not_ doing that what we're doing.

Clearly something must have changed in udev 181 to make
/usr-without-initramfs not work anymore, and someone must have done
something to make that change happen, unless udev has aquired the
ability to evolve by itself.

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[David Leverton]

On 15 March 2012 00:45, Zac Medico  wrote:
> You're pointing your finger at udev, but the udev change is just a
> symptom of a more general shift away from supporting the "/ is a
> self-contained boot disk that is independent of /usr" use case.

OK, so there are multiple instances of people not not doing anything
rather than just one.  I think that supports my point more than it
refutes it.

Re: [gentoo-dev] Packages up for grabs due iluxa retirement

[David Leverton]

On 19 March 2012 06:05, Samuli Suominen  wrote:
> dev-cpp/cppserv would need working dev-cpp/sptk and we have none:
>
> http://bugs.gentoo.org/show_bug.cgi?id=402149#c9
>
> the only working versions got marked as "obsolete" by upstream due to
> "undisclosed reasons" whatever that means
>

Not that I personally care, but it seems like this could be "solved"
by just removing fltk support, rather than nuking it completely.

Re: [gentoo-dev] Happy 10th birthday (in advance)

[David Leverton]

On 30 March 2012 14:25, Samuli Suominen  wrote:
> Back to year 2009?
>
> http://www.gentoo.org/news/20091004-gentoo-10-years.xml

That never stopped anyone before

http://en.wikipedia.org/wiki/Final_Fantasy_X-2

Re: [gentoo-dev] Making user patches globally available

[David Leverton]

Zac Medico wrote:

Also, maybe apply_user_patches_here should have a special return value
if there are no patches to be applied? That way, src_prepare can avoid
an eautoreconf call if there are no patches.


Does that imply that every ebuild for an autotools-based package would 
be expected to have an "apply_user_patches_here && eautoreconf" line, 
just in case the user might want to add custom patches?  It could be 
exported by autotools.eclass, but even so, requiring every autotools 
ebuild to inherit the eclass even if it doesn't have any effect by 
default seems a bit unfortunate.

Re: [gentoo-dev] Making user patches globally available

[David Leverton]

Zac Medico wrote:

Isn't that just a consequence of how autotools works? Do you have a
better alternative?


Maaaybe letting the package manager know how to run autotools if 
necessary?  There's already built-in autotools knowledge in that econf 
is in practice autotools-specific.  On the other hand, the eclass logic 
isn't trivial, so unless a simplified subset would be adequate for this 
usage it's probably best left as it is.


The point I was trying to get at was that it seems a bit heavyweight to 
rely on a whole eclass for a minor use-case, as well as a bit 
error-prone to expect people to remember it every time, but maybe that's 
the least bad option after all

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[David Leverton]

Zac Medico wrote:

So, here's a description of the whole algorithm that I'd use:

> [snip]

I think the following is equivalent, but simpler and more general since 
it doesn't have to mention details like ** and friends that aren't 
currently in PMS, and doesn't assume that the rule for handling KEYWORDS 
is simply "does it contain at least one of the accepted values? (plus 
handling of ** etc)".  (For example, I can imagine something like 
"accept the package if it has amd64, or if it has both ~amd64 and x86" 
being potentially useful for some people, although I don't think it's 
implemented anywhere at the moment.)


1) Pretend that all stable keywords in the package's KEYWORDS are 
replaced with the corresponding ~arch ones
2) If this would result in the package being masked by keywords (I 
forget the exact terminology Portage uses, but I'm sure you know what I 
mean), then apply the masks/forces from package.use.stable.*

Re: [gentoo-dev] Chromium bundled code

[David Leverton]

Luca Barbato wrote:

On 03/05/12 16:18, Mike Frysinger wrote:

you need to think bigger.  Chromium supports joystick inputs (which come and
go) for playing games in the browser, so udev makes sense.


So is it using libudev to get that information? I guess would be
possible to patch it out, probably dbus would cover that base as well.

(As soon I have some time I might dabble with a dbus integration for mdev)


If it really is just for joysticks etc it might be worth seeing if it 
can be made to use XInput instead.  Maybe upstream had a specific reason 
not do it that way in the first place, but in general, X apps really 
shouldn't be touching the input devices directly.

Re: [gentoo-dev] Chromium bundled code

[David Leverton]

Mike Frysinger wrote:

On Friday 04 May 2012 15:25:58 David Leverton wrote:

If it really is just for joysticks etc it might be worth seeing if it
can be made to use XInput instead.  Maybe upstream had a specific reason
not do it that way in the first place, but in general, X apps really
shouldn't be touching the input devices directly.


why require X ? :)
-mike


I wasn't aware that Chromium on Linux supported anything else (and at 
least the current ebuild has hard deps on X libraries), but when it is 
running on X it ought to follow X conventions, even if it does something 
else in other circumstances.

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[David Leverton]

Greg KH wrote:

No one forces you to use any of this software if you do not want to.
There are lots of other operating systems out there, feel free to switch
to them if you do not like the way this one is working out, no one is
stopping you.


Or alternatively, the people who hate Unix could move to some other OS 
that suites them better, rather than trying to destroy what everyone 
else is perfectly happy with.

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[David Leverton]

Zac Medico wrote:

Isn't it presumptuous to say that they hate Unix? Maybe their vision of
how they'd like Unix to be is just different from yours?


If "how they'd like Unix to be" goes so blatantly against its 
fundamental design principles then I think it's reasonable to say that 
they hate it.

Re: [gentoo-dev] multiprocessing.eclass: doing parallel work in bash

[David Leverton]

Mike Frysinger wrote:

exec {mj_control_fd}<>${mj_control_pipe}


I'll have to remember that feature, but unfortunately it's new in bash 
4.1, so unless we're giving up 3.2 as the minimum for the tree



: $(( ++mj_num_jobs ))


Any reason not to do just

(( ++mj_num_jobs ))

?


: $(( --mj_num_jobs ))



: $(( ret |= $? ))


Same.

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[David Leverton]

Michał Górny wrote:

Hello,

A simple solution to a program long-unsolved. In GLEP form.


Just a couple of minor points/nitpicks:

1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE, 
should REQUIRED_USE be re-verified:


a) for every dep resolution
b) when the package is involved in the resolution for some other reason 
(not necessarily being reinstalled, just when the resolver has some 
reason to look at it)

c) something else?

I think b) should be sufficient (and probably easier to implement), but 
is there any reason why it wouldn't be?


2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag of 
package B being disabled, but it's unlikely to be useful.  To make this 
more concrete, a fictional but vaguely plausible example:


app-text/docmangler:

# links to poppler to handle PDFs, and can use Ghostscript for
# PostScript support if available
IUSE="postscript"
IUSE_RUNTIME="postscript"
DEPEND="app-text/poppler"
RDEPEND="${DEPEND}
postscript? ( app-text/ghostscript )"

app-misc/coolapp:

IUSE="doc"
# if Ghostscript is installed, docmangler uses it for both
# PostScript and PDF files, but Ghostscript misrenders our PDFs
DEPEND="doc? ( app-text/docmangler[-postscript] )"

Here, the [-postscript] dep would force the user to disable that flag, 
but it wouldn't do much good because Ghostscript would still be 
installed.  This doesn't happen with regular USE flags because (if the 
ebuild is written correctly) disabling the flag removes the feature even 
if its dependencies happen to be installed.


Possible solutions:

a) automatically rewrite the dep as
postscript? ( app-text/ghostscript )
!postscript? ( !app-text/ghostscript )
b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make 
sense in that case to disallow them in !foo-style conditionals in the 
dependencies of the package itself, as that could cause similar paradoxes)
c) don't address it in the spec itself, and require people to manually 
write the dep in the blocker form if it's required

d) something else?

a) is pretty icky IMHO, especially if the flag pulls in multiple 
packages.  I could live with either b) or c), but b) is less flexible 
and c) leaves a potential trap for the unwary.  Any opinions?

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[David Leverton]

Michał Górny wrote:

On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton  wrote:

1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
should REQUIRED_USE be re-verified:

a) for every dep resolution
b) when the package is involved in the resolution for some other
reason (not necessarily being reinstalled, just when the resolver has
some reason to look at it)
c) something else?


Well, I don't understand the difference between a) and b) in your case


Suppose kde-base/kde-meta has both IUSE_RUNTIME and REQUIRED_USE, and 
that I have it installed and then modify one of the flags it uses in my 
configuration, but don't run any PM commands.  Then suppose I install a 
Gnome package.  Normally installing a Gnome package wouldn't require the 
PM to go anywhere near kde-meta, but being strict about revalidating 
REQUIRED_USE would require it to look through every installed package, 
just in case any have IUSE_RUNTIME and REQUIRED_USE set, for every 
installation command.  Is that necessary?


> but the idea is that REQUIRED_USE should be re-verified if either
> enabled USE flag list or REQUIRED_USE changes.

Would that mean the enabled USE flag list should be updated in the VDB 
every time REQUIRED_USE is checked, even when the package isn't being 
reinstalled?  I think it would probably be easier to just recheck 
REQUIRED_USE, without trying to figure out whether any of the 
IUSE_RUNTIME flags were changed, it's just a question of how eager we 
want to be.



2) It's not forbidden for package A to depend on an IUSE_RUNTIME flag
of package B being disabled, but it's unlikely to be useful.  To make
this more concrete, a fictional but vaguely plausible example:



Possible solutions:

a) automatically rewrite the dep as
  postscript? ( app-text/ghostscript )
  !postscript? ( !app-text/ghostscript )
b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
sense in that case to disallow them in !foo-style conditionals in the
dependencies of the package itself, as that could cause similar
paradoxes)

>> c) don't address it in the spec itself, and require people

to manually write the dep in the blocker form if it's required
d) something else?



Good observation. I think b) is the best solution since forced removal
of random dependencies is a very bad idea (and misuse of blockers).


One case that I forgot to mention before: if some package does something 
like


if has_version app-text/docmangler[postscript]; then
# ...
else
# ...
fi

Here, again, the "else" branch can lead to incoherent results as it 
can't assume that the postscript flag being disabled means Ghostscript 
isn't installed, and this one can't be forbidden by restricting the 
allowed dep forms.  I think we'd have to just say "don't do that then"

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[David Leverton]

Michał Górny wrote:

No, of course not. Otherwise, every package manager run would
practically require it to re-validate all packages in the tree
(possibly not only installed ones).

Package manager must ensure the flags are valid when package is
in the graph. I would think of IUSE_RUNTIME as a last-step action where
packages were in the graph for rebuild already but the rebuild is
disabled as being unnecessary.


That's what I thought, was just making sure we're on the same page.


No, the USE flag list in vdb may be updated every time the package gets
into the graph with changed runtime flags. I don't consider that
necessary, however. Just a nice backwards compatibility feature for
other applications looking at vdb.


'K


Well, as I see it restricting is more of a policy than a technical
requirement.


As long as we're clear on which it is, and what restrictions if any the 
PM can/should impose...



But in the current form, the spec doesn't allow passing
IUSE_RUNTIME flags to has_version() so we're on the safe side :P.


True.  Do we want to keep it that restrictive?

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[David Leverton]

Ian Stakenvicius wrote:

Technically it could, but the issue here would be what you are going
to do with a has_version check on an IUSE_RUNTIME dep -- the package
should do filesystem-identical installs no matter what status of
IUSE_RUNTIME flags, so whatever one would do with a has_version check
would have to not change any part of the build or installation.


In principle it would be used for more or less the same thing as it 
would in a dependency, i.e. check whether the runtime-only dependencies 
for that feature are satisfied - the difference being that the package 
can specify arbitrary if-yes and if-no behaviours, rather than just 
"fail the dependency resolution" or not.  (Modulo the problem being 
discussed in this subthread, that a "no" answer isn't reliable.)


For example, some tool used during the build might have a "slow" mode 
that always works, and a "fast" mode that requires some other program to 
be installed and that has to be requested explicitly.  So the package 
that uses the tool might want to do something like


src_compile() {
if has_version dev-util/buildtool[fast]; then
buildtool --fast
else
buildtool
fi
}

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[David Leverton]

Marien Zwart wrote:

Possible solutions:

a) automatically rewrite the dep as
  postscript? ( app-text/ghostscript )
  !postscript? ( !app-text/ghostscript )


There may be more than one version of docmangler, with a postscript flag
with different effects (IUSE_RUNTIME or full IUSE, different
dependencies). That means this kind of rewriting would have to be done
based on the dependencies of the docmangler installed at the time this
package gets built, which seems like entirely too much magic, and...


To clarify, I meant rewrite the dep in docmangler itself, and not 
necessarily on disk in the VDB or wherever, just in memory when parsing 
it.  But as I said, I don't like that idea anyway, I just mentioned it 
for completeness.



b) forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make
sense in that case to disallow them in !foo-style conditionals in the
dependencies of the package itself, as that could cause similar paradoxes)


this seems generally impossible, as the same USE flag may be
IUSE_RUNTIME in only some versions of docmangler.


True.  We could declare that in situations like that the developer just 
needs to be more careful, but then it's not that much better than c)



c) don't address it in the spec itself, and require people to manually
write the dep in the blocker form if it's required


I would be in favor of leaving this up to the writer of the coolapp
ebuild, especially as if docmangler is currently using a "full" USE flag
for postscript this is already currently broken.


Well, in theory if it's a normal USE flag then disabling it should 
actively remove the Ghostscript support from docmangler, even if 
Ghostscript happens to be installed, but maybe it doesn't always work 
out that way.

Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc

[David Leverton]

On 10 September 2012 15:48, William Hubbs  wrote:
> All,
>
> I have a regression in OpenRc wrt netplugd [1].
>
> In researching this program, I have found that it and ifplugd, which is
> the alternative, have been unmaintained for years. Also Debian has
> declared netplugd to be obsolete in favor of ifplugd.

The page referenced on the bug that says so appears to be talking
about a different package than the one we have in the tree - they have
different authors stated, and also, for the one we have the package is
called netplug, with the executable called netplugd, whereas for the
one declared obsolete the package itself is called netplugd.

> Does anyone have any thoughts about whether we should keep OpenRC
> support for one or both of these?

There are a few options for this functionality (that I'm aware of):
1) netplug: never used it so no particular comments.
2) ifplugd: what I'm using now.  I can't remember if there's a
particularly good reason why I chose it, but I suspect it might have
been for the audio feedback it provides when it detects a connection
or disconnection.  This probably isn't compelling enough by itself to
keep the package if we'd otherwise want to remove it, but it is quite
nice.
3) wpa_supplicant: supposed to be able to do this even for wired
interfaces, but I just did some experimenting and it seems broken - it
thinks the cable is plugged in even when it isn't.
4) dhcpcd: not sure when it was introduced, but current dhcpcd can
detect when the link goes up and down, and request/renew its lease
when it comes up.  The only wrinkle that I can see here is that, if no
ifplugd/netplug/wpa_supplicant is configured, OpenRC waits for it to
receive a lease when starting the interface, rather than allowing it
to background itself.

So for dhcpcd, it might be enough to just make OpenRC aware that it
doesn't need to wait for a lease when starting the interface.  Keeping
at least one of the other options working would still be required for
other DHCP clients if they don't have similar functionality, or
non-DHCP situations where it's necessary to do some sort of
reconfiguration when the network is (dis)connected (such as OpenRC's
arping module), assuming anyone cares about those of course.

>
> Thanks,
>
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=427088

Re: [gentoo-dev] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

[David Leverton]

On 13 September 2012 06:48, Ulrich Mueller  wrote:
>> On Thu, 13 Sep 2012, Brian Harring wrote:
>> For SANDBOX_*, while that's a PM internal, that's a bit of a grey
>> zone; regardless, we can actually address that via extending the
>> sandbox functions a bit:
>>
>> addwrite [-r|--remove] pathway # for example, to do a removal.

It's nice to be able to do
local SANDBOX_WRITE=${SANDBOX_WRITE}
and then allow bash to restore the old value at the end of the
function, regardless of how it exits.  It's not the end of the world
to lose this, but it would be a bit of a shame IMHO - having to do it
manually seems a little error-prone.

>> For instances where the sandbox needs to be turned off for a command-
>> we do the same thing we did w/ nonfatal;
>>
>> sandboxless 
>
> To start the bikeshedding: For some reason I associate "less (the
> pager) in a sandbox" with this. ;-) Maybe "nosandbox" or "sandboxoff"?

"sansbox"?  *flees*

Re: [gentoo-dev] Re: [RFC] Shall econf append its arguments to end of ./configure invocation?

[David Leverton]

On 1 May 2013 02:52, Ryan Hill  wrote:

> Then the person implementing the code for Paludis is either a monkey or a
> robot*.
>
> *or both (?!)
>

Alternative possibilities include ninja, zombie and wizard.

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[David Leverton]

Rich Freeman wrote:

[...] and the point that many things
break in namespaces without the symlink, since /etc/mtab does not
reflect the state of the namespace.  The latter in particular seems
like a pretty fundamental limitation - the very concept of /etc/mtab
is that mounts are global, and the design of linux is that mounts are
NOT global.


If only someone would invent some sort of kernel feature that could make 
the name "/etc/mtab" refer to different files in different processes

Re: [gentoo-dev] rfc: converting /etc/mtab to a symlink

[David Leverton]

Rich Freeman wrote:

However, FWIW, linux namespaces cannot be used to have only a single
file appear differently to different processes.  Mount namespaces can
only operate at the directory level.


So to work around that limitation we insist that everyone change how 
their systems are set up, and still have to reintroduce mtab under a 
different name ("utab", hidden away under /run) because 
/proc/self/mounts *doesn't* contain everything that's supposed to be in 
mtab after all?


If someone decides they want to use, say, different DNS servers in 
different namespaces, should we make the kernel store the server IP 
addresses, add a /proc file that dumps them out in the expected format, 
and demand that everyone replace their /etc/resolv.conf with a symlink 
to /proc/self/resolv.conf?  Or maybe, if people want namespaces, they 
can implement them properly, in which case it becomes literally a 
self-solving problem.