On Tue, Oct 02, 2012 at 06:56:14PM +0100, Ciaran McCreesh wrote:
A := only makes sense for a dependency that is present both at build
time and at runtime. Currently, the only place you should be seeing
a := is on a spec that is listed in both DEPEND and RDEPEND.
Conceptually, the := applies
On Sun, Sep 30, 2012 at 03:15:18PM -0700, Brian Harring wrote:
On Wed, Sep 19, 2012 at 09:16:02AM -0400, Ian Stakenvicius wrote:
On 19/09/12 09:09 AM, Michael Orlitzky wrote:
The problem appears as we introduce more DEPEND variables (which is
what prompted the proposal, IIRC). If we have
Michał Górny wrote:
+ find ${D} -type f -name '*.la' -print0 | while read -r -d '' f;
..
+ rm -f ${f} || die
..
+ done
Don't pipe to read like that; it means the final command is in a subshell
and die is /not/ guaranteed to work correctly if called from a subshell
environment.[1]
Steven J Long wrote:
More seriously, the script doesn't actually get the correct filenames,
despite being written to handle any filename.
This doesn't actually apply in this case with -name '*.la' but it still
looks wrong, and implies one doesn't really grok the usage. *shrug*
--
#friendly
in distutils.eclass,
we'd add:
# @INHERITED-API: python
and repoman would use this to build a tree of implicit funcs to allow
w/out a direct inherit.
++ That sounds like a clean solution to me.
Steven J Long wrote:
You could maybe tighten the false-negative side by scanning all functions
defined
Mike Frysinger wrote:
..the proposal is to utilize the existing eclass documentation markers
..the metadata stays current, and we can scale better to all eclasses
if people don't properly document their eclasses, repoman might throw
false positives (warnings, not errors) about unused eclasses
Michał Górny wrote:
Sometimes it is necessary for a single package to pull from multiple
remote repositories.
snip
Another question is how to implement it API-wide. The main problem here
is that we already use multiple values for EGIT_REPO_URI to support
fallback URIs, and I'd prefer
Hey, William
William Hubbs wrote:
Steven J Long wrote:
Thing is it runs before the real init[1] so if we are using a separate
/usr partition on LVM, will it still work? I'd have thought not, since we
need the device-mapper service and there's /etc/lvm.conf to consider, but
I'll gladly
Greg KH wrote:
Steven J Long wrote:
And that is what we were discussing: possible future coupling between the
two, which is much easier to do when the sources are part of the
same package.
..
OFC you could just assure us that udev will never rely on systemd as a
design decision. I can
Alec Warner wrote:
Fabio Erculiani lx...@gentoo.org wrote:
I think expressing my own opinion about Lennart-made software is my
right, after all.
Firstly, it's almost impossible nowadays to avoid including avahi,
systemd and pulseaudio into a desktop distro so, there is no real
choice. This
William Hubbs wrote:
I'm wondering the same thing since once busybox 1.20.0 hits stable you
will be able to have a separate /usr without an initramfs quite easily
if that's what you want to do.
When you emerge this version of busybox with the sep-usr use flag, you
get a binary in / called
Greg KH wrote:
On Fri, May 04, 2012 at 03:50:24PM +0100, Steven J Long wrote:
To confirm again, that this is about without initramfs:
systemd and udev are being merged into one tarball. For the
foreseeable future, it will still build 2 separate binaries.
What happens down the road
Walter Dnes wrote:
Steven J Long wrote
dberkholz who's going to either port udev as necessary, or maintain
an old version forever?
Chainsaw I will keep an old version going until the end of time.
Chainsaw dberkholz: My plan is to patch reasonable behaviour back into
udev, and going
Mike Gilbert wrote:
On 04/22/2012 05:28 AM, Steven J Long wrote:
To clarify, the question is whether or not we support a separate /usr
_without_ mounting it early via an initramfs.
I hope that settles that particular issue.
Hmm... I see that in Zac's reply, thanks
Zac Medico wrote:
On 04/22/2012 10:55 AM, Mike Gilbert wrote:
On 04/22/2012 05:28 AM, Steven J Long wrote:
From the first reply:
To clarify, the question is whether or not we support a separate /usr
_without_ mounting it early via an initramfs.
I hope that settles that particular issue
Mike Frysinger wrote:
On Wednesday 11 April 2012 12:10:05 Steven J Long wrote:
William Hubbs wrote:
Another issue to consider is binaries that want to access things in
/usr/share/*.
I'm ignorant of which binaries do that?
off the top of my head:
Ah thanks, this is what I was after
Ciaran McCreesh wrote:
On Sun, 01 Apr 2012 17:04:11 +0100
Steven J Long sl...@rathaus.eclipse.co.uk wrote:
Ciaran McCreesh wrote:
No, what I actually say is *why* things don't work, and if it hasn't
already been explained, I say how to fix it.
Oh? Where on Earth did you do
Mike Frysinger wrote:
On Friday 04 May 2012 12:36:20 Steven J Long wrote:
Mike Frysinger wrote:
- this is why /etc/localtime is no longer a symlink to
/usr/share/zoneinfo/
- don't think that makes any difference to rescue situation.
no, but that isn't the driving factor here
Zac Medico wrote:
Steven J Long wrote:
It seems there's two major cases, with autotools or without. In either
case, epatch_user should be called after Gentoo patches have been
applied.
Why not make epatch_user set a variable to indicate that patches have
been applied, and only apply
Mike Frysinger wrote:
On Wednesday 25 April 2012 02:26:19 Steven J Long wrote:
Mike Frysinger wrote:
Paul Varner wrote:
Robin H. Johnson wrote:
Why are we keeping it? I move that we remove it. It's been replaced
by USE flags in metadata.xml for several years now.
euse from
Mike Frysinger wrote:
Paul Varner wrote:
Robin H. Johnson wrote:
Why are we keeping it? I move that we remove it. It's been replaced
by USE flags in metadata.xml for several years now.
euse from gentoolkit still uses it since it is written in bash and XML
parsing in bash can be
Mike Gilbert wrote:
On Sun, Apr 22, 2012 at 1:28 AM, Steven J Long wrote:
And again, I ask: if it were *not* about running udev without an
initramfs, then why would anyone even be discussing the possibility of
patching or forking?
Here is my interpretation: the council voted
Ulrich Mueller wrote:
| 3. New udev and separate /usr partition (30 minutes)
|
|See [4]: Decide on whether a separate /usr is still a supported
|configuration. If it is, newer udev can not be stabled and
|alternatives should be investigated. If it isn't, a lot of
|
Mike Frysinger wrote:
On Sunday 22 April 2012 00:44:11 Steven J Long wrote:
I can find nothing overriding it in portage, which makes sense, since in
general one cannot know if the package in question uses gmake
.LIBPATTERNS to link to locally-built libs. However I can't help thinking
Ryan Hill wrote:
Zac Medico wrote:
Funtoo has support for FEATURES=localpatch, which does the epatch_user
thing before src_prepare. I think it should really go after src_prepare,
in order to apply patches after those that src_prepare may apply
(avoiding possible conflicts).
I agree.
The
Zac Medico wrote:
On 04/11/2012 07:13 AM, Steven J Long wrote:
Zac Medico wrote:
On 04/10/2012 07:28 PM, Steven J Long wrote:
I suppose you could script that, but again, it just seems like a lot of
bother to implement an alternative that doesn't actually gain
anything over the traditional
Rich Freeman wrote:
On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long wrote:
That might be true for some Linux-only packages, but I really find it
hard to believe that any upstream targetting more than one OS (just
adding a BSD is enough) with software that could be considered critical
(I
Hi,
I've been working with GNU make quite a lot recently, and I came across the
.LIBPATTERNS variable. This variable means that make expands all -lname
prerequisites via a library path search of /lib and /usr/lib *before* any
command sees it. (It searches local paths set in the makefile first,
Rich Freeman wrote:
The Council has voted that Gentoo continue to support that subset,
without an initramfs.
(The subset of users being those who do not need udev before localmount.)
Citation, please?
ulm New udev and separate /usr partition
Chainsaw In my opinion, a separate /usr
Rich Freeman wrote:
On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
sl...@rathaus.eclipse.co.uk wrote:
As for the burden of ensuring that binaries installed to /{s,}bin don't
link to libs in /usr, why not just automate a QA check for that, and let
developers decide whether a fix is necessary
Zac Medico wrote:
On 04/10/2012 07:28 PM, Steven J Long wrote:
I suppose you could script that, but again, it just seems like a lot of
bother to implement an alternative that doesn't actually gain anything
over the traditional setup (plus making sure that partitions are mounted
before udev
William Hubbs wrote:
Another issue to consider is binaries that want to access things in
/usr/share/*. If a binary in /{bin,sbin} needs to access something in
/usr/share/*, you have two choices. move the binary to /usr or move the
thing it wants to access to / somewhere which would involve
Zac Medico wrote:
On 04/09/2012 11:09 AM, Steven J Long wrote:
One thing that has bothered me with the mooting of an initramfs as the
new rescue system that rootfs has traditionally been, is at the we are
told at the same time that the initramfs can be very minimal. If so, how
does
Rich Freeman wrote:
On Sun, Apr 8, 2012 at 6:04 PM, Greg KH gre...@gentoo.org wrote:
On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
The council has voted in favour of a separate /usr being supported
(5 yes, 1 no vote).
What?
Perhaps the council should be the ones to
Walter Dnes wrote:
I've also cobbled together my
own autodepclean script that check for, and optionally unmerges
unneeded stuff that was pulled in as a dependancy of a package that has
since been removed.
What advantage does it have over a standard --depclean?
--
#friendly-coders -- We're
Ciaran McCreesh wrote:
No, what I actually say is *why* things don't work, and if it hasn't
already been explained, I say how to fix it.
Oh? Where on Earth did you do that in this thread? All you've said so far is
that preserve-libs is an awful hack that doesn't really work, is
conceptually
Kent Fredric wrote:
On 19 March 2012 14:12, Steven J Long sl...@rathaus.eclipse.co.uk wrote:
As for non-bash ebuilds, I have always agreed with antarus that they
should simply use a different extension. Adding a new extension per
source language is a *lot* cleaner than one per EAPI.
Ok
Michał Górny wrote:
On Tue, 10 Jan 2012 19:14:52 +0100
Enrico Weigelt weig...@metux.de wrote:
* Micha?? Górny mgo...@gentoo.org schrieb:
Does working hard involve compiling even more packages statically?
I guess, he means keeping udev in / ?
Because adding 80 KiB of initramfs hurts
Michał Górny wrote:
On Tue, 10 Jan 2012 12:56:11 -0600
Dale rdalek1...@gmail.com wrote:
How much time does it take when the initramfs fails?
The same when rootfs fails? Only the fact that initramfs is less likely
to break than rootfs,
Seems to me for the average desktop user (who all this
Michał Górny wrote:
On Sun, 1 Jan 2012 08:53:26 +
Sven Vermeulen sw...@gentoo.org wrote:
On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote:
The goal is to deprecate /bin, /lib, /sbin and /usr/sbin. My
understanding is that they want to move software that is installed
in
Rich Freeman wrote:
On Wed, Jan 4, 2012 at 8:50 AM, Steven J Long
sl...@rathaus.eclipse.co.uk wrote:
The thing I don't understand is why it is necessary to move stuff from
/bin to /usr/bin. After all, if you're running the approved setup you
don't have a separate /usr so all the binaries
Just to point out that arithmetic context can be more efficient; no bugs,
except for a /minor/ possibility (second last comment.)
Mike Frysinger wrote:
--- eutils.eclass 14 Dec 2011 17:36:18 - 1.372
+++ eutils.eclass 14 Dec 2011 23:46:37 -
@@ -100,6 +100,54 @@
Francisco Blas Izquierdo Riera (klondike) wrote:
El 23/10/11 05:56, Steven J Long escribió:
Will we be able to switch off SSP via config, or will we have to setup
our own profile?
This should do the trick:
CFLAGS=$CFLAGS -fno-stack-protector
Well, with quotes ;) but yeah that's what I
Magnus Granberg wrote:
It's hard to keep the patches up to date when they
are not maintained upstream.
There are about 30 packages which have problems with PIE. We either add
patch to these or else use filter-flags on them.
Sounds perfectly reasonable just to filter those, and not give
Samuli Suominen wrote:
On 10/12/2011 06:30 AM, Steven J Long wrote:
Michał Górny wrote:
I don't think that passing multiple files to epatch actually improves
readability. Simple example:
# bug #123456, foo, bar
epatch ${FILESDIR}/${P}-foo.patch
# bug #234567, baz bazinga blah blah
epatch
Michał Górny wrote:
I don't think that passing multiple files to epatch actually improves
readability. Simple example:
# bug #123456, foo, bar
epatch ${FILESDIR}/${P}-foo.patch
# bug #234567, baz bazinga blah blah
epatch ${FILESDIR}/${P}-baz.patch
With multiple arguments, you can't put
Joshua Kinard wrote:
On 09/13/2011 07:24, Amadeusz Żołnowski wrote:
You don't need -n/-z with [[.
[[ $var ]] == [[ -n $var ]]
[[ ! $var ]] == [[ -z $var ]]
Also, you can usually be more succinct with [[ $var ]] || { some code; } for
the empty case (as opposed to [[ $var ]] {
Ulrich Mueller wrote:
But both sides of [[ ]] aren't symmetric, in the first place:
# When the == and != operators are used, the string to the right of
# the operator is considered a pattern and matched according to the
# rules described below under Pattern Matching.
So there's almost
Sven Vermeulen wrote:
On Fri, Aug 05, 2011 at 07:42:29PM -0500, William Hubbs wrote:
On Fri, Aug 05, 2011 at 10:06:48PM +0200, Sven Vermeulen wrote:
That said, I'm a bit hesitant to describing that we recommend it
regardless of the situation. What is wrong with describing when? At
least
Mike Gilbert wrote:
On Fri, Aug 5, 2011 at 10:37 PM, William Hubbs willi...@gentoo.org
wrote:
Not quite. It is actually inside the kernel binary. You are thinking of
an initrd.
Look at these files:
/usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt.
Brian Harring wrote:
And no, I don't think that Gentoo should fully support reduced-@system
builds, but there is no harm in making them more of a viable option.
Personally... I think gentoo should aim for it actually. Question is
how close we can get to it w/out overly burdening
Rémi Cardona wrote:
Le 18/08/2009 03:30, Steven J Long a écrit :
[snip]
Steven,
This thread was dead for more than 4 days. Yet you pick it up and you
try to pick a fight with Ciaran.
No I was answering the points he made, specifically he gave the fact that
something's not used
Ciaran McCreesh wrote:
I look forward to seeing Funtoo's creation of EAPI funtoo-2.
Well judging by your EAPI-2, I'd prefer it. Apart from USE-deps, there's
been no discussion apart from under your supervision on bugzie.
nonfatal? (or w/e it's called.) Who came up with that idea, and why did
Zac Medico wrote:
Steven J Long wrote:
Zac Medico wrote:
Steven J Long wrote:
Yeah sounds right. Perhaps a per-category bashrc split (both for
usual /etc/portage case and for overlays) might also be useful?
(Overlay admin can always test PN should the need arise.)
Maybe that's more
Ciaran McCreesh wrote:
On Thu, 13 Aug 2009 19:22:16 +0100
Steven J Long sl...@rathaus.eclipse.co.uk wrote:
PMS accurately reflects the Portage documentation and the commit
message that introduced the feature -- it's purely for use
in /etc/portage/, which is beyond the scope of PMS
Samuli Suominen wrote:
I find it very hard to commit thesedays since tree is full of
DEPEND.bad's from selinux profiles (existing ones that I didn't create).
I vote for marking these profiles as dev, instead of stable since that's
what they seem to be.
Any thoughts?
!doIt
Anyone who
Ciaran McCreesh wrote:
On Thu, 13 Aug 2009 12:50:26 + (UTC)
Mark Bateman coul...@soon.com wrote:
On Wed, 12 Aug 2009 20:41:30 +0200
Tomáš Chvátal scarabeus at gentoo.org wrote:
Also we should allow the stuff as directory thingus (portage
already handles it right).
That's a
Zac Medico wrote:
Steven J Long wrote:
Zac Medico wrote:
The specification is really the most important part, and you have to
give the -dev community an opportunity to participate in refining
the spec (via RFC email, GLEP, or whatnot).
It seems like this idea will probably serve for bug
Zac Medico wrote:
The specification is really the most important part, and you have to
give the -dev community an opportunity to participate in refining
the spec (via RFC email, GLEP, or whatnot).
It seems like this idea will probably serve for bug 179800, which is
about allowing eclasses
Nirbheek Chauhan wrote:
On Sun, Jul 12, 2009 at 9:36 PM, Raúl Porcelarmi...@gentoo.org wrote:
Also, *STOP* dropping keywords when a new dependency isn't keyworded
without filing a bug for that architecture.
Towards reducing arch load, I say that new packages should not be
added to ~arch
Sorry for delay in answering this one, been up to here with RL, and I didn't
have access to the debian and BSD bookmarks.
Sebastian Pipping wrote:
Steven J Long wrote:
You might as well use Gentoo's version specification for your internal
format, as it's the most comprehensive. The most you
I'm not answering the the points in here, much as I would like to. My bad, I
forgot that dev ML sets followup-to, stripping w/e the author puts on
there. My mail was set to followup-to project.
There's nothing stopping anyone else posting to project either, if they
believe they're not discussing
Brian Harring wrote:
In terms of involvement in PMS, frankly it's not worth it from where
I'm sitting due to ciarans behaviour.
It's not a matter of having thicker skin- it's literally a question of
worth. Is it worth trying to have a voice if it means exposing
yourself to BS behaviour?
Duncan wrote:
Wow, joke or not, this is the kind of thing that makes me glad I don't do
IRC.
Just to answer this quickly, as I think you're querying my earlier assertion
that gentoo IRC is a lot of fun?
The real point is that on IRC you can just type: /ignore asshat
and you never know that
Thomas Anderson wrote:
Steven J Long wrote:
Denis Dupeyron wrote:
This list is for technical discussions only.
I look forward to the day when that actually happens, and we are not
regaled with countless emails about technical issues that were solved 3
years ago, accompanied by juvenile
Denis Dupeyron wrote:
This list is for technical discussions only.
I look forward to the day when that actually happens, and we are not regaled
with countless emails about technical issues that were solved 3 years
ago, accompanied by juvenile insults at anyone who might disagree.
Also, public
Thomas Anderson wrote:
Tiziano Muller(dev-zero) banned igli from #-council for what he called
repeated trolling after private warnings.
This is inaccurate, and to be frank, a lie.
dev-zero was placed on /ignore by me a couple of weeks previously after
unwelcome /msg'ing wrt dev ML, that he
Richard Hughes wrote:
Sebastian Pipping wrote:
To do such mapping we need code (or a service) that does the mapping
for us and base of collected data that the service can operate on. Both
of these is project PackageMap
You might as well use Gentoo's version specification for your internal
Mike Frysinger wrote:
Roy Marples wrote:
You would have to ask the VServer team, but my understanding was they
needed to detect version of OpenRC in a container from the host before
the container is started.
if systems need crazy restrictions,
It sounded quite simple: no execution of
Roy Bamford wrote:
On 2009.06.07 10:34, Ulrich Mueller wrote:
On Sun, 07 Jun 2009, Steven J Long wrote:
I'd just like to know what the implications would be for users if
we
kept the .ebuild extension, and a new PMS were rolled out stating
that the mangler were allowed to find the EAPI
Jorge Manuel B. S. Vicetto wrote:
I'd like to second: amne solar grobian leio and darkside
and nominate: robbat2
As ever, I'm disappointed I can't nominate you, jmb.
--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Roy Bamford wrote:
I've spent some time reading all of this years emails on GLEP55 and
added a few lines to version 1.5 which is the last offical version.
Thanks for all the hard work.
My apologies for my mistaken comment at the end of the last Council meeting.
Clearly the mangler /does/ need
Duncan wrote:
Steven J Long posted:
Personally I favour restricting the EAPI='blah' line (which imo should
simply be single-quoted to avoid escaping issues, but whatever: it's
easy enough to lex in C, so I fail to see the issue lexing it anywhere
else) to before the inherit line _in_ _the_
Duncan wrote:
Thilo Bangert bang...@gentoo.org posted
200905311126.00274.bang...@gentoo.org, excerpted below, on Sun, 31 May
2009 11:25:56 +0200:
the thing is though, nothing constructive is being said. people are
going in circles. ciaran and co are pushing glep55 for reasons which
they
Duncan wrote:
Tobias Klausmann klaus...@gentoo.org posted
I was under the impression that it's illegal to change/set the EAPI
after using inherit.
The short answer, based on my understanding of posts to this point, would
be that it's illegal for Gentoo (in-tree, council decided), but not
Ciaran McCreesh wrote:
On Sat, 16 May 2009 00:28:36 +0530
Arun Raghavan ford_pref...@gentoo.org wrote:
As I've stated a long time ago, I'm for this solution. My
understanding is that there are 2 objections to this:
3) It doesn't solve the problem. It doesn't allow things like version
David Leverton wrote:
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.
Yes there's a lot
Ciaran McCreesh wrote:
On Fri, 15 May 2009 21:06:13 +0100
Steven J Long wrote:
Before an ebuild has had its metadata generated, its EAPI is
unknown. At this point, the package manager assumes EAPI 0.
With the format restriction, that everyone last year seemed happy
with, apart from
Joe Peterson wrote:
Ciaran McCreesh wrote:
3. Extend versioning rules in an EAPI - for example, addition of the
scm suffix - GLEP54 [1] or allowing more sensible version formats like
1-rc1, 1-alpha etc. to match upstream more closely.
Apart from GLEP54, I believe our versioning scheme works
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
Ciaran McCreesh wrote:
On Sat, 16 May 2009 11:27:10 +0200
Tobias Klausmann klaus...@gentoo.org wrote:
Change the spec, then.
If we change the spec, we can't do anything with the change until we're
absolutely sure that everyone's updated both their ebuilds and their
package manager for it.
Robert R. Russell wrote:
snip
If I understand the problem GLEP 55 is trying to solve correctly, it stems
from portage's assumption that an unknown EAPI is equal to EAPI 0.
No, portage will reject an ebuild with an unknown EAPI, as per the spec.
(This is important for shared overlays.) Search
Robert Bridge wrote:
Patrick Lauer wrote:
On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote:
On Thu, 14 May 2009 20:06:51 +0200
Patrick Lauer patr...@gentoo.org wrote:
Let EAPI be defined as (the part behind the = of) the first line of
the ebuild starting with EAPI=
Uh, so horribly
Ciaran McCreesh wrote:
Steven J Long wrote:
Robert R. Russell wrote:
snip
If I understand the problem GLEP 55 is trying to solve correctly,
it stems from portage's assumption that an unknown EAPI is equal to
EAPI 0.
No, portage will reject an ebuild with an unknown EAPI, as per
101 - 184 of 184 matches
Mail list logo
