Diego Elio Pettenò wrote:
> I don't believe in the future until I can see it. I'm pretty sure that's
> the same thing that they said about app-antivirus at some point (can
> somebody _kill_ that category please?!)
Since it's clearly been bothering you for a while, why haven't you done
anything,
i
Rich Freeman wrote:
> Roy Bamford wrote:
> > The open floor is a part of the openness and approachability of the
> > council. Its 60 seconds well spent, even if nobody says anything.
>
> The concern that was raised was that when it does get used it is rare
> for anything to get accomplished. The
Pacho Ramos wrote:
> How the /usr in other partition ended finally then? I though that, since
> there are a lot of things in / that rely in others in /usr, people were
> supposed to either use initramfs or busybox to get /usr mounted
As Rich said, lvm doesn't link outside rootfs so it's not an iss
On Fri, Aug 09, 2013 at 08:39:20AM +0300, Samuli Suominen wrote:
> I've always disliked unnecessary profiles, a lot, but this whole
> selecting of init plus packages supporting it plus the /usr-move issue
> the systemd maintainers are bundling together with it by forcing the
> unstandard systemd
wrote:
> It would seem to make sense if the packages are unmasked conditionally
s/ conditionally//
> in the parent, or the linux profile, and then unmasked in the profiles
> that need them. Sorry if I'm misunderstanding.
And for noise.
--
#friendly-coders -- We're friendly, but we're not /that
Rich Freeman wrote:
> In general I'd avoid any requirement to use a non-base profile.
> Obviously using the right arch/prefix profile makes sense as those are
> fundamental config changes and they're all minimalist profiles anyway.
> The issues come when you force users to use non-minimalist profi
Tom Wijsman wrote:
> Let's say that I were to develop a system with some other Gentoo devs;
> that doesn't mean we are able to make everything in the tree support
> that system, making it an usable tool for everything is unrealistic
This isn't just "any tool" though: it's the core init-system. You
On Sat, Aug 10, 2013:
Tom Wijsman wrote:
> "Steven J. Long" wrote:
>
> > The core system has to be a usable basis to build "everything" from.
>
> I do agree with this except for "shaky"; it is a nice goal to pursue...
>
> That still does
Michał Górny wrote:
> +systemd_install_serviced() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + local src=${1}
> + local service=${2}
> +
> + if [[ ! ${service} ]]; then
> + [[ ${src} == *.conf ]] || die "Source file needs .conf suffix"
I would hoist this check
On Tue, Sep 10, 2013 at 10:43:53AM +, Martin Vaeth wrote:
> Duncan <1i5t5.dun...@cox.net> wrote:
> >
> > Indeed. The general gentoo policy is that "trivial" files such as bash-
> > completions, systemd unit files, etc, aren't to be install-controlled via
> > USE flags
>
> Then why is bash-com
On Fri, Sep 13, 2013, William Hubbs wrote:
> OpenRC currently has a public api, consisting of librc and libeinfo
> (rc.h and einfo.h are the headers); however, I do not know of any
> released software that uses these, so, if there is nothing, I am
> considering making this code private to OpenRC an
On Mon, Sep 16, 2013, Rich Freeman wrote:
> On Mon, Sep 16, 2013 at 7:28 AM, Steven J. Long
> > It's only an issue at system-level when your code is dependent on what
> > the higher layer is going to do with your output, or requires a specific
> > higher layer to run a
On Mon, Oct 14, 2013 at 07:38:19AM +0800, Patrick Lauer wrote:
> On 10/14/2013 07:29 AM, Mike Gilbert wrote:
> > On Sun, Oct 13, 2013 at 7:21 PM, Patrick Lauer wrote:
> >> On 10/14/2013 03:32 AM, William Hubbs wrote:
> >>> All,
> >>>
> >>> from what I'm seeing, we should look into converting /etc/
On Tue, Dec 10, 2013, Steev Klimaszewski wrote:
> On Tue, 2013-12-10, Rich Freeman wrote:
> > On Tue, Dec 10, 2013, Steev Klimaszewski wrote:
> > > On Mon, 2013-12-09, Rich Freeman wrote:
> > > You're thinking with your x86/amd64 hat on here.
> >
> > Actually, I probably just underquoted. I am we
On Wed, Dec 11, 2013, Pavlos Ratis wrote:
> On Tue, Dec 10, 2013, Pacho Ramos wrote:
>
> > https://bugs.gentoo.org/show_bug.cgi?id=197625#c14
> >
> > This has reminded me that maybe we should switch to cronie from
> > vixie-cron as default and recommended cron provider in Handbook. Last
> > time
On Sun, Jan 05, 2014 at 04:09:12AM +, Robin H. Johnson wrote:
> Summary:
>
> gen_ld_script is removing a vital unversioned symlink from some packages, and
> this breaks libtool lt_dlopenext consumers at runtime.
> lt_dlopenext is given the basename of a library to find. In this case,
On Fri, Jan 10, 2014 Igor wrote:
> I've been using C/C++ since school it's fast, even bad code is working fast.
>
> I WOULD NEVER BELIVE PYTHON IS AS FAST AS C++ with math algorithms
> that do calculate staff and not call functions from pre-complied
> objects written in C/C++.
I would never belie
On Wed, Jan 08, 2014, Rick "Zero_Chaos" Farina wrote:
> Or we could just stop randomly moving libs across the system and
> breaking things then hackmeating things back to a "working" state with
> gen_ld_script.
>
> The whole reason for having gen_ld_script is because people wanted
> dynamic libs i
On Sun, Jan 12, 2014 at 01:53:47AM -0600, Ryan Hill wrote:
> While I'm adding USE defaults to toolchain.eclass and moving them out of the
> profiles, I thought now would be a good time to review a couple default flag
> settings.
>
> mudflap:
> This is currently enabled by default but I'd like to d
On Mon, Jan 13, 2014 at 04:15:37PM +0700, "C. Bergström" wrote:
> On 01/13/14 03:43 PM, Alexander Berntsen wrote:
> > Realistically, we have to keep updating them both in parallel. pkgcore
> > needs to be brought up to portage-level functionality,
Yeah but it already outshines under the hood: all
On Mon, Jan 13, 2014, Alexander Berntsen wrote:
> > Updating both in parallel isn't hard: once pkgcore is up to EAPI-5,
> > EAPI-6 isn't that much work (mostly bash afair.)
> If it is trivial: show us the code.
Ah that old canard. Tell you what: I hereby undertake to deliver
everything currently
On Mon, Jan 13, 2014, Ciaran McCreesh wrote:
> On Mon, 13 Jan 2014 19:27:36 +0100
> Tom Wijsman wrote:
> > > Not an API. APIs are bad. What we should have is a good set of
> > > lightweight Unix-friendly command line tools. See, for example, the
> > > "Scripting Commands" section of "man cave".
>
On Sat, Jan 18, 2014 at 12:56:36AM +0100, Tom Wijsman wrote:
> On Fri, 17 Jan 2014 18:28:41 +
> Ciaran McCreesh wrote:
>
> > On Fri, 17 Jan 2014 17:47:58 +0100
> > Tom Wijsman wrote:
> > > Maybe we can let the package managers only perceive it as keyworded
> > > or stable if all of its depen
On Mon, Jan 20, 2014, Tom Wijsman wrote:
> On Sun, 19 Jan 2014, Christopher Head wrote:
> > If stable really is falling behind and the backlog is always growing,
> > obviously something has to be done. I just don't want "something" to
> > mean "don't have a stable tree". The stable tree provides me
Tom Wijsman wrote:
> "Steven J. Long" wrote:
> > What? Without a stable tree, Gentoo is useless afaic.
>
> It moves us closer to upstream releases, a little more bleeding edge; a
> lot of users and developers run that already, it is found to be useful.
What? Mor
Please set your client not to embed people's email addresses in your
responses: it's spambait in web archives. Thanks.
Tom Wijsman wrote:
> "Steven J. Long" wrote:
> > Tom Wijsman wrote:
> > > "Steven J. Long" wrote:
> > > > What? Wit
Alec Warner wrote:
> Sorry, I work on Portage. What I'm saying is that We are free to change the
> behavior of *portage* now; rather than waiting for a new EAPI. If an ebuild
> needs to define EAPI=eapi-next to 'correctly' use XDG_*, well that is
> someone else's can of worms.
Agreed: portage can
Rich Freeman wrote:
> Jeroen Roovers wrote:
> > "Paweł Hajdan" wrote:
> >
> >> Why not allow maintainers to drop redundant stable and even ~arch
> >> keywords from their packages?
> >
> > This is standard practice already.
>
> If there is still pain then maybe we need to re-communicate this, or
>
Tom Wijsman wrote:
> "Steven J. Long" wrote:
>
> > Closing those bugs as WONTFIX is more work, and in some cases the bugs
> > would be justified, if the user is on the slow arch in question.
>
> They are less work; since it lets the slower arches move their wo
Rick "Zero_Chaos" Farina wrote:
> Andreas K. Huettel wrote:
> > in its last session the Gentoo council decided that 30 days from now the
> > entire profile tree will be updated to require EAPI=5 support.
..
> > If you are running an installation that has not been updated for more than
> > a
> >
On Wed, Feb 05, 2014 at 01:08:33AM +0100, Tom Wijsman wrote:
> On Tue, 4 Feb 2014 21:03:20 +
> "Steven J. Long" wrote:
>
> > Tom Wijsman wrote:
> >
> > > They are less work; since it lets the slower arches move their work
> > > to bugs of impo
On Fri, Feb 14, 2014 Tom Wijsman wrote:
> On Thu, 13 Feb 2014 "Steven J. Long" wrote:
>
> > > > Much better for the arch in question to field the bug, than tell
> > > > the user there is no problem, and we don't care. That way you can
> > > &g
On Sat, Mar 01, 2014 at 07:20:24AM +0200, Samuli Suominen wrote:
> If only Portage had supported checking if files from /usr were used by
> files installed to /
> Hard to create check for every case, but something like libraries and NEEDED
> entries (bug 443590) would have been a start
> But there
On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote:
> On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
> > But let's be real here: if I install something and
> > want to configure its system-wide bits, the first place I go is ALWAYS
> > /etc. When I don't find it there, with t
On Fri, Mar 07, 2014 at 09:17:20PM +0200, Samuli Suominen wrote:
> - sys-apps/systemd has it's own service to handle /dev/rfkill from
> 99-systemd.rules we don't install with sys-fs/udev:
>
> SUBSYSTEM=="rfkill", TAG+="systemd", IMPORT{builtin}="path_id",
> ENV{SYSTEMD_WANTS}+="systemd-rfkill@$nam
On Fri, Feb 28, 2014 at 09:53:57PM -0500, Rick "Zero_Chaos" Farina wrote:
> On 12/31/2013 06:43 PM, Andreas K. Huettel wrote:
> > Am Dienstag, 31. Dezember 2013, 23:30:14 schrieb Mike Gilbert:
> >> I have noticed that the arch profile directories (profiles/arch/$ARCH)
> >> are not EAPI 5 capable. T
Mike Frysinger wrote:
> Greg Turner wrote:
> > As for how to fix it, if foo-bar-baz-quux crossdev targets are at
> > ${EROOT}/usr/foo-bar-baz-quux, putting wrappers in
> > ${EROOT}/usr/foo-bar-baz-quux/cross-wrappers, or something like that,
> > seems perfectly reasonable... heck, pure speculation,
Joshua Kinard wrote:
> Basically what I am suggesting is finding a sane way to politely tell users
> who set INSTALL_MASK locally that specific to systemd/udev packages, they
> risk breaking their system if using it or migrating to it. Optionally,
> telling them the same thing if they install a pa
Mike Frysinger wrote:
> Steven J. Long wrote:
> > Mike Frysinger wrote:
> > > if they're in $PATH, then the exact location is irrelevant.
> > > they need not be in /usr/bin to cause a problem.
> > > if they're not in $PATH, then you're breaking
Tom Wijsman wrote:
> If we were to take this example to its extreme; then we would have to
> create an inventory of which INSTALL_MASK entries are good and bad for
> each ebuild, in which we cover all the files installed by that ebuild.
Why are you directing this at me? Please don't cc me off-list
Mike Frysinger wrote:
> Steven J. Long wrote:
> > Mike Frysinger wrote:
> > > Steven J. Long wrote:
> > > > The cross tools should NOT pollute the default PATH, simply because the
> > > > user happened to run crossdev at some point.
> > >
>
On Sat, May 10, 2014, Rich Freeman wrote:
> On Sat, May 10, 2014, hasufell wrote:
> > Longterm, this makes it year after year more difficult to develop
> > software for "Linux". Instead (like valve), people start to develop for
> > certain distros only (like Ubuntu), because it's just too much work
On Fri, May 30, 2014, Rick "Zero_Chaos" Farina wrote:
> On 05/30/2014 11:10 AM, Samuli Suominen wrote:
> > https://bugs.gentoo.org/show_bug.cgi?id=461828
> >
> > I'll p.mask it on amd64 profiles if noone replies soon :(
> >
>
> Please don't p.mask a working program because a config file is wrong
On Tue, May 27, 2014 at 09:57:01AM +0300, Samuli Suominen wrote:
>
> On 27/05/14 08:34, Michał Górny wrote:
> > Dnia 2014-05-26, o godz. 23:15:34
> > Samuli Suominen napisał(a):
> >
> >> UPower upstream removed sys-power/pm-utils support from 0.99 release
> >> (currently unkeyworded in tree), as
On Tue, Jun 17, 2014 at 10:56 -0400, Alexandre Rostovtsev wrote:
> All multilib packages that use pkgconfig, for one thing. (Which means almost
> all multilib packages.) Because current crossdev versions blindly install
> their
> /usr/bin/i686-pc-linux-gnu-pkg-config wrapper script, overwriting th
On Sun, Jun 15, 2014 at 03:30:10PM +0200, Michał Górny wrote:
> Dnia 2014-06-15, o godz. 07:00:15
> Rich Freeman napisał(a):
>
> > The Eclass argument goes like this:
> > Eclasses already work in every PM. Half of what we're debating is
> > already in eutils. Why move this code into the PM, wher
On Fri, Jun 20, 2014, Ian Stakenvicius wrote:
> On 19/06/14 05:20 PM, Steven J. Long wrote:
> > Well I've spent far too long at crossdev code, only to see this and
> > realise you can simply hard-mask:
> > cross-i686-pc-linux-gnu/{binutils,gcc,glibc,pkg-config} in the
On Sun, Jun 29, 2014 at 11:01:53PM -0500, William Hubbs wrote:
> On Sun, Jun 29, 2014 at 10:04:54AM -0400, Rich Freeman wrote:
> > A package that hasn't been tested AT ALL doesn't belong in ~arch.
> > Suppose the maintainer is unable to test some aspect of the package,
> > or any aspect of the pack
On Mon, Jul 28, 2014 at 05:49:07AM +, Martin Vaeth wrote:
> hasufell wrote:
> > Ulrich Mueller:
> >>
> >> I wonder if it wouldn't be saner to leave our revision syntax
> >> untouched.
>
> As already mentioned, -r1.1 is only one of several possible ways
> how to achieve the same aim; I am not
On Fri, Aug 01, 2014 at 10:36AM, Ian Stakenvicius wrote:
> On 01/08/14 05:05 AM, Steven J. Long wrote:
> > I don't know why we can't just mask cross-*/whatever in the
> > multilib profile, instead of more talk of "masking crossdev" with a
> > heavy heart.
Martin Vaeth wrote:
> Steven J. Long wrote:
Please set your client not to include email addresses (for publically
web-archived newsgroups.)
> >> > It will probably also cause confusion for comaintainers and
> >> > collaborators, especially when INSTALL_VERSION points t
On Wed, Sep 03, 2014 at 03:27:15PM -0400, Rich Freeman wrote:
> On Wed, Sep 3, 2014 at 2:11 PM, William Hubbs wrote:
> >
> > I can deprecate it. To do so, I would need to have it print out a
> > deprecation warning that would be wrong for Gentoo in the next release.
> >
> > That warning would have
On Wed, Sep 10, 2014 at 07:53:31AM -0400, Rich Freeman wrote:
> On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos wrote:
> >
> > Personally I would vote for simply have a tag pointing to
> > the alias but we would still need to keep a list of real maintainers for
> > that alias as usually not all peop
On Sun, Sep 07, 2014 at 09:03:00PM -0400, Rich Freeman wrote:
> Right now the general policy is that we don't allow unmasked (hard or
> via keywords) ebuilds in the tree if they use an scm to fetch their
> sources. There are a bunch of reasons for this, and for the most part
> they make sense.
>
On Tue, Sep 16, 2014 at 07:26:06AM -0400, Rich Freeman wrote:
> On Tue, Sep 16, 2014 at 6:18 AM, hasufell wrote:
> > Ulrich Mueller:
> >>
> >> ChangeLogs are aimed at users
> >
> > Did any1 ask them if they care?
> >
>
> I'm sure somebody will reply and say that they care.
Yup, mainly because of
On Sat, Sep 27, 2014, Luca Barbato wrote:
> On 17/09/14 14:09, Jorge Manuel B. S. Vicetto wrote:
> > On Wed, 17 Sep 2014, Luca Barbato wrote:
> >
> >> The bc utility is part of the posix tools and it might be used to build
> >> linux among the other stuff.
> >
> > Luca,
> >
> > bc is not in the sys
On Wed, Sep 24, 2014 at 09:51:31PM -0700, Zac Medico wrote:
> On 07/09/2014 07:17 AM, Michał Górny wrote:
> >>> c) 'esudo' helper [3]. This is a more generic form of (2), with
> >>> support for other potential privilege changes.
> >>
..
> > I don't think we'd use the reference 'sudo' impl. Rather s
On Mon, Sep 29, 2014, Zac Medico wrote:
> On 09/28/2014, Steven J. Long wrote:
> > On Wed, Sep 24, 2014, Zac Medico wrote:
> >> The environment doesn't necessarily have to be isolated, since we could
> >> extend the existing environment saving/loading support t
On Mon, Sep 29, 2014 at 04:05:19AM +, Jorge Manuel B. S. Vicetto wrote:
> It seems like everyone needs to "chill" a bit.
++
> On Sat, 27 Sep 2014, Tom Wijsman wrote:
> > What is really needed here is a vote by the Council on whether to add bc
> > back to the stage3. If the people do insist, a
On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote:
> On 09/29/2014 04:31 PM, Steven J. Long wrote:
> > On Mon, Sep 29, 2014, Zac Medico wrote:
> >> On 09/28/2014, Steven J. Long wrote:
> >>> On Wed, Sep 24, 2014, Zac Medico wrote:
> >>>>
On Tue, Sep 30, 2014, Jeroen Roovers wrote:
> If people are that attached to then we should apparently fix it
> instead of removing it, possibly by making it closely resemble
> .
Well to do that you need to clear up that "ontological discussion"
which is nothing more than defining what it is you'
On Fri, Oct 03, 2014 at 05:01:20AM +0200, Peter Stuge wrote:
> Steven J. Long wrote:
> > On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote:
> > > The IPC implementation that I've suggested does not involve an SUID
> > > helper, so it is much more se
Peter Stuge wrote:
> Steven J. Long wrote:
> > > It's a lot more secure to have a single well-defined privileged trust
> > > anchor (the privileged process) with a well-defined protocol, than to
> > > have built-in privilege escalation which allows arbitrary acti
On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote:
> On Sun, Sep 28, 2014 at 12:31:16PM -0400, Richard Yao wrote:
> > May I suggest an alternative? We could implement sys-virtual/posix and
> > make it depend on all packages that are not necessary for @system, but
> > are necessary fo
On Sun, Oct 05, 2014, Zac Medico wrote:
> On 10/02/2014 07:32 PM, Steven J. Long wrote:
> > On Tue, Sep 30, 2014, Zac Medico wrote:
> >>> On Mon, Sep 29, 2014, Zac Medico wrote:
> >>>> We control the shell code that launches the requested command, so we can
&
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 th
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 e
Nirbheek Chauhan wrote:
> On Sun, Jul 12, 2009 at 9:36 PM, Raúl Porcel 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 if some of
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 ecla
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 what
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 in
Ciaran McCreesh wrote:
> On Thu, 13 Aug 2009 12:50:26 + (UTC)
> Mark Bateman wrote:
>> > On Wed, 12 Aug 2009 20:41:30 +0200
>> > Tomáš Chvátal gentoo.org> wrote:
>> > > Also we should allow the stuff as directory thingus (portage
>> > > already handles it right).
>> >
>> > That's a seperate
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 wh
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?
>>>
Ciaran McCreesh wrote:
> On Thu, 13 Aug 2009 19:22:16 +0100
> Steven J Long 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
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 t
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
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 deve
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
Mike Gilbert wrote:
> On Fri, Aug 5, 2011 at 10:37 PM, William Hubbs
> 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.
>> /usr/src/linux/Documentat
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 alm
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 ]
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, yo
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
>>>
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 giv
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 ;) b
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 @@ esvn_clea
Michał Górny wrote:
> On Sun, 1 Jan 2012 08:53:26 +
> Sven Vermeulen 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 /b
Rich Freeman wrote:
> On Wed, Jan 4, 2012 at 8:50 AM, Steven J Long
> 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 sep
Michał Górny wrote:
> On Tue, 10 Jan 2012 19:14:52 +0100
> Enrico Weigelt wrote:
>
>> * Micha?? Górny schrieb:
>>
>> > Does working hard involve compiling even more packages statically?
>>
>> I guess, he means keeping udev in / ?
>
> Because adding 80 KiB of initramfs hurts so much? We shoul
Michał Górny wrote:
> On Tue, 10 Jan 2012 12:56:11 -0600
> Dale 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 is aimed at, a
101 - 191 of 191 matches
Mail list logo
