Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)

2014-02-28 Thread David Leverton

William Hubbs wrote:

The reason the split happened is pretty straight forward, and every other
justification for continuing it was come up with after the fact.


I keep hearing this, but I really don't see how it's relevant.  I'm sure 
you'll find lots of things in your life that you use for some purpose 
other than what they were originally invented for¹, and there's no 
reason why /usr should be any different.  All that matters is whether or 
not the newer reasons for having separate /usr actually provide a benefit.


[1] http://en.wikipedia.org/wiki/Coca-Cola#19th_century_historical_origins




Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)

2014-02-28 Thread David Leverton

William Hubbs wrote:

And I would argue that the maintenance cost of having separate /usr in a
general sense is much higher than the benefit it provides.


That's a legitimate point (not that I necessarily agree or disagree as 
I'm not the one who's tried to make it work) - perhaps I should have 
acknowledged that it's still a trade-off.  I'm just trying to get rid of 
the meme that whatever benefits do exist somehow don't count because 
they weren't planned in the original Unix design.





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

2013-10-14 Thread 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

2013-10-14 Thread 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.





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

2013-10-14 Thread David Leverton

Mike Gilbert wrote:

This is a horrible example. /etc/resolv.conf is a configuration file
for code that lives entirely in userspace. Of course it makes no sense
to shove that into the kernel.


My point is that it's silly to have a hard-coded special case in the 
kernel for mtab, especially if it doesn't do the job properly and 
requires an extra utab file, when the general solution could work for 
any file and wouldn't require any changes when the namespace feature 
isn't in use.





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

2013-10-14 Thread David Leverton

Patrick McLean wrote:

This is not true. Bind mounts can be performed on a single file, and
bind mounts are part of mount namespaces. Granted the target file _must_
exist (it could be a dead symlink, or a symlink to /dev/null) before
performing the bind mount.


Well that's even better then. :-)




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

2013-05-01 Thread David Leverton
On 1 May 2013 02:52, Ryan Hill dirtye...@gentoo.org 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] EAPI5: require ebuilds/eclasses to not use any vars/funcs prefixed with __

2012-09-13 Thread David Leverton
On 13 September 2012 06:48, Ulrich Mueller u...@gentoo.org 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 the command and args

 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] rfc: netplugd and ifplugd support in OpenRc

2012-09-10 Thread David Leverton
On 10 September 2012 15:48, William Hubbs willi...@gentoo.org 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] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

2012-06-22 Thread 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

2012-06-22 Thread 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] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

2012-06-21 Thread 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

2012-06-21 Thread David Leverton

Michał Górny wrote:

On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton levert...@googlemail.com 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

2012-06-21 Thread 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] multiprocessing.eclass: doing parallel work in bash

2012-06-02 Thread 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] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

2012-05-10 Thread 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]

2012-05-10 Thread 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] Chromium bundled code

2012-05-04 Thread 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

2012-05-04 Thread 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] Feature request: package.use.stable.mask and package.use.stable.force

2012-04-27 Thread 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] Happy 10th birthday (in advance)

2012-03-31 Thread David Leverton
On 30 March 2012 14:25, Samuli Suominen ssuomi...@gentoo.org 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] Packages up for grabs due iluxa retirement

2012-03-19 Thread David Leverton
On 19 March 2012 06:05, Samuli Suominen ssuomi...@gentoo.org 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] Re: Let's redesign the entire filesystem!

2012-03-14 Thread David Leverton
On 14 March 2012 18:56, Zac Medico zmed...@gentoo.org 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!

2012-03-14 Thread David Leverton
On 14 March 2012 21:04, Greg KH gre...@gentoo.org 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!

2012-03-14 Thread David Leverton
On 14 March 2012 22:51, Greg KH gre...@gentoo.org 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!

2012-03-14 Thread David Leverton
On 14 March 2012 23:44, Greg KH gre...@gentoo.org 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!

2012-03-14 Thread David Leverton
On 14 March 2012 23:47, Zac Medico zmed...@gentoo.org 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!

2012-03-14 Thread David Leverton
On 15 March 2012 00:45, Zac Medico zmed...@gentoo.org 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] RFD: EAPI specification in ebuilds

2012-03-08 Thread David Leverton
On Mar 8, 2012 3:29 PM, Zac Medico zmed...@gentoo.org 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] RFD: EAPI specification in ebuilds

2012-03-07 Thread David Leverton
On 7 March 2012 21:07, Alexis Ballier aball...@gentoo.org 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] new virtual/yacc

2011-08-07 Thread David Leverton
On Aug 8, 2011 12:22 AM, Mike Frysinger vap...@gentoo.org wrote:
 virtual/yacc which has || ( sys-devel/bison dev-util/yacc ).

No dev-util/byacc?


Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

2011-07-30 Thread David Leverton
On Saturday 30 July 2011 14:55:23 Samuli Suominen wrote:
 Someone mentioned NFS mount on /usr.  Do we have other reasons?  How
 many users that might be?

From /etc/conf.d/fsck, seems like a reason to keep the / FS as small as 
possible to reduce the amount of time spent waiting during boot:

# fsck_shutdown causes fsck to trigger during shutdown as well as startup.
# The end result of this is that if any periodic non-root filesystem checks are
# scheduled, under normal circumstances the actual check will happen during
# shutdown rather than at next boot.
# This is useful when periodic filesystem checks are causing undesirable
# delays at startup, but such delays at shutdown are acceptable.
fsck_shutdown=YES



Re: [gentoo-dev] Warn users not to do separate /usr partition without proper initramfs in the handbook?

2011-07-30 Thread David Leverton
On Saturday 30 July 2011 18:38:55 Rich Freeman wrote:
 On Sat, Jul 30, 2011 at 1:20 PM, David Leverton
  From /etc/conf.d/fsck, seems like a reason to keep the / FS as small as
  possible to reduce the amount of time spent waiting during boot:
 Well, that only really has a benefit if the system can do something
 useful between the time that root is mounted and /usr is mounted,
 which is probably a no.

Not quite sure what you mean there... I meant that OpenRC lets you move non-/ 
fscks to shutdown, but you still have to wait for / to be checked during boot 
whenever it's due, so it's good to have it small so you don't have to wait too 
long.



Re: [gentoo-dev] Re: Re: .la files and their future on Gentoo

2010-10-06 Thread David Leverton
On 6 October 2010 10:20, Luca Barbato lu_z...@gentoo.org wrote:
 We discussed that to death, you are wrong abusing overlinking in your pet
 project and what you were asking for is exactly the as-needed behaviour.

Clearly you have no clue what you're talking about here.



Re: [gentoo-dev] Re: .la files and their future on Gentoo

2010-10-05 Thread David Leverton
On 5 October 2010 23:38, Enrico Weigelt weig...@metux.de wrote:
 And for Distros, it doesnt make sense to try to support anything imaginable.

Not breaking things that already work would be a decent compromise.

 I'm now working in embedded area (where static linking is quite common)
 for about 10yrs, and pkg-config has proven quite well here. (packages
 that dont provide .pc-descriptor yet, simply have to be fixed to do
 so ;-p). Libtool, on the other hand, always had been a nightmare.

What about things that don't use pkg-config?  If you say we don't
support that, modify it to use pkg-config, does that mean you're
willing to make Gentoo incompatible with Linux in general?  (That
question isn't just about .la files, it applies to any change versus
upstream that affects interfaces between components.)

Just to reiterate, I'm not trying to block anything here.  I'm just
asking for a small override so people with use-cases you (in general,
not a specific person) haven't thought of can be happy.  It doesn't
have to be officially supported or anything.  Is that really so
unreasonable?



Re: [gentoo-dev] .la files and their future on Gentoo

2010-10-03 Thread David Leverton
On 2 October 2010 20:54, Jorge Manuel B. S. Vicetto
jmbsvice...@gentoo.org wrote:
 Given the recent activity around .la files and conflict about how to
 deal with them, I propose we discuss this issue in this mailing list,
 and take this issue to the council.
 That way, we can make a global decision, taking into account all the
 arguments for and against, find a balance, opt for a policy, inform
 users and developers about it and move on.

While I do agree that the underlying problem we're trying to solve is
worth solving, I do have a couple of small concerns about how it's
being done.  The first is that it seems people are judging whether a
particular .la file is needed by checking whether anything currently
in the tree needs it, but this doesn't take into account anything that
/isn't/ in the tree yet.  The second is that removing .la files
everywhere makes it hard for people to experiment with alternative
solutions, as testing an alternative would require modifying all the
affected ebuilds to stop removing them.  (And yes, I am interested in
doing so myself, although time constraints mean it might not
happening.)

Would it be too much trouble to have a standardised variable that
means .la files should be kept?  It maybe /shouldn't/ be exposed as a
USE flag because very few people will need it, but if it's easy to
implement (maybe by having an eutils function to do the removal,
checking the variable first) it would remove any objections I could
imagine.

As I said, these are minor points, and I wouldn't expect people to go
to great effort to satisfy them.  Just something to consider.



Re: [gentoo-dev] .la files and their future on Gentoo

2010-10-03 Thread David Leverton
On 3 October 2010 14:20, Richard Freeman ri...@gentoo.org wrote:
 Such a solution would also have the virtue of allowing the use of USE
 dependencies.  So, you would only install the .la files from a
 particular library if another package actually needed them.  Packages
 could also have USE defaults as seems logical to their maintainers and
 distro policy.

That's a good point - I did suggest not putting it in USE to avoid
cluttering things up for the sake of a use case that most people won't
need, but being able to do USE deps would be nice.  Maybe a
USE_EXPAND_HIDDEN variable could be a compromise, but that itself
could be confusing when a package wants to enable a flag that doesn't
appear to exist.  It probably depends on how often such a dep would
actually be needed - I suspect not very often.

 Where this would get complex is if we want more than all-or-nothing
 resolution.  The simplest USE approach would be to have it toggle all
 the .la files in the package.  However, if you have 5 files that are
 essential, and 5 that are likely nothing but trouble it will be harder
 to manage that while still allowing full control.  I guess careful use
 of local flags might work, in combination with some sane policy.  I'm
 not sure if this is a use case that is even worth worrying about...

I think that's unlikely to be a problem, but yes, local flags or the
like could be used if it ever does come up.



Re: [gentoo-dev] .la files and their future on Gentoo

2010-10-03 Thread David Leverton
On 3 October 2010 15:29, Luca Barbato lu_z...@gentoo.org wrote:
 I think the simpler solution is that if it needs .la, before reaching the
 tree it has to be fixed...

What I'm not keen about that is that using the .la files isn't really
broken - if libfoo uses libtool, and some other software uses
libfoo's .la files in a way that works with the upstream version of
libfoo, then it ought to work with Gentoo's libfoo too.  (This gets
into arguments about what sorts of changes are appropriate for a
distribution to make, versus being left to upstream.)

Also, not every piece of software that people might want to use is
going to go into the main tree - people can use Gentoo to develop
their own software (and might have their own ideas (or their
company/project's ideas) about what parts of libtool it's appropriate
to rely on), use packages from overlays, compile other people's
software outside the package management system, run precompiled
binaries, etc.  Again, from here I'm sure you can have a big
discussion about whether libraries in the tree exist only to support
applications in the tree, or whether they're products (for want of a
better word) in their own right.

Again, maybe not earth-shatteringly important issues, but I do think
these should at least be considered when deciding the policy.



Re: [gentoo-dev] New eclass: scons.eclass

2010-08-22 Thread David Leverton
2010/8/22 Michał Górny gen...@mgorny.alt.pl:
 src_compile() {
        scons \
                $(scons-use unicode) \
                $(scons-use gnutls ssl gnutls openssl) \
                ${MAKEOPTS} || die
        # expands into:
        # scons unicode={1|0} ssl={gnutls|openssl} -jN || die
 }

It might be slightly nicer to have an escons function that adds the
modified MAKEOPTS to the command line and calls die by itself.
Besides making it easier to use, that would provide a single place to
add additional functionality (perhaps an EXTRA_ESCONS user variable
analogous to EXTRA_ECONF, for example).



Re: [gentoo-dev] RFC: Reviving GLEP33

2010-08-12 Thread David Leverton
On 12 August 2010 08:51, Ben de Groot yng...@gentoo.org wrote:
 Exactly. This is Gentoo. Let Exherbo devs go develop their own distro
 and stop trying to interfere with Gentoo. It is time the council puts
 a definite stop to GLEP 55.

I've already discussed this with you, but it seems you still don't get
it.  People are not defined as Gentoo people or Exherbo people.  I
can't speak for anyone else, but I am a sentient being with enough
mental capacity to be interested in more than one thing at once - in
other words, being an Exherbo developer doesn't in any way interfere
with wanting to see Gentoo improve.  There is no activity from Exherbo
trying to push anything on Gentoo, there is only Gentoo users
contributing ideas towards developing the distribution.



Re: [gentoo-dev] RFC: Reviving GLEP33

2010-08-06 Thread David Leverton
On 5 August 2010 04:27, Brian Harring ferri...@gmail.com wrote:
 If an EAPI adds a new global function that cannot set/influence EAPI,
 PM's that don't support that EAPI will spit complaints about 'missing
 command' during sourcing- however the PM will still see the EAPI value
 is one it knows it doesn't support, and act accordingly.

You're suggesting a system based around ebuilds running commands that
don't exist and ignoring the errors, which is a pretty blatant hack.
While I don't think it's /absolutely/ out of the question, as I said
earlier, I can see why some people would exclude it from consideration
entirely.



Re: [gentoo-dev] RFC: Reviving GLEP33

2010-08-02 Thread David Leverton
On 2 August 2010 12:11, Brian Harring ferri...@gmail.com wrote:
 On Mon, Aug 02, 2010 at 11:56:08AM +0200, Matti Bickel wrote:
 Hi folks,

 I've been told that my use of eblits in dev-lang/php is something I
 should get rid of as soon as possible. Suggested alternative by ferring:
 use elibs.

There's a couple of hundred lines of repeated metadata between
php-5.3.2 and php-5.3.3 - not identical, but similar enough that there
would be gains from factoring it out, and elibs won't help with that.
Am I understanding correctly in that you didn't use an eclass to avoid
cluttering up the main eclass directory with something specific to
this one package?  If so, it sounds like what you really want is
per-package eclasses (maybe with elibs as well to hold the
non-metadata code), which aren't covered by GLEP33 but ought to be
easy enough to add.

 There's a caveat here; imagine one of the current PM's processing an
 EAPI=4 (or whatever) ebuild that uses elib- specifically there will be
 a global scope function invocation of a function that doesn't exist.

 In the past, a minority of folk have raised complaints about this- it
 was never stated as best I know, but my assumption looking back is
 that it was due primarily to paludis getting pissy about ebuilds
 outputing anything during metadata sourcing

I can't speak for other people who may have complained, but it seems
to me that for ebuilds to be calling non-existent commands is fairly
obviously wrong, even if the consequences happen to be benign - not
the end of the world, but something that ought to be avoided if
possible.  (As far as paludis goes, it's more stdout that it used to
get upset about than stderr.)

 Managers should implementat that functionality; orthogonal to it,
 we've got a few options for how to deal with an EAPI=4 ebuild being
 metadata sourced by a =EAPI3 PM (meaning, there will be a command
 not found spat to stderr during sourcing):

 [...]

Regarding the stuff about other standalone repositories, I don't think
it's a big deal to require them to carry a small amount of extra stuff
(only if they actually start using elibs in any case), considering all
the profiles, eclasses etc that they'd need anyway.  Overlays based on
the main Gentoo tree would be fine without any effort.

(For the record, +1 for GLEP55 from me, but the reasons for and
against don't need to be repeated yet again.)

 My suggestion?  Split this into two, elibs, and eclass refactoring.

Per-package eclasses would be beneficial IMHO regardless of the other
eclass stuff from 33, might be worth thinking about those as another
item (consistent with the existing design plans of course) if the rest
isn't going to happen soon.



Re: [gentoo-dev] RFC: Reviving GLEP33

2010-08-02 Thread David Leverton
On 2 August 2010 22:40, Matti Bickel m...@gentoo.org wrote:
 On 08/02/2010 08:16 PM, David Leverton wrote:
 If so, it sounds like what you really want is per-package eclasses
 (maybe with elibs as well to hold the non-metadata code), which
 aren't covered by GLEP33 but ought to be easy enough to add.

 It's actually covered by GLEP33:
 http://www.gentoo.org/proj/en/glep/glep-0033.html#tree-restructuring

I interpreted that more as a way to organise the global eclasses, but
yes, it could be used for per-package stuff too.  I'd still prefer to
have the eclasses next to the ebuilds they're meant to be used by, but
that's just a detail (and as I say, could easily be added to the GLEP
if anyone else wants it).



Re: [gentoo-dev] versionator.eclass: convert to eshopts_{push,pop}

2010-07-19 Thread David Leverton
On 19 July 2010 20:43, Mike Frysinger vap...@gentoo.org wrote:
 On Monday, July 19, 2010 03:38:39 Ciaran McCreesh wrote:
 On Sun, 18 Jul 2010 20:17:45 -0700 Alec Warner wrote:
  Can we do away with all the extra foo  return bullshit and just set
  a trap?
 
  trap eshopts pop RETURN
 
   ?

 That strikes me as a horribly fragile way of doing things that's bound
 to come back and screw things up at some point...

 nifty in theory, but i'm inclined to agree with Ciaran
 -mike

Is something like the below function too hideous (not massively
tested, but it seems to work)?  Usage is something like:

[dlever...@shiny-one ~] $ foo() { shopt -p extglob; }
[dlever...@shiny-one ~] $ eshopts_need foo -s extglob
[dlever...@shiny-one ~] $ shopt -p extglob
shopt -u extglob
[dlever...@shiny-one ~] $ foo
shopt -s extglob
[dlever...@shiny-one ~] $ shopt -p extglob
shopt -u extglob

eshopts_need() {
[[ $# -ge 1 ]] || die eshopts_need needs at least one argument
local func=$1
shift
local opts=( $...@} )
if [[ $1 == -[su] ]] ; then
eval _eshopts_need_shopt_$(declare -f $func)
eval $func() {
local old=\$(shopt -p)
$(declare -p opts)
shopt \\${op...@]}\
_eshopts_need_shopt_$func \\...@\
local status=\$?
eval \\$old\
return \$status
}
else
eval _eshopts_need_set_$(declare -f $func)
eval $func() {
local old=\$-
$(declare -p opts)
set \\${op...@]}\
_eshopts_need_set_$func \\...@\
local status=\$?
set +\$-
set -\$old
return \$status
}
fi
}



Re: [gentoo-dev] versionator.eclass: convert to eshopts_{push,pop}

2010-07-19 Thread David Leverton
On 19 July 2010 21:30, Mike Frysinger vap...@gentoo.org wrote:
 i imagine this might be useful in some scenarios, but i think the more common
 usage is to enable things inline.  otherwise, the exported API would need to
 be wrapped internally like:
 get_all_version_components() {
        eshopts_need _get_all_version_components -s extglob
 }

It's meant to work to just define get_all_version_components with the
assumption that extglob will be enabled, and then call eshopts_need in
global scope right after.

 although, the method we have now also
 allows for disabling of shopts before calling `die`.  not sure if that's
 important, but i think it's better to disable before all exit/termination
 points.

That's a reasonable point.

 so unless their is a consumer now we can point to in the tree, i'm inclined to
 leave this alone.

Fair enough.

 there are already eshopts_push/pop funcs that accomodate more things than the
 usage here, but i imagine you did it this way just to make testing in your
 shell easier
 -mike

It was supposed to support everything the existing functions do (not
everything demonstrated in the example for brevity), but I might have
missed something.



Re: [gentoo-dev] versionator.eclass: convert to eshopts_{push,pop}

2010-07-19 Thread David Leverton
On 19 July 2010 22:11, Mike Frysinger vap...@gentoo.org wrote:
 you mean the people who want to use get_all_version_components would have to
 change their invocation to go through eshops_need ?  otherwise i dont follow
 what you mean.

You define the function, then call eshopts_need immediately
afterwards, and it sets up the wrapper automatically.  You can then
call get_all_version_components as normal.



Re: [gentoo-dev] Re: Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults

2010-07-05 Thread David Leverton
On 5 July 2010 14:01, Peter Hjalmarsson x...@rymdraket.net wrote:
 1. (A t-shirt saying 2 + 2 = 5. For this joke to work you have to know
 how to round numbers, and that 2 can be rounded from everything between
 1,5 and 2,4, and that 4,8 rounds to 5. And it is still correct math.)

You said yourself that it's a joke, and yet somehow you don't seem to
understand what that means



Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults

2010-06-29 Thread David Leverton
On Monday 28 June 2010 02:09:44 Nirbheek Chauhan wrote:
 Hello everyone,

 I'm sure at least half of you are thinking Oh no, not this again...,
 and I agree. However, I'm /also/ thinking Why the heck haven't we
 done this yet?

 [...]

/If/ you're¹ going to insist on doing this, could you please at least do it in 
a way that's easy for users to disable?  (Profile LDFLAGS as the subject line 
says obviously qualifies, but there's also been talk of creating gcc-config 
profiles, modified specs etc.)  That way people can choose according to their 
own preferences for correctness versus convenience etc.

[1] Whoever does it, not specifically Nirbheek



Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults

2010-06-29 Thread David Leverton
On Tuesday 29 June 2010 09:46:52 Alex Alexander wrote:
 If the community feels their choice, albeit not perfect, will help the
 project, you have to respect that. That is, if you want to be part of the
 community :)

I see your point to some extent, but the concern is that such decisions might 
sometimes get made according to who's best at ignoring technical objections 
rather than what's the best thing to do.  It has happened before, although in 
that case the change was made first, and then when the issue was brought up 
it got basically ignored for so long that it would be pointless to fix.  It 
would be worrying if things like that started to happen more often.

In any case, as mentioned in my other mail, if this particular change is done 
in a way that's optional for the user, I personally won't be /too/ upset if 
the rest of you want to do unspeakable things to your systems ;-).



Re: [gentoo-dev] Tone in Gentoo

2010-06-19 Thread David Leverton
On Saturday 19 June 2010 22:03:31 Ben de Groot wrote:
 It is about whether Gentoo wants to keep around people [...] who
 continually attack others

Considering the number of attacks directed towards Paludis developers (and 
sometimes users), and lack of corresponding punishment, I can only assume the 
answer is yes.



Re: [gentoo-dev] Tone in Gentoo

2010-06-19 Thread David Leverton
On Saturday 19 June 2010 23:01:33 Patrick Lauer wrote:
 you're actively stepping in the way of moving fists to complain that
 people punch you. Stop doing that.

You mean banning trolls is an invitation for you to snip the trolling and 
publicly accusing me of banning them on a whim?  (excerpt from 
http://www.gentooexperimental.org/~patrick/weblog/archives/2008-03.html#e2008-03-31T20_31_17.txt)

 So things are starting to look quite toasty. The nice paludis people even 
 keep the bad vibes away:

 [17:12:44] *** Mode #paludis +b *...@gentoo/user/FamousToaster by dleverton
 [17:13:11] *** Mode #paludis +b d0pamin...@* by dleverton
 [17:13:15] -* dleverton has kicked fragalot from #paludis (bye bye)
 [17:13:19] -* dleverton has kicked D0pamine from #paludis (bye bye)
 [17:13:35] *** Mode #paludis -o dleverton by dleverton

 followed by

 17:19 rane i'm a gentoo developer relations project member
 17:19 fragalot Hi. :)
 17:20 rane and i want to inform you that if you continue to behave the way 
 you did on #paludis, your  gentoo/user cloak will be 
 removed

 Behaving that way meaning joining the channel and saying Hi ? Wow, that's 
 great. So I must really recommend to users never to go near that place as
 they will have firebreathing dragons on their behind within minutes.  

Or asking for opinions on a technical issue is a form of trolling?

http://www.gentooexperimental.org/~patrick/weblog/archives/2008-05.html#e2008-05-03T22_15_54.txt

There's plenty more, but I don't think it would be productive to try and track 
down everything.



Re: [gentoo-dev] Tone in Gentoo

2010-06-19 Thread David Leverton
On Saturday 19 June 2010 23:05:25 Domen Kožar wrote:
 http://xkcd.com/386/

s/wrong/attacking me in public/ and it might be closer.



Re: [gentoo-dev] pkg_pretend USE validation and VALID_USE alternative

2010-04-02 Thread David Leverton
On Thursday 01 April 2010 19:39:43 Dror Levin wrote:
 Here's another suggestion: how about we don't impose any ridiculous
 constraints on development and keep this discussion on the technological
 side of the original proposal?

It's not ridiculous to expect to have a new EAPI in a reasonable amount of 
time.  Other features are already done, so holding them back until this one 
is complete would itself be placing constraints on developers who have a use 
for the other features.



Re: [gentoo-dev] Re: Marking bugs for bugday?

2010-03-07 Thread David Leverton
On Sunday 07 March 2010 04:30:55 Sebastian Pipping wrote:
 What I wonder now is:
 - Will it work with our very instance of Bugzilla?

The security team uses (or at least has used in the past) flags on Gentoo 
Bugzilla.

 - Can certain flag states be required when searching?

It looks like you need to use the Advanced Searching Using Boolean Charts 
section on the search page - you can select Flag, is equal to, and type 
the flag name/state, for example Assigned_To? for one of the 
above-mentioned security flags.  Note that the normal search fields still 
apply, so you need to deselect all the options in the Status list before 
that particular example will produce any results.

 - Can we get their current value out using ctype=rdf output

I don't think you can with the RDF, but the XML button on the search results 
page includes the flags (and a whole lot of other information), so if you're 
going to rewrite the bugday software anyway you could consider using that 
instead, if it would give sufficient benefit.  It seems that if you're 
requesting it programmatically you'd have to do the search, get the bug IDs 
and explicitly pass them to the XML generator, though, which makes things a 
little more awkward.



Re: [gentoo-dev] Re: Marking bugs for bugday?

2010-03-06 Thread David Leverton
On Saturday 06 March 2010 15:26:10 Ioannis Aslanidis wrote:
 Well, I personally would prefer to have two keywords at least, one for
 candidates and another for confirmed bugs.

This sounds like the sort of thing Bugzilla's flags mechanism is for.

http://www.bugzilla.org/docs/2.22/html/flags-overview.html



Re: [gentoo-dev] [RFC] New eclass for x11 packages

2010-02-18 Thread David Leverton
On Thursday 18 February 2010 22:33:42 Tomáš Chvátal wrote:
   [[ ${PN} == util-macros ]] || DEPEND+= =x11-misc/util-macros-1.3.0
   [[ ${PN} == font-util ]] || DEPEND+= =media-fonts/font-util-1.1.1-r1

Do non-fonts really need font-util there?  Looks like that sets up a nice 
circular dependency.

   [[ -e ./configure.ac ]]  eautoreconf || ewarn 
 Unable to autoreconf 
the configure script. Things may fail.

That'll ewarn if configure.ac doesn't exist at all.  Doesn't eautoreconf die 
anyway if it fails, and if not, is it a good idea for failures to only give a 
warning?



Re: [gentoo-dev] [RFC] New eclass for x11 packages

2010-02-18 Thread David Leverton
On Thursday 18 February 2010 23:16:54 Tomáš Chvátal wrote:
 That || die is not for eautoreconf

 [[ -e something ]]  somethingexists || somethingisnotexisting

 For your behaviour it would have to look like this

 [[ -e something ]]  { somethingexists || die if the commands failed ; }

