Hi, since the whole discussion got somehow sidetracked on where and if
to install for everybody the rc system specific files for everybody
(that should be an implementation detail for the specific dohelper
IMHO), I'm back to the other part of it: switching the actual init
implementation.
# WHY
Luca Barbato wrote:
- init gets effectively switched only at boot/reboot
Please not on reboot, because an unclean shutdown shouldn't leave the
system in limbo.
On boot could work, except that it does add more steps (= more
fragility) to the boot process, which I think everyone wants to
avoid.
El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió:
Hi, since the whole discussion got somehow sidetracked on where and if
to install for everybody the rc system specific files for everybody
(that should be an implementation detail for the specific dohelper
IMHO), I'm back to the
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:
Hi, since the whole discussion got somehow sidetracked on where and if
to install for everybody the rc system specific files for everybody
(that should be an implementation detail for the specific dohelper
IMHO), I'm
On Sat, 25 May 2013 12:25:03 +0200
Peter Stuge pe...@stuge.se wrote:
I would actually expect the change to take effect immediately.
Then how would you be able to shutdown / reboot your system in a clean
way? The premise here is that when you boot with an init system you
must shutdown with that
On Sat, 25 May 2013 13:13:36 +0200
Pacho Ramos pa...@gentoo.org wrote:
I use e4rat and, for that, I need to add
init=/sbin/e4rat-preload
to my grub.conf, I guess this wouldn't change with this, no? :/
Thanks for the info!
That instead of the default will first load e4rat-preload and
Isn't eselect for cases where I might want to reconfigure something or
add configuration values such as for bash-completion, do testing with
java-vm or python implementations during development, switch opengl
implementation depending on the graphics driver loaded and whatnot.
I don't see any of
On Sat, 25 May 2013 14:29:12 +0300
Sergei Trofimovich sly...@gentoo.org wrote:
If you can't change options at boot time it's very simple to get
unbootable system.
https://bugs.gentoo.org/show_bug.cgi?id=465236#c34
In above Bug #465236 at Comment #34 the suggestion has been made to
maybe call
El sáb, 25-05-2013 a las 14:03 +0200, Tom Wijsman escribió:
On Sat, 25 May 2013 13:13:36 +0200
Pacho Ramos pa...@gentoo.org wrote:
I use e4rat and, for that, I need to add
init=/sbin/e4rat-preload
to my grub.conf, I guess this wouldn't change with this, no? :/
Thanks for the
# Justin Lecher j...@gentoo.org (25 May 2013)
# Upstream dropped support long ago
# Switch to sys-fs/aufs3 or
# sys-kernel/aufs-sources
sys-fs/aufs2
signature.asc
Description: OpenPGP digital signature
On 05/25/2013 01:29 PM, Sergei Trofimovich wrote:
If you can't change options at boot time it's very simple to get
unbootable system. Just curious, who does such systems and
how root filesystem (+ it's mount options) is expected to be
found there?
You write your bootargs in the kernel, if you
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:
since the whole discussion got somehow sidetracked [SNIP], I'm back
to the other part of it: switching the actual init implementation.
Thank you very much.
Since efi at least some people started to put in the kernel
On 05/25/2013 01:13 PM, Pacho Ramos wrote:
El sáb, 25-05-2013 a las 11:54 +0200, Luca Barbato escribió:
Hi, since the whole discussion got somehow sidetracked on where and if
to install for everybody the rc system specific files for everybody
(that should be an implementation detail for the
On 05/25/2013 02:13 PM, hasufell wrote:
Isn't eselect for cases where I might want to reconfigure something or
add configuration values such as for bash-completion, do testing with
java-vm or python implementations during development, switch opengl
implementation depending on the graphics
I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing
list, since this discussion doesn't really belong on bugzilla.
Some background copied from the bug report:
(In reply to comment #21)
(In reply to comment #19)
(In reply to comment #17)
(In reply to comment #15)
(In
El dom, 26-05-2013 a las 00:14 +0800, Ben de Groot escribió:
I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing
list, since this discussion doesn't really belong on bugzilla.
Some background copied from the bug report:
[...]
Probably your following comment in bug report
Ben, you're really just being a child here. Is that a really big problem to
add a small text file to your package?! Is that a big maintaining burden?
If you can't test it, systemd team can, just like there are arch teams to
test packages on other archs the maintainers can't. It's not something
On Sun, 26 May 2013 00:14:36 +0800
Ben de Groot yng...@gentoo.org wrote:
I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing
list, since this discussion doesn't really belong on bugzilla.
Since Bugzilla is down at the moment and it seems not to be mentioned
anywhere in the
I'd go for init=/sbin/gentoo-init and make all the messy stuff there.
Otherwise by breaking /sbin/init it would be hard to find proper
name of, say, SYSVs /sbin/init. How would you call it?
/bin/init is my idea (second in the list in linux fallback), otherwise
we can just make the
On Sat, May 25, 2013 at 12:48 PM, Michał Górny mgo...@gentoo.org wrote:
On Sun, 26 May 2013 00:14:36 +0800
Ben de Groot yng...@gentoo.org wrote:
But if a co-maintainer pushes through a change that I oppose, then
working together becomes quite difficult. In this case I opted to give
up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/25/2013 05:14 PM, Ben de Groot wrote:
But if a co-maintainer pushes through a change that I oppose, then
working together becomes quite difficult. In this case I opted to
give up maintainership.
Ben,
We've been working together, in
For those unaware, dev-util/ninja is a make-replacement created by one
of the Chromium guys at Google. Its focus is on making incremental
builds of large software faster.
In the latest chromium ebuild (chromium-29.0.1516.3), we are using ninja
instead of make. ninja auto-detects the number of
On 05/25/13 05:25, Peter Stuge wrote:
Luca Barbato wrote:
- init gets effectively switched only at boot/reboot
Please not on reboot, because an unclean shutdown shouldn't leave the
system in limbo.
On boot could work, except that it does add more steps (= more
fragility) to the boot
On Sat, May 25, 2013 15:38, Tom Wijsman wrote:
On Sat, 25 May 2013 11:54:48 +0200
Luca Barbato lu_z...@gentoo.org wrote:
SNIPPED
there's one option we forget about
here though, EFI users can build a second smaller minimally adjusted
defconfig kernel that ends up loading the default init
On Sat, 25 May 2013 14:48:30 -0400
Mike Gilbert flop...@gentoo.org wrote:
For those unaware, dev-util/ninja is a make-replacement created by one
of the Chromium guys at Google. Its focus is on making incremental
builds of large software faster.
I've no idea how this would work out, so I'm
On 05/25/2013 03:17 PM, Tom Wijsman wrote:
From an user perspective I was wondering if ninja in the Portage tree
makes use of this faster incremental builds feature. Should I expect
faster builds when trying this out?
No, you will not see any significant speed increase because we always
Sergei Trofimovich schrieb:
I guess EFI allows you to set bootargs via EFI UI.
If you have an EFI shell, then you can pass additional kernel command line
parameters via that. Passing parameters via the UI is not possible with any
of the UEFI systems that I have come across.
Best regards,
On 05/25/2013 02:13 PM, Markos Chandras wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/25/2013 05:14 PM, Ben de Groot wrote:
But if a co-maintainer pushes through a change that I oppose, then
working together becomes quite difficult. In this case I opted to
give up
On Sat, 25 May 2013 21:09:47 +0200
J. Roeleveld jo...@antarean.org wrote:
I was thinking of a default option in the eselect init part that
would remove init=/sbin/einit from the kernel boot parameters.
With the different boot loaders, it's not easy to do this consistently
everywhere; lilo !=
On Sat, May 25, 2013 at 3:53 PM, Anthony G. Basile bluen...@gentoo.org wrote:
Can I ask the systemd people to design a working solution for opting out? I
can't support this initiative without such a solution and I would be happy
to work with the systemd people to reach it, ie I'll test.
What
On Sat, May 25, 2013 at 3:53 PM, Anthony G. Basile bluen...@gentoo.org wrote:
We are moving too quickly on bug #448882 ([Tracker] packages not providing
systemd units). We should come to better consensus on systemd integration
and we were getting there with the idea of INSTALL_MASK. I don't
Rich Freeman schrieb:
Yet another stand. No offense but I'm afraid it's quite childish of you.
I don't understand why you're so proud of it. It's a bit like 'Gentoo
will play as I like. If it doesn't, then I will play against Gentoo.
And if that doesn't help, I will resent and slam the door,
On 25/05/13 03:55 PM, Tom Wijsman wrote:
I don't have init= set on my machines and it seems to
start /sbin/init. So that should be correct.
Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
On Sat, May 25, 2013 at 4:02 PM, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
Rich Freeman schrieb:
Yet another stand. No offense but I'm afraid it's quite childish of you.
I don't understand why you're so proud of it. It's a bit like 'Gentoo
will play as I like. If it doesn't, then
On Sat, 25 May 2013 22:02:26 +0200
Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote:
Rich Freeman schrieb:
Yet another stand. No offense but I'm afraid it's quite childish of you.
I don't understand why you're so proud of it. It's a bit like 'Gentoo
will play as I like. If it
On Sat, 25 May 2013 16:07:51 -0400
Alex Xu alex_y...@yahoo.ca wrote:
On 25/05/13 03:55 PM, Tom Wijsman wrote:
I don't have init= set on my machines and it seems to
start /sbin/init. So that should be correct.
Ah yeah, a quick `ps axjf | grep bin/[i]nit` indeed confirms that.
On 5/25/13 9:17 PM, Tom Wijsman wrote:
On Sat, 25 May 2013 14:48:30 -0400
Mike Gilbert flop...@gentoo.org wrote:
For those unaware, dev-util/ninja is a make-replacement created by one
of the Chromium guys at Google. Its focus is on making incremental
builds of large software faster.
I've no
On 5/25/13 6:48 PM, Michał Górny wrote:
On Sun, 26 May 2013 00:14:36 +0800
Ben de Groot yng...@gentoo.org wrote:
I'm taking this from https://bugs.gentoo.org/412697 to the dev mailing
list, since this discussion doesn't really belong on bugzilla.
Seems that *upstream* had to a bit of work in
On 05/25/2013 03:58 PM, Mike Gilbert wrote:
On Sat, May 25, 2013 at 3:53 PM, Anthony G. Basile bluen...@gentoo.org wrote:
Can I ask the systemd people to design a working solution for opting out? I
can't support this initiative without such a solution and I would be happy
to work with the
On Sat, 25 May 2013 14:48:30 -0400
Mike Gilbert flop...@gentoo.org wrote:
I'm wondering if we should create a more global function for calling
ninja in a consistent way. Maybe we should introduce a NINJAOPTS
variable for users to set in make.conf. Should we create a new eclass
for this, or
On Sat, May 25, 2013 at 01:57:39PM +0200, Tom Wijsman wrote
On Sat, 25 May 2013 12:25:03 +0200
Peter Stuge pe...@stuge.se wrote:
I would actually expect the change to take effect immediately.
Then how would you be able to shutdown / reboot your system in a clean
way? The premise here is
On 25/05/13 09:53 PM, Ryan Hill wrote:
Is NINJAOPTS a variable recognized by ninja or something that would be Gentoo
specific?
MAKEOPTS is Gentoo-specific anyways. MAKEFLAGS is parsed by at least GNU
make.
signature.asc
Description: OpenPGP digital signature
Tom Wijsman wrote:
I would actually expect the change to take effect immediately.
Then how would you be able to shutdown / reboot your system in a clean
way? The premise here is that when you boot with an init system you
must shutdown with that same init system, you can't just start one
On Sat, May 25, 2013 at 9:53 PM, Ryan Hill dirtye...@gentoo.org wrote:
On Sat, 25 May 2013 14:48:30 -0400
Mike Gilbert flop...@gentoo.org wrote:
I'm wondering if we should create a more global function for calling
ninja in a consistent way. Maybe we should introduce a NINJAOPTS
variable for
On 5/25/13 12:45 PM, Mike Gilbert wrote:
You may see small (~60 seconds) difference when compiling Chromium due
to faster target dependency resolution.
You may also see faster builds in general because ninja is designed for
very high degree of parallelization as compared to make.
From a
On Sat, 25 May 2013 22:00:36 -0400
Alex Xu alex_y...@yahoo.ca wrote:
On 25/05/13 09:53 PM, Ryan Hill wrote:
Is NINJAOPTS a variable recognized by ninja or something that would be
Gentoo specific?
MAKEOPTS is Gentoo-specific anyways. MAKEFLAGS is parsed by at least GNU
make.
Yeah, so I'm
46 matches
Mail list logo