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
&
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
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 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
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 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 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 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 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 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 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 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 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 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
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 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.
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 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 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 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 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 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 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 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
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.
> > >
>
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:
> > > 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
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:
> 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,
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
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: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 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 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 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
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
> >
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
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
>
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
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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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
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
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
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
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
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
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
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
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
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:
> > 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
>
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:
> > 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
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:
> 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
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
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 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
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 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 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).
> 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, 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
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
> 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
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
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
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
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, 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 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 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 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 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 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 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
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 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
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 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
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 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
1 - 100 of 191 matches
Mail list logo