Do you mean that it's /supposed/ to ewarn if configure.ac doesn't exist?  Do 
you expect that to happen for X.org packages that have a configure script at 
all?  (Which IIRC is all of them; if there are any that don't have a 
configure, there's obviously no reason to worry about not being able to 
rebuild it.)



Re: [gentoo-dev] RFC: don't define ebeep and epause in eutils in EAPI 3

2010-01-17 Thread David Leverton
On Sunday 17 January 2010 20:38:48 Petteri Räty wrote:
 With GLEP 42 and proper logging of e* messages I think we shouldn't
 annoy users any more with ebeep or epause so attached is a patch only
 defines these functions for EAPIs 0, 1 and 2. Anyone have a reason to
 keep these around for EAPI 3? If not I will apply the attached patch.

The eclass-manpages comments should be updated too.



Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug

2009-12-28 Thread David Leverton
On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote:
 What all this has to do with the fact that they are just build
 dependencies? Just wondering.

They're not just build dependencies.  They're required to use the library in a 
certain way, namely to compile other programs against it.  As long as we 
don't have compile-against dependencies, the only correct way to express that 
is RDEPEND (and also DEPEND because they're /also/ needed to build the 
library itself).



Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug

2009-12-28 Thread David Leverton
On Monday 28 December 2009 21:04:01 Fabio Erculiani wrote:
 To me you are saying that DEPEND would work just fine. No?

Setting the proto as DEPEND for the library wouldn't work because a user could 
install the library, remove every DEPEND-only package and legitimately expect 
the library to continue working, including being able to build other programs 
against it.  Putting the proto in DEPEND for every package that uses the 
library isn't good because (unless the package references the proto directly) 
the fact that the proto is needed is an internal detail of the library, that 
might even change between versions, and packages using the library shouldn't 
have to know about it.



Re: [gentoo-dev] mtime preservation

2009-11-26 Thread David Leverton
2009/11/26 Brian Harring ferri...@gmail.com:
 This discussion in generall is daft.  No package can rely on
 nanonsecond resolution for installation because the most common FS out
 there (ext3) does *second* level resolution only.  As such, I can
 pretty much gurantee there is *zero* packages out there that require
 nanosecond resolution for installation.

It's possible that a package might assume that *if* nanosecond
timestamps were available on the build filesystem, then they can do
nanosecond comparisons on the installed filesystem.  That would be a
rather questionable assumption, and I'm not sure what we could do
about packages that do require that, but that's why we discuss things,
right?  To find solutions?

 It's an academic discussion, and pointless.  We don't mandate the
 filesystems PMS implementations are run on- as such we cannot make a
 gurantee to ebuilds that nanosecond resolution is available.  It's
 daft to encode in the spec NS resolution when it's essentially
 impossible to gurantee it

If we're not going to insist on preserving nanoseconds as far as
possible, then package managers should be required to explcitly clear
the nanoseconds part.  Otherwise we'll get situations where a package
works on the maintainer's machine, because it happens to use a package
manager, filesystem setup, configuration etc that happens to cause
nanoseconds to be preserved accurately, but it randomly and
mysteriously fails for users.  This is especially a concern in this
case because a maintainer can easily have no idea that he's
accidentally relying on nanoseconds being preserved - it's not
something the ebuild requests explicitly, and if the timestamps happen
to be set on his machine as the package expects, it'll just work
without any indication that there was a potential issue.

 I'm honestly not sure why we're having this discussion beyond the python 
 sucks angle.

Because some of us want to find a correct solution, not just one that
no-one's complained about yet in the context of the few filetypes that
are currently known to benefit from preservation.  Shocking, I know.



Re: [gentoo-dev] mtime preservation

2009-11-26 Thread David Leverton
2009/11/26 Brian Harring ferri...@gmail.com:
 Why is this one special?  Two out of three do this already, and it
 works.

You mean two out of three blatently ignored long-standing behaviour
and added a new feature without discussion or an EAPI bump.

 Paludis doesn't preserve mtime

You mean Paludis carefully emulated Portage behaviour, and is now
somehow being blamed for the whole matter, to the extent that people
are trying to use threats (to the effect of 'I'm going to deliberately
break packages for Paludis users) to try to get their way in the
discussion.

 and it's approach to randomly resetting mtimes

There's nothing random about it.  Files' mtimes are reset to the
current time while being merged, just as Portage did for years.



Re: [gentoo-dev] mtime preservation

2009-11-26 Thread David Leverton
On Thursday 26 November 2009 13:21:43 Brian Harring wrote:
 It was always on the todo to convert portage over to preserving mtime-
 this long predates PMS and even EAPI.

Like, for example, use deps?  Yet somehow we managed to introduce those in a 
new EAPI, instead of retroactively adding them to all EAPIs.  Why should 
mtimes be different?

 Beyond that, I presume your intention is to stir things up

I suppose you have the right to presume whatever you want.

 It's a bit ironic really.  Y'all didn't want mtime in there so it was
 left unspecified.  Now you're complaining that portage changed it's
 behaviour (2+ years after the fact) as an arguement against adding
 mtime preservation into the next eapi.

I'm certainly not arguing against adding it, I just want it to be done 
properly, and I'm expressing distaste at people trying to blame Paludis for 
the fact that it's not as easy as some people want it to be.

 I mean paludis doesn't preserve mtimes.  People aren't going out of
 their way to break paludis (and claiming so is just trolling).

