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
save the environment after the requested command
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 for
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 actions.
the whole point is to run arbitrary
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 secure. Security would rely on the permission
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:
1) When esudo is called, it saves the current (unprivileged) bash
On Tue, Sep 30, 2014, Jeroen Roovers wrote:
If people are that attached to herd then we should apparently fix it
instead of removing it, possibly by making it closely resemble
maintainer.
Well to do that you need to clear up that ontological discussion
which is nothing more than defining what
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 to be used for by
esudo. The steps
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, another
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 system set and is a
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 some
On Tue, Sep 16, 2014 at 07:26:06AM -0400, Rich Freeman wrote:
On Tue, Sep 16, 2014 at 6:18 AM, hasufell hasuf...@gentoo.org 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
On Wed, Sep 10, 2014 at 07:53:31AM -0400, Rich Freeman wrote:
On Wed, Sep 10, 2014 at 7:33 AM, Pacho Ramos pa...@gentoo.org wrote:
Personally I would vote for simply have a maintainer tag pointing to
the alias but we would still need to keep a list of real maintainers for
that alias as
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.
I
On Wed, Sep 03, 2014 at 03:27:15PM -0400, Rich Freeman wrote:
On Wed, Sep 3, 2014 at 2:11 PM, William Hubbs willi...@gentoo.org 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
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 to a version
that has already been
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
amd64 multilib profile, unless
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 package?
On Mon, Jul 28, 2014 at 05:49:07AM +, Martin Vaeth wrote:
hasufell hasuf...@gentoo.org 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
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.
Nor do know if that's been done already, as I
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 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, where it has
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.
The arch
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 ssuomi...@gentoo.org napisał(a):
UPower upstream removed sys-power/pm-utils support from 0.99 release
(currently unkeyworded in
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 to
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.
that's bs. people install crossdev to get a cross-compile environment
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 the cross-compilers
and that is unacceptable.
Cross
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:
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, but it
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
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@$name.service
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. These
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 the
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
get the user involved in stabilisation and AT via that bug
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 important packages that need their attention, instead of
bugs
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 work to
bugs of important packages that need
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
year, you
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
clarify.
To me
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? Without a stable tree, Gentoo is useless afaic.
It moves us closer
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
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? More vague. As are many of your philosophical
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 with a
On Sat, Jan 18, 2014 at 12:56:36AM +0100, Tom Wijsman wrote:
On Fri, 17 Jan 2014 18:28:41 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Fri, 17 Jan 2014 17:47:58 +0100
Tom Wijsman tom...@gentoo.org wrote:
Maybe we can let the package managers only perceive it as
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 you're
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 tom...@gentoo.org 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 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 believe
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 in / and
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
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, the
On Wed, Dec 11, 2013, Pavlos Ratis wrote:
On Tue, Dec 10, 2013, Pacho Ramos pa...@gentoo.org 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
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 well-aware
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 patr...@gentoo.org wrote:
On 10/14/2013 03:32 AM, William Hubbs wrote:
All,
from what I'm seeing, we should look into converting
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 at all(!).
I think the real issue
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 and
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 to before
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-completion still
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 not make us able to do it or make it a realistic goal.
But it's
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 profiles
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. Your
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
clumsy fool 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
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
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 desire
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
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,
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 be
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 the build by
default., which I later clarified with It's just
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
resultant kernel is labelled -exp as you suggest.
Yes, we
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 quantumsumm...@gentoo.org wrote:
If the patchset patches the kernel's core, it doesn't matter what
CONFIG_* option is set the core
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) maintain
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 to introduce an experimental USE flag
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 available. I
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 script to redirect the calls
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 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 for using a symlink switcher or the
equivalent
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
sl...@rathaus.eclipse.co.uk wrote:
[...]
The whole symlink/boot/fallback thing is simply a waste of technical effort.
And blanket your opinion and you didn't comment a week
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 for it either.
Firstly, we should
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@.
--
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 with an enigmatic some who
haven't
posted
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 enough, he'll
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 way
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
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
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
sl...@rathaus.eclipse.co.uk 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.
THIS IS NOT A POST AGAINST
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
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 awfully big
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
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 aball...@gentoo.org 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]
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 faulty logic.
While many packages
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 require
Christopher Head wrote:
William Hubbs willi...@gentoo.org 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
On Mon, Nov 19, 2012 at 11:52:46AM -0500, Rich Freeman wrote:
On Mon, Nov 19, 2012 at 11:32 AM, Alec Warner anta...@gentoo.org 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
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
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 answer
the point.
_Arfrever himself_ point
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 fail
On Sun, Oct 14, 2012 at 05:38:06PM +0100, Ciaran McCreesh wrote:
Steven J. Long sl...@rathaus.eclipse.co.uk 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 both. There are two specs, which
On Mon, Oct 01, 2012 at 10:15:31AM +0100, Ciaran McCreesh wrote:
On Mon, 1 Oct 2012 02:01:32 -0700
Brian Harring ferri...@gmail.com wrote:
Implicit labels context is build+run.
snip
Your rules require a handler to say have I seen any dep: blocks
further up the tree than my current position?
1 - 100 of 184 matches
Mail list logo
