Robert R. Russell wrote:
> 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 for:
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 wrote:
Let EAPI be defined as (the part behind the = of) the first line of
the ebuild starting with EAPI=
>>> Uh, so horrib
Ciaran McCreesh wrote:
> Steven J Long wrote:
>> Robert R. Russell wrote:
>>
>> > 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.
>>
>
Ciaran McCreesh wrote:
> On Sat, 16 May 2009 11:27:10 +0200
> Tobias Klausmann 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.
>
Isn't tha
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
David Leverton wrote:
> 2009/5/17 Ben de Groot :
>> I think the way eapi-2 was introduced into the tree wasn't particularly
>> problematic.
>
> I think there might be a misunderstanding here. Ciaran means functions
> provided by the package manager that ebuilds can call during metadata
> generat
Ciaran McCreesh wrote:
> On Thu, 21 May 2009 19:57:49 +0200
> Arfrever Frehtes Taifersar Arahesis wrote:
>> > We always have to assume that there might not be an up to date
>> > cache. The Gentoo rsync mirrors do not always ship up to date cache,
>> > particularly if someone's just changed a wide
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 sou
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
Duncan wrote:
> Tobias Klausmann 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
> necessarily
Ciaran McCreesh wrote:
> On Sat, 16 May 2009 00:28:36 +0530
> Arun Raghavan 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
> format extensions.
AllenJB wrote:
> lx...@sabayonlinux.org wrote:
>>
>>
>> On Mon, May 25, 2009 at 3:43 PM, Alex Legler wrote:
>>> For usability's sake, please don't do this. I can imagine users getting
>>> confused over the different meanings of the @ sign.
>>>
> Personally I think the PHP namespace syntax issue
Duncan wrote:
> Thilo Bangert 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 have stat
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 anywh
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/ nee
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
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 ;-)
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 you
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
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 w
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, publ
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 pe
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 "technica
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 behaviou
Firstly, wrt probing the ebuild for EAPI=.. I'd just like to point out that
a regex is not required during the scan, and nor is restricting it to the
first N lines, though the latter may be desirable and could trivially
exclude comment and whitespace-only or empty lines.
Ciaran McCreesh wrote:
Kent Fredric wrote:
> On 19 March 2012 14:12, Steven J Long wrote:
>>
>> As for non-bash ebuilds, I have always agreed with antarus that they
>> should simply use a different extension. Adding a new extension per
>> source language is a *lot* cleaner than one per EAP
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 --
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
Rich Freeman wrote:
> On Sun, Apr 8, 2012 at 6:04 PM, Greg KH 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 clar
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 minima
Rich Freeman wrote:
> On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
> 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
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 mak
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/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 "
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 b
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?
>
New udev and separate /usr partition
In my opinion, a separate /usr partition h
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 int
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
> |doc
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
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 agr
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 c
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
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
>>
Walter Dnes wrote:
> Steven J Long wrote
>
>> who's going to either "port" udev as necessary, or maintain
>> an old version forever?
>> I will keep an old version going until the end of time.
>> dberkholz: My plan is to patch reasonable behaviour b
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.
>>
>
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 ea
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?
>
>
Ciaran McCreesh wrote:
> On Sun, 01 Apr 2012 17:04:11 +0100
> Steven J Long 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? Wher
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
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 b
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 syst
Alec Warner wrote:
> Fabio Erculiani 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 issue
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 / c
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/lv
Michał Górny wrote:
> Sometimes it is necessary for a single package to pull from multiple
> remote repositories.
> 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 support
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 eclas
lasses that largely should not be inherited by the end
> ebuild.
>
> maybe a new eclass-level keyword @INHERITED-API ? it takes a space
> delimited
> list of eclasses that are guaranteed by the API. so in distutils.eclass,
> we'd add:
> # @INHERITED-API: python
>
>
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.
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 th
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
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 := appl
On Sun, Oct 14, 2012 at 05:38:06PM +0100, Ciaran McCreesh wrote:
> "Steven J. Long" wrote:
> > On Tue, Oct 02, 2012 at 06:56:14PM +0100, Ciaran McCreesh wrote:
> > > But with the current syntax, there's no such thing as "the
> > > spec that is in
On Mon, Oct 01, 2012 at 10:15:31AM +0100, Ciaran McCreesh wrote:
> On Mon, 1 Oct 2012 02:01:32 -0700
> Brian Harring wrote:
> > Implicit labels context is build+run.
> Your rules require a handler to say "have I seen any dep: blocks
> further up the tree than my current position? If yes, handle
On Wed, Oct 31, 2012 at 11:50:13PM -0700, Diego Elio Pettenò wrote:
> Dirty experiments, no. Testing stuff that's almost ready, yes. If you
> run the tinderbox against dirty experiments, the time _I_ pour in to
> sort through the logs report bugs is wasted because they'll hit stupid
> hacks that fa
On Thu, Nov 01, 2012 at 07:32:54PM -0700, Diego Elio Pettenò wrote:
> On 01/11/2012 19:23, Steven J. Long wrote:
> > He's right tho: the topic was "Why doesn't your tinderbox work with
> > overlays?" Your response was to insult Arfrever and not actually a
On Sun, Nov 18, 2012 at 05:16:18PM +0200, Samuli Suominen wrote:
> I'm still happy enough with building udev out from systemd tree and
> letting sep. /usr consept from 90s to finally die in favour of
> simplifying the system.
It's from a lot earlier than the 90s. Perhaps we should get rid of pi
On Mon, Nov 19, 2012 at 11:52:46AM -0500, Rich Freeman wrote:
> On Mon, Nov 19, 2012 at 11:32 AM, Alec Warner wrote:
> >
> > Debian / Ubuntu have a tool that basically does this. Its
> > update-initramfs. I believe it is called from..the postinst of
> > packages that are supposed to be in the init
Christopher Head wrote:
> William Hubbs wrote:
>
> > There is a way for users to opt out if we default this to on, but I
> > think the new naming scheme has advantages over the traditional eth*
> > wlan* etc names.
>
> I think it should be taken with a grain of salt. The page mentions how
> it l
On Sat, Jan 12, 2013 William Hubbs wrote:
> Steven J. Long wrote:
> > Obviously it's good to have the functionality should you need it, but
> > again it appears that simple cases are being made complex, just to allow
> > for someone else's complex cases. Which is fa
Kevin Chadwick wrote:
> > but
> > again it appears that simple cases are being made complex, just to allow
> > for someone else's complex cases. Which is faulty logic.
>
> It's a welcome option but an important question seems to be; Why wasn't
> this picked up in the dev cycle?.
>
That would req
On Wed, Mar 06, 2013 at 06:25:38PM -0100, Carlos Silva wrote:
> + if ! use module-signing; then
> + return 1
> + fi
use module-signing || return 1
> +
> + # Check that the configuration is correct
> + KERNEL_MODSECKEY="${KERNEL_MODSECKEY:-${KV_DIR}/signing_key.priv}"
No shell field-splits (aka w
On Mon, Mar 04, 2013 at 11:21:36PM +0100, Thomas Sachau wrote:
> Michał Górny schrieb:
> > On Mon, 4 Mar 2013 11:02:40 +0100
> > Alexis Ballier wrote:
> >> you are called with ABI=sth argv[0] = your name
> >
> > I'm afraid that's the first potential point of failure. Relying
> > on argv[0] is a p
On Mon, Apr 08, 2013 at 12:30:08AM +1000, Michael Palimaka wrote:
> On 7/04/2013 16:53, Kacper Kowalik wrote:
> > On 06.04.2013 20:08, Michał Górny wrote:
> >> As far as I'm aware, we don't really have much of a patch maintenance
> >> policy in Gentoo. There a few loose rules like «don't put awfull
On Sat, Apr 13, 2013 at 03:04:51AM +0200, Michael Weber wrote:
> I'm not sure if it's a sane way to push make -j1 via
>
> src_compile() {
> cmake-multilib_src_compile -j1
> }
>
> but I detected a lack of functionality in the current
> cmake-multilib.eclass. Both cmake-utils.eclass and multili
On Mon, Apr 15, 2013 at 12:01:24PM +0100, Ciaran McCreesh wrote:
> On Mon, 15 Apr 2013 10:56:45 +
> "Aaron W. Swenson" wrote:
> > ROOT being a user set variable, having ROOT be an empty string by
> > default still does not guarantee that ROOT won't end with a
> > slash. Even if we change it so
On Mon, Apr 15, 2013 at 11:54:22AM -0700, Gregory M. Turner wrote:
> On 4/15/2013 10:31 AM, Steven J. Long wrote:
> > On Mon, Apr 15, 2013 at 12:01:24PM +0100, Ciaran McCreesh wrote:
> >> The spec guarantees that ROOT will be non-empty and end in a slash. If
> >> Portage
On Wed, Apr 24, 2013 at 01:30:25PM -0500, William Hubbs wrote:
> On Wed, Apr 24, 2013 at 02:16:51PM -0400, Rich Freeman wrote:
> > On Wed, Apr 24, 2013 at 1:54 PM, William Hubbs wrote:
> > > if we keep a dependency for a while, even behind something like
> > > IUSE="+oldnet", when we drop it, peop
On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote:
> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST.
> THIS IS NOT A POST AGAINST OPENRC.
>
> With the release of Sabayon 13.04 [1] and thanks to the efforts I put
> into the systemd-love overlay [2], systemd has become much more
> a
On Wed, May 01, 2013 at 03:14:07PM +0100, Fabio Erculiani wrote:
> On Wed, May 1, 2013 at 2:54 PM, Steven J. Long
> wrote:
> > On Wed, May 01, 2013 at 12:04:00PM +0200, Fabio Erculiani wrote:
> >> PLEASE DO NOT START A FLAME WAR AND READ ON FIRST.
> >> THI
Ambroz Bizjak wrote:
> Rich Freeman wrote:
> > Init.d scripts are programs - they could probably do just about anything.
>
> They couldn't monitor a process and restart it when it crashes, as
> specified by the restart options in the unit file. That is, without
> significant modifications in the w
Rich Freeman wrote:
> I think it really needs to be accommodated in the same way as openrc
> init.d scripts. I'm not saying that maintainers should be required to
> create them if they're missing (they don't even have to do that for
> openrc init.d scripts). However, if users or other devs contri
> William Hubbs wrote:
> > waltdnes wrote:
> >> Question... when Sun made OpenOffice depend on Java (also a Sun
> >> product) did Gentoo developers run around suggesting that Java be made a
> >> part of the core Gentoo base system? I don't think so. If a user wants
> >> to run GNOME badly enoug
William Hubbs wrote:
> Steven J. Long wrote:
> > I haven't seen anyone say that in this entire discussion, but I might have
> > missed something. "If a user wants to run GNOME, he [can] switch to systemd"
> > is clearly not saying that, so we're left
On Sat, May 25, 2013 at 11:54:48AM +0200, Luca Barbato wrote:
> I'm back to the other part of it: switching the actual init implementation.
>
> # WHY (not just edit your bootloader)
>
> Since efi at least some people started to put in the kernel the bootargs
> and we have at least few new options
> In the UEFI arena, why not simply recommend something like rEFIt
sorry should have been rEFInd: http://www.rodsbooks.com/refind/ as discussed
recently on gentoo-user@.
--
On Sat, Jun 01, 2013 at 11:03:20PM -0400, Mike Frysinger wrote:
> simple set of helpers to save/restore a variable in a limited section of code
>
> you can see an example of it in action at the end of the file where i need to
> tweak epatch (and no, doing `LC_COLLATE=C set -- ` does not work).
On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote:
> On 06/01/2013 11:23 AM, Steven J. Long wrote:
> > That's not an argument for using a symlink switcher or the
> > equivalent across the board, by any means.
>
> Your opinion.
That's not an argument f
On Mon, Jun 03, 2013 at 12:35:29AM +0200, Luca Barbato wrote:
> On 06/02/2013 08:20 PM, Steven J. Long wrote:
> > On Sun, Jun 02, 2013 at 11:15:37AM +0200, Luca Barbato wrote:
> >> On 06/01/2013 11:23 AM, Steven J. Long wrote:
> >>> That's not an argument
On Sun, Jun 02, 2013 at 08:48:23PM +0200, Fabio Erculiani wrote:
> On Sun, Jun 2, 2013 at 8:20 PM, Steven J. Long
> wrote:
> >
>
> [...]
>
> > The whole symlink/boot/fallback thing is simply a waste of technical effort.
> > And blanket "your opinion&quo
Fabio Erculiani wrote:
> - only init is currently handled by eselect-init, which is now using a
> very small wrapper POSIX shell script to redirect the calls to the
> currently running init
How does say, switching inittab format, work under this setup?
--
#friendly-coders -- We're friendly, but
On Thu, Jun 20, 2013 at 03:48:29PM -0500, William Hubbs wrote:
> On Thu, Jun 20, 2013 at 06:10:27PM +0100, Steven J. Long wrote:
> > Fabio Erculiani wrote:
> > > - only init is currently handled by eselect-init, which is now using a
> > > very small wrapper POSIX shell s
Tom Wijsman wrote:
> Greg KH wrote:
>
> > On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote:
> > > On Mon, 1 Jul 2013 14:09:57 -0500
> > > Matthew Summers wrote:
> > > > If the patchset patches the kernel's core, it doesn't matter what
> > > > CONFIG_* option is set the core kernel cod
Michael Weber wrote:
> Anthony G. Basile wrote:
> > Now I'm confused because gentoo-sources is gentoo specific. It
> > contains stuff that we need in gentoo but other distros do not
> > need, like our end-to-end support for certain xattr namespaces. If
> > you remove these then we must either 1)
Tom Wijsman wrote:
> "Steven J. Long" wrote:
> > If it does [affect the build by default] then it should never be
> > applied, unless the user specifically asks for it, imo, and the
> > resultant kernel is labelled -exp as you suggest.
>
> Yes, we are going
Walter Dnes wrote:
> Tom Wijsman wrote
> > With USE=-experimental (which will be the default) they are excluded by
> > default, after enabling that the user can exclude patches by setting
> > UNIPATCH_EXCLUDE through the package.env mechanism.
>
> Assume that there are 50 different patches avail
Tom Wijsman wrote:
> Steven J. Long wrote:
> > Tom Wijsman wrote:
> > > "Steven J. Long" wrote:
> > > > If it does [affect the build by default] then it should never be
> > > > applied, unless the user specifically asks for it, imo, and the
>
Sven Vermeulen wrote:
> I did some additional work on the style (as well as making a small wrapper
> script to simplify handling it). There are still some issues that I need to
> sort out, but I hope I can do that the coming days.
>
> I keep track of the stuff at [1], an example output can already
Tom Wijsman wrote:
> "Steven J. Long" wrote:
> > The bit about the user explicitly opting-in to 'fragile' patches still
> > is of concern, however.
>
> Why is this still of concern?
..
> My original post mentions "3) The patch should not affect
Thomas Kahle wrote:
> So far our gtest package has shipped only the compiled library and a
> bunch of helper scripts. Now bug 474454 asks for the sources to be
> installed too (or exclusively). What should we do?
>
> a) Drop the library from the ebuild and break most of the consumers who
> don't
1 - 100 of 191 matches
Mail list logo