I don't think anyone's talking about changing packages purely for the sake of 
break Paludis and for no other reason, but people have been talking about 
making changes that they know will break Paludis.  (Whether they've actually 
done so is a different question, but the talk, and people blaming Paludis 
both when it behaves differently from Portage and when we've taken care to 
make it behave the same as Portage only for Portage to randomly change, are 
quite irritating.)

 Just because portage did something for a few years, does not make it
 right (this is something the PMS folk have been claiming since day
 one).  So... that arguement is invalidated by your own statements.

PMS tries to document Portage behaviour as long as it's not clearly 
unreasonable and unspecifiable.  Discarding mtimes is suboptimal behaviour, 
yes, but it's coherent enough that it can't be considered a blatent bug.  
Much like the lack of use deps in older EAPIs.



Re: [gentoo-dev] FEATURES use or misuse?

2009-11-03 Thread David Leverton
On Tuesday 03 November 2009 15:48:03 Patrick Lauer wrote:
 To quote:
 FEATURES is a portage specific package manager configuration variable not
 specified in PMS and cannot reliably be used in ebuilds or eclasses.

This has been the Portage team's position for years, since long before there 
were PMS and other package managers.  See 
http://bugs.gentoo.org/show_bug.cgi?id=82513#c16 for example.



Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in xfce-base/xfconf: ChangeLog xfconf-4.6.1.ebuild

2009-10-06 Thread David Leverton
On Monday 05 October 2009 23:20:10 Ciaran McCreesh wrote:
 You probably will see some remarks about commit it, and let
 everyone else deal with the mess for years to come being the
 long-established Gentoo tradition, however.

Not to mention accuse anyone who disagrees with you of being a troll.



Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)

2009-09-04 Thread David Leverton
On Friday 04 September 2009 16:01:41 Rémi Cardona wrote:
 For instance, I'm still working on migrating all the X11 packages to the
 MIT license (mainly for cleaning purposes), but in fact, each and
 every package should have its own license file (like today) because the
 MIT license requires that we acknowledge all major contributions to the
 code. Therefore, using a template like ${PORTAGE}/licences/MIT does is
 probably not a good idea from a legal point of view.

Is that really a problem?  I admit to not being around for the original design 
decisions, but I would assume that the purpose of having LICENSE in ebuilds 
is to tell users what licence the package is under (whether or not it's 
accurate is a different matter), and the purpose of having the licences 
themselves in the tree is so that it's easy for users to look them up and 
decide whether they want to accept the conditions or not.  For that purpose, 
the exact list of credits is irrelevant.  Also, I'm not a lawyer, but I would 
think that the licence's requirement for credit is satisfied by the credits 
being included in the source code - it doesn't require acknowledgement when 
merely talking about the software or stating the fact that it's under a 
particular licence, just when distributing it.



Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

2009-08-23 Thread David Leverton
On Sunday 23 August 2009 03:39:52 Arfrever Frehtes Taifersar Arahesis wrote:
 /etc/make.profile is by default a symlink to appropriate profile directory
 in ${PORTDIR}/profiles.

Again, a detail of how Portage is configured.  PMS only covers profiles that 
are in repositories - it's up to the package manager how to deal with ones 
that are elsewhere.



Re: [gentoo-dev] profiles/info_pkgs

2009-08-23 Thread David Leverton
On Sunday 23 August 2009 18:28:46 Ulrich Mueller wrote:
 ... still contains the following entries:

app-admin/eselect-compiler
dev-util/confcache

 Both packages were punted about two years ago, so maybe it's time to
 clean up?

 Ulrich

confcache is still available in masterdriverz's overlay (although it was 
recently removed from the layman list, since he retired a while back), and ¹ 
(a Bugzilla search for bugs opened in the last year with confcache listed in 
emerge --info output) indicates that a few people still have it installed, or 
at least have in the near past, so I'd suggest keeping that one for now.  On 
the other hand, a similar search for eselect-compiler returns no results, so 
it's probably OK to drop it.

[1] 
http://bugs.gentoo.org/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=long_desc_type=substringlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=status_whiteboard_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywords=emailassigned_to1=1emailtype1=substringemail1=emailassigned_to2=1emailreporter2=1emailcc2=1emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=creation_tstype0-0-0=greaterthanvalue0-0-0=2008-08-23field0-1-0=longdesctype0-1-0=substringvalue0-1-0=dev-util%2Fconfcachefield0-2-0=longdesctype0-2-0=regexpvalue0-2-0=dev-util%2Fconfcache%3A+*[0-9]



Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

2009-08-22 Thread David Leverton
On Sunday 23 August 2009 01:26:24 Chip Parker wrote:
 So, Ciaran, if your personal reference implementation of PMS fails
 miserably when using this methodology, your argument that I won't be
 or am not affected by your attempt at changing portage is invalid.
 If you'd like to test for yourself, I'll be more than happy to tar up
 both my /etc/paludis and /etc/managed-portage for you.

You're still talking about /etc, which is still unaffected by PMS.  If Paludis 
doesn't support a feature in /etc that you want to use, then feel free to 
file a bug.  If Portage supports that feature in /etc, there's no reason why 
it needs to stop doing so, regardless of what it does or doesn't accept in 
the tree.



Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

2009-08-22 Thread David Leverton
On Sunday 23 August 2009 02:10:36 Chip Parker wrote:
 They're the same thing. It doesn't matter if the profiles directory is
 in located in /tmp or in /usr/local/portage, the behavior of paludis
 *still* doesn't support the feature that these profiles depend on and
 portage still *HAS* since before PMS was submitted to this list as an
 RFC in August of 2006.

The behaviour of Paludis doesn't matter as far as your own /etc goes, because 
you (presumably) don't use Paludis.  You're free to use whatever's supported 
by your own favourite package manager.

 Additionally, there isn't a way to define in paludis where the profiles
 actually exist outside of the repository configuration files, which means
 that in your mind, they're one and the same.

You can read minds now?  The actual reason why the profile is configured in 
the repository configuration file is that the profile used by a particular 
repository's packages is a parameter to that repository.  Not that that's 
relevant to what you do in your own /etc, as I said above.



Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

2009-08-21 Thread David Leverton
2009/8/21 Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org:
 Portage documentation has been properly fixed (and the fix will be released
 in next version) and this feature can now be used in 10.0 profiles.

No.  Changing the documentation does not retroactively change existing EAPIs.



[gentoo-dev] EAPI 3 and nonfatal die

2009-08-21 Thread David Leverton
In EAPI 3, most commands and functions provided by the package
manager automatically call die if they fail.  There's also a
new nonfatal function that can be used to suppress this
behaviour: by prefixing a function/command call with nonfatal,
the automatic die behaviour is suppressed during the executation
of that function/command.

The difficulty here is that it's not clear what nonfatal should
do to explicit die and assert calls.  On the one hand, if
nonfatal does suppress these functions, then nonfatal can be
usefully used with eclass functions - silly hypothetical example:

# eclass
escons() {
scons $...@} || die scons failed
}

# ebuild
nonfatal escons || do_something_else

On the other hand, it could be risky to change the behaviour of
existing functions like that:

do_foo() {
cd foo || die cd failed
# something that would be dangerous if run in some other directory
}

If called as nonfatal do_foo and the cd failed, do_foo
/wouldn't/ return a failure code - it would proceed with the rest
of its body and wreak all manner of havoc.

One way around this would be to add either an option to die to
explicitly tell it to respect nonfatal, or an alternative die
function.  This would allow eclasses to choose to respect
nonfatal when it's safe to do so, but without changing existing
behaviour.  The disadvantage of this is that it would require
changes to all eclass functions that could potentially use it,
plus the slight ugliness of making them handle older EAPIs as
well.

Another option would be to make die respect nonfatal by default,
and add an option that doesn't.  This wouldn't require changes to
eclasses that want the nonfatal behaviour, but it would require
some care to make sure that it was used when necessary.  A
potential advantage of this over the previous solution is that if
the force option is implemented with an environment variable,
it can be used regardless of EAPI - the previous example could be
changed to something like

do_foo() {
cd foo || DIE_FORCE=1 die cd failed
# something that would be dangerous if run in some other directory
}

Does anyone have any opinions on which of the four options (#1
make die respect nonfatal, #2 make die always die, #3 add a new
die variant that respects nonfatal, #4 make regular die respect
nonfatal, and add a new variant that doesn't) we should go with?
We should definitely get this resolved and agreed on before EAPI
3 is finalised.



[gentoo-dev] Re: EAPI 3 and nonfatal die

2009-08-21 Thread David Leverton
On Friday 21 August 2009 21:56:41 David Leverton wrote:
 A potential advantage of this over the previous solution is that if
 the force option is implemented with an environment variable,
 it can be used regardless of EAPI

...except that the previous solution could use an environment variable too, of 
course.



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

2009-07-05 Thread 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] Gentoo Council 2009/2010 - Nominations are now open

2009-06-02 Thread 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] Re: Re: Re: The fallacies of GLEP55

2009-05-24 Thread 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] Re: GLEP 55 updated

2009-05-18 Thread David Leverton
2009/5/18 Steven J Long sl...@rathaus.eclipse.co.uk:
 David Leverton wrote:

 2009/5/17 Ben de Groot yng...@gentoo.org:
 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: The fallacies of GLEP55

2009-05-17 Thread 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

2009-05-17 Thread David Leverton
2009/5/17 Ben de Groot yng...@gentoo.org:
 Ciaran McCreesh wrote:
 On Sun, 17 May 2009 23:17:57 +0200
 Ben de Groot yng...@gentoo.org 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] The fallacies of GLEP55

2009-05-16 Thread 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

2009-05-16 Thread 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] The fallacies of GLEP55

2009-05-15 Thread 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

2009-05-15 Thread 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

2009-05-14 Thread 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 maybeing 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 that, and what do we gain from it?

Aside from -scm (below), there are 

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

2009-05-10 Thread 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

2009-05-10 Thread David Leverton
On Sunday 10 May 2009 09:58:22 Ryan Hill wrote:
 On Sun, 10 May 2009 02:00:17 -0600

 Ryan Hill dirtye...@gentoo.org 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

2009-05-10 Thread 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

2009-05-10 Thread 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

2009-05-10 Thread 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] EAPI-3 draft: slot operator support

2009-04-09 Thread 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] Monthly Gentoo Council Reminder for April

2009-04-01 Thread David Leverton
2009/4/1 Mike Frysinger vap...@gentoo.org:
 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] x-modular.eclass: A modified approach to EAPI support

2009-03-08 Thread 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] USE dependencies

2009-01-04 Thread 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] Flags to punt (including: kerberos USE flag)

2008-11-03 Thread 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] Flags to punt (including: kerberos USE flag)

2008-11-01 Thread 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

2008-11-01 Thread 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] Re: Re: [gentoo-commits] gentoo-x86 commit in dev-lang/python: ChangeLog python-2.6.ebuild python-2.5.2-r6.ebuild

2008-10-15 Thread 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 $(run)
 #!/bin/bash
 P='some-crap/god-i-hate-asshats'

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

 for ((i=0;i10;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] Making built_with_use die by default with EAPI 2

2008-09-21 Thread 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] EAPI-2

2008-09-14 Thread 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] [RFC] Ability to pass arguments to src_configure/src_compile

2008-09-08 Thread 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.




  1   2   >