Re: [gentoo-dev] Questions about SystemD and OpenRC
On Sun, 12 Aug 2012 01:29:43 +0200 "viv...@gmail.com" wrote: > > 2. I saw on some lists that Gnome/Kde and Xfce plan to use some > > SystemD API, so does it means that we will need to install SystemD > > aside of OpenRC ? > It's not possible at the moment. systemd break non-systemd setups. Elaborate. I do my best to make it possible to be able to do at least minimal OpenRC boot when systemd is used (for fallback). Even during the time of 'systemd providing udev' systemd depended on udev-init-scripts to ensure that openrc was able to boot. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Questions about SystemD and OpenRC
On 08/07/2012 03:47 PM, Sylvain Alain wrote: Hi everyone, for a couple of months now, I see on the list some of activities about OpenRC been ported to FreeBSD or OpenRC to Debian and other stuff related to SystemD. I have some basic questions about all that : 2. I saw on some lists that Gnome/Kde and Xfce plan to use some SystemD API, so does it means that we will need to install SystemD aside of OpenRC ? For Xfce it only means that xfce4-session will try to query credentials also from systemd, not ConsoleKit alone There are no plans of removing ConsoleKit support for Xfce wrt upstream anytime soon since Xfce is committed for long-term BSD support, and the Xfce development team includes developers, from eg. OpenBSD 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps related to SystemD ? I don't understand why these desktops want to depend on a specific Sysint || ( sys-auth/consolekit sys-apps/systemd ) or something can be done if the package tries to query both via DBUS calls As in, something needs to tell PolicyKit (polkit) that you are a local user and thus grant access to eg. USB removable devices
[gentoo-dev] Re: Questions about SystemD and OpenRC
Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted:
> viv...@gmail.com wrote:
>> First problem udev/SD has is that it can't see all the file system
>> labels, for some reason it only see sda and sdb so it's able to partly
>> proceed in the boot sequence, mount / (root) but can't mount anything
>> else.
>
> What software parses the filesystem labels when you boot with openrc?
>
> (I ask because I never use labels myself.)
Short answer, mount and udev, and the kernel directly when fed that
information for root= on the kernel commandline. Openrc has basically
nothing to do with it. As such, I don't know what systemd's doing, but
if it indeed is a systemd bug, it's obviously doing /something/ rather
different... probably interacting in some unpredicted way with udev now
that they're integrating it.
Slightly more detail, quoting the mount (8) manpage:
>
It is possible to indicate a block special device using its volume LABEL
or UUID (see the -L and -U options below).
The recommended setup is to use LABEL= or UUID= tags rather
than /dev/disk/by-{label,uuid} udev symlinks in the /etc/fstab file.
The tags are more readable, robust and portable. The mount(8) command
internally uses udev symlinks, so use the symlinks in /etc/fstab has no
advantage over LABEL=/UUID=. For more details see libblkid(3).
Note that mount(8) uses UUIDs as strings. The UUIDs from command line or
fstab(5) are not converted to internal binary representation. The string
representation of the UUID should be based on lower case characters.
<
The implication of the "as strings, not converted to binary" in the last
paragraph is that mount's simply doing a dumb string match against the
appropriate /dev/disk/by-* symlink names and dereferencing the symlink
after which it can proceed as usual if there's a match. It's udev (and
thus now systemd, since they're combining) that's actually doing the
work, exposing the /dev/disk/by-* symlinks with the correct references.
As such, mount basically supports anything found in that location,
including device hardware ID (combined with partition number where
appropriate, listed in /dev/disk/by-id), the already mentioned filesystem
LABEL (/dev/disk/by-label), PARTLABEL (GPT partitions have a partition
label that's similar in function to the filesystem label, but set at gdisk
time, not mkfs time, obviously this doesn't apply to legacy MBR
partitioning), PARTUID, PATH (bus path, tho like traditional /dev/[hs]dX,
this can be dynamic and the bus paths are longer and more obtuse for
humans so there's generally little practical use for this one), and (as
the manpage mentions, partition) UUID.
It is however worth noting that PARTLABEL at least is new enough that at
least as of a couple months ago when I looked at it for my md/raid setup,
while udev passed thru the PARTLABEL for physical devices, it was NOT
doing so for partitioned md/raid devices. (That mobo died and I don't
have md/raid on the new system so I can't verify current kernel 3.6-rc1+
and udev-187-r3 PARTLABEL-on-md/raid behavior.) So while people could
setup their md/raid gpt partitions with partition-labels using gptfdisk
(aka gdisk) or whatever, and I did so, only the ones on the physical
disks showed up in udev, and at the time I was looking at it, I was
running md/raid on virtually everything, so the feature was about useless
for me.
But that does mean that if mdev or whatever creates similar /dev/disk/by-
*, that mount and friends should use it just as they would with udev,
since all they're doing is a dumb string match and symlink deref.
It'a also worth noting that the kernel's root= line can take a number of
these (I'm not sure if it can take them all), including partlabel,
according to information someone posted on the btrfs list (which I was
following at the time, before I decided btrfs was too unstable still and
that I'd wait until next year to try again). I was going to try it, but
lost interest when I found I couldn't use it with fstab for my mdraid-
based gpt partitions anyway. So all I can say is that it was reported to
work on the btrfs list, and no one contradicted it, so...
>> a) SD does not re-calculate it's deptree/services when exiting from
>> rescue shell, it still try to start the "virtual" services as fstab
>> would have never modified, a reboot is needed
>
> systemctl --system daemon-reload ?
I've not tried systemd yet nor have I yet researched it (I have the
research vaguely scheduled for next year, sometime), but thanks to both
of you for these details. Based on past experience, I expect I'm
collecting the pieces even tho I don't have context to assemble them in,
but as a result, when I /do/ research it and get that context, the pieces
I already have thanks to discussions like this, will fall into place, and
it'll be far easier to get upto speed than it would have been had I tried
going into it "cold turkey".
So while I could guess, I
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
On Sun, Aug 12, 2012 at 5:43 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted: >> >> What software parses the filesystem labels when you boot with openrc? >> >> (I ask because I never use labels myself.) > > Short answer, mount and udev, and the kernel directly when fed that > information for root= on the kernel commandline. >... > It'a also worth noting that the kernel's root= line can take a number of > these (I'm not sure if it can take them all), including partlabel, > according to information someone posted on the btrfs list I'm pretty sure that this particular part of your post is incorrect, but I'd be happy to be corrected. The kernel cannot interpret a root= parameter that doesn't reference a device node that it can't internally generate (with a devtmpfs/etc). I'm pretty sure that rules out just about anything but a physical device (not even /dev/by-uuid/...). I think that people get this confused because 99% of linux users have an initramfs (and about 2% of Gentoo users it seems), and most initramfs implementations DO interpret the root=parameter. If you specify an initramfs then the kernel actually ignores the root=parameter entirely, mounting the initramfs as root, and passing control to its init. The initramfs is expected to mount root (or not - you could just run the whole system off an initramfs I guess). Most initramfs implementations just parse the root= line on the kernel, although it is worth noting that genkernel's initramfs does not and uses real_root instead. So, I could see how many linux users might think that interpreting a complex root= parameter is a kernel function, when it is really just the fact that they use an initramfs. If somebody is running with root=LABEL=foo or something like that without an initramfs I'll happily stand corrected. Rich
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
Il 12/08/2012 11:43, Duncan ha scritto:
Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted:
viv...@gmail.com wrote:
First problem udev/SD has is that it can't see all the file system
labels, for some reason it only see sda and sdb so it's able to partly
proceed in the boot sequence, mount / (root) but can't mount anything
else.
What software parses the filesystem labels when you boot with openrc?
(I ask because I never use labels myself.)
Short answer, mount and udev, and the kernel directly when fed that
information for root= on the kernel commandline. Openrc has basically
nothing to do with it. As such, I don't know what systemd's doing, but
if it indeed is a systemd bug, it's obviously doing /something/ rather
different... probably interacting in some unpredicted way with udev now
that they're integrating it.
exactly my bet, since openrc with the _same_ (not recompiled) udev does work
Slightly more detail, quoting the mount (8) manpage:
It is possible to indicate a block special device using its volume LABEL
or UUID (see the -L and -U options below).
The recommended setup is to use LABEL= or UUID= tags rather
than /dev/disk/by-{label,uuid} udev symlinks in the /etc/fstab file.
The tags are more readable, robust and portable. The mount(8) command
internally uses udev symlinks, so use the symlinks in /etc/fstab has no
advantage over LABEL=/UUID=. For more details see libblkid(3).
Note that mount(8) uses UUIDs as strings. The UUIDs from command line or
fstab(5) are not converted to internal binary representation. The string
representation of the UUID should be based on lower case characters.
<
The implication of the "as strings, not converted to binary" in the last
paragraph is that mount's simply doing a dumb string match against the
appropriate /dev/disk/by-* symlink names and dereferencing the symlink
after which it can proceed as usual if there's a match. It's udev (and
thus now systemd, since they're combining) that's actually doing the
work, exposing the /dev/disk/by-* symlinks with the correct references.
As such, mount basically supports anything found in that location,
including device hardware ID (combined with partition number where
appropriate, listed in /dev/disk/by-id), the already mentioned filesystem
LABEL (/dev/disk/by-label), PARTLABEL (GPT partitions have a partition
label that's similar in function to the filesystem label, but set at gdisk
time, not mkfs time, obviously this doesn't apply to legacy MBR
partitioning), PARTUID, PATH (bus path, tho like traditional /dev/[hs]dX,
this can be dynamic and the bus paths are longer and more obtuse for
humans so there's generally little practical use for this one), and (as
the manpage mentions, partition) UUID.
It is however worth noting that PARTLABEL at least is new enough that at
least as of a couple months ago when I looked at it for my md/raid setup,
while udev passed thru the PARTLABEL for physical devices, it was NOT
doing so for partitioned md/raid devices. (That mobo died and I don't
have md/raid on the new system so I can't verify current kernel 3.6-rc1+
and udev-187-r3 PARTLABEL-on-md/raid behavior.) So while people could
setup their md/raid gpt partitions with partition-labels using gptfdisk
(aka gdisk) or whatever, and I did so, only the ones on the physical
disks showed up in udev, and at the time I was looking at it, I was
running md/raid on virtually everything, so the feature was about useless
for me.
But that does mean that if mdev or whatever creates similar /dev/disk/by-
*, that mount and friends should use it just as they would with udev,
since all they're doing is a dumb string match and symlink deref.
It'a also worth noting that the kernel's root= line can take a number of
these (I'm not sure if it can take them all), including partlabel,
according to information someone posted on the btrfs list (which I was
following at the time, before I decided btrfs was too unstable still and
that I'd wait until next year to try again). I was going to try it, but
lost interest when I found I couldn't use it with fstab for my mdraid-
based gpt partitions anyway. So all I can say is that it was reported to
work on the btrfs list, and no one contradicted it, so...
a) SD does not re-calculate it's deptree/services when exiting from
rescue shell, it still try to start the "virtual" services as fstab
would have never modified, a reboot is needed
systemctl --system daemon-reload ?
I've not tried systemd yet nor have I yet researched it (I have the
research vaguely scheduled for next year, sometime), but thanks to both
of you for these details. Based on past experience, I expect I'm
collecting the pieces even tho I don't have context to assemble them in,
but as a result, when I /do/ research it and get that context, the pieces
I already have thanks to discussions like this, will fall into place, and
it'll be far easier to get upto speed than it would have been had I tried
going into it "co
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
Il 12/08/2012 14:25, Rich Freeman ha scritto: On Sun, Aug 12, 2012 at 5:43 AM, Duncan<1i5t5.dun...@cox.net> wrote: Peter Stuge posted on Sun, 12 Aug 2012 02:12:38 +0200 as excerpted: What software parses the filesystem labels when you boot with openrc? (I ask because I never use labels myself.) Short answer, mount and udev, and the kernel directly when fed that information for root= on the kernel commandline. ... It'a also worth noting that the kernel's root= line can take a number of these (I'm not sure if it can take them all), including partlabel, according to information someone posted on the btrfs list I'm pretty sure that this particular part of your post is incorrect, but I'd be happy to be corrected. The kernel cannot interpret a root= parameter that doesn't reference a device node that it can't internally generate (with a devtmpfs/etc). I'm pretty sure that rules out just about anything but a physical device (not even /dev/by-uuid/...). I think that people get this confused because 99% of linux users have an initramfs (and about 2% of Gentoo users it seems), and most initramfs implementations DO interpret the root=parameter. If you specify an initramfs then the kernel actually ignores the root=parameter entirely, mounting the initramfs as root, and passing control to its init. The initramfs is expected to mount root (or not - you could just run the whole system off an initramfs I guess). Most initramfs implementations just parse the root= line on the kernel, although it is worth noting that genkernel's initramfs does not and uses real_root instead. So, I could see how many linux users might think that interpreting a complex root= parameter is a kernel function, when it is really just the fact that they use an initramfs. If somebody is running with root=LABEL=foo or something like that without an initramfs I'll happily stand corrected. Rich Yes it's incorrect, a kernel w/out initrd is not able to mount by LABEL, even with automounted /dev experienced few weeks ago.
Re: [gentoo-dev] Questions about SystemD and OpenRC
Il 12/08/2012 09:44, Michał Górny ha scritto: On Sun, 12 Aug 2012 01:29:43 +0200 "viv...@gmail.com" wrote: 2. I saw on some lists that Gnome/Kde and Xfce plan to use some SystemD API, so does it means that we will need to install SystemD aside of OpenRC ? It's not possible at the moment. systemd break non-systemd setups. Elaborate. I do my best to make it possible to be able to do at least minimal OpenRC boot when systemd is used (for fallback). Even during the time of 'systemd providing udev' systemd depended on udev-init-scripts to ensure that openrc was able to boot. enable systemd USE flag, start with openrc. Pulseaudio will break, I suspect automount will break too, worried the list will grow.
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
Rich Freeman schrieb: > So, I could see how many linux users might think that interpreting a > complex root= parameter is a kernel function, when it is really just > the fact that they use an initramfs. > > If somebody is running with root=LABEL=foo or something like that > without an initramfs I'll happily stand corrected. If your disk is GPT partitioned, then you can use root=PARTUUID=... without initramfs. Note that PARTUUID is the partition UUID, not the filesystem UUID. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Kernel calls gcc directly: fine?
If you try to launch make V=1 from the kernel source directory you will see: gcc -Wp,-MD,scripts/mod/.empty.o.d -nostdinc -isystem /usr/lib/gcc/x86_64- pc-linux-gnu/4.5.3/include -I/usr/src/linux-3.3.8-gentoo/arch/x86/include - Iarch/x86/include/generated -Iinclude -include /usr/src/linux-3.3.8- gentoo/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function- declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 - march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate- outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 - DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -fno- asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe- larger-than=2048 -fno-stack-protector -fomit-frame-pointer -Wdeclaration- after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack - DCC_HAVE_ASM_GOTO-D"KBUILD_STR(s)=#s" - D"KBUILD_BASENAME=KBUILD_STR(empty)" -D"KBUILD_MODNAME=KBUILD_STR(empty)" -c -o scripts/mod/empty.o scripts/mod/empty.c So it calls gcc directly. I see we don't like gcc called directly from the tracker[1], but this is for packages/ebuild. Should this bug block that tracker or it is invalid? [1]: https://bugs.gentoo.org/show_bug.cgi?id=cc-directly -- Agostino Sarubbo / ago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Kernel calls gcc directly: fine?
On Sun, 12 Aug 2012 16:19:59 +0200 Agostino Sarubbo wrote: > If you try to launch make V=1 from the kernel source directory you > will see: > snip < > So it calls gcc directly. Yes. That is called a default. Set CC on the make command line or set CONFIG_CROSS_COMPILE through make *config if you don't like the default. > I see we don't like gcc called directly from the tracker[1], but this > is for packages/ebuild. Should this bug block that tracker or it is > invalid? What bug (report)? The kernel build system cannot guess what compiler you want to use, so it defaults to CC=gcc. It's a feature. jer
Re: [gentoo-dev] Re: Questions about SystemD and OpenRC
On Sun, Aug 12, 2012 at 8:25 AM, Rich Freeman wrote: > I think that people get this confused because 99% of linux users have > an initramfs (and about 2% of Gentoo users it seems), and most > initramfs implementations DO interpret the root=parameter. If you > specify an initramfs then the kernel actually ignores the > root=parameter entirely, mounting the initramfs as root, and passing > control to its init. The initramfs is expected to mount root (or not > - you could just run the whole system off an initramfs I guess). Most > initramfs implementations just parse the root= line on the kernel, > although it is worth noting that genkernel's initramfs does not and > uses real_root instead. Small correction: genkernel's /init script accepts both real_root and root on the kernel command line. If real_root is not specified, the value of root is used. It seems that the real_root option is a remnant of the initrd (not intramfs) code, where root needed to be a ram disk (/dev/ram0). With initramfs, the kernel ignores root, so we are free to use it for specifying the actual root device. So, when you see grub2-mkconfig generating entries with root=..., please do not panic; this works just fine. :-)
Re: [gentoo-dev] Global Systemd USE Flag
On Wed, Aug 8, 2012 at 4:31 PM, Patrick Lauer wrote: > > equery f udev | grep udevd > > /usr/lib/systemd/systemd-udevd > > > And as long as our maintainers refuse to use the proper paths this is > just one of the little things that makes life more exciting for us. > > Can we please add some sanity back? > The gods heard your call, and have replied: > Yes, udev on non-systemd systems is in our eyes a dead end, in case you > haven't noticed it yet. I am looking forward to the day when we can drop > that support entirely. -- Lennart [1] [1] http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html
[gentoo-dev] Re: Questions about SystemD and OpenRC
Chí-Thanh Christopher Nguyễn posted on Sun, 12 Aug 2012 15:43:02 +0200 as excerpted: > Rich Freeman schrieb: >> So, I could see how many linux users might think that interpreting a >> complex root= parameter is a kernel function, when it is really just >> the fact that they use an initramfs. >> >> If somebody is running with root=LABEL=foo or something like that >> without an initramfs I'll happily stand corrected. > > If your disk is GPT partitioned, then you can use root=PARTUUID=... > without initramfs. > Note that PARTUUID is the partition UUID, not the filesystem UUID. Thanks. Note that the btrfs list discussion was in the context of gpt partlabels (and that I specifically said I don't know if the kernel takes all such assignments in root= or just that in the discussion), so it's quite possible only partlabels and partuuids are accepted, as these are found in the gpt partition table itself, which the kernel must know how to parse in general, so teaching it to parse and honor these probably wasn't /that/ much more work than teaching it to parse the table but ignore them. And the gpt handling code is new enough, it may have simply been added with/for it, without touching the legacy mbr code. Another variable may be bootloader. Grub2 has legacy linux16 loader support, as well as 32-bit "linux" support. Between that and the fact that it was designed to handle both BIOS and EFI systems, it's quite possible that the legacy 16-bit linux loader protocol doesn't support these features, while the 32-bit (and presumably 64-bit EFI) kernel loader protocol does. I've no idea what grub-legacy used, but it wouldn't surprise me if it was the legacy 16-bit loader protocol, and that feeding root=PARTID= won't work for it but will with the 32-bit loader grub2 defaults to. I really should try it one of these days and know from personal experience, but in this case, it really /is/ easier to just talk than to do, since trying it requires rebooting, so I can't simply try it in another window while I keep this post open, waiting on the result... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Kernel calls gcc directly: fine?
On Sun, Aug 12, 2012 at 9:19 AM, Agostino Sarubbo wrote: > If you try to launch make V=1 from the kernel source directory you will see: > > gcc -Wp,-MD,scripts/mod/.empty.o.d -nostdinc -isystem /usr/lib/gcc/x86_64- > pc-linux-gnu/4.5.3/include -I/usr/src/linux-3.3.8-gentoo/arch/x86/include - > Iarch/x86/include/generated -Iinclude -include /usr/src/linux-3.3.8- > gentoo/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes > -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function- > declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -m64 - > march=core2 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate- > outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 - > DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -pipe -Wno-sign-compare -fno- > asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe- > larger-than=2048 -fno-stack-protector -fomit-frame-pointer -Wdeclaration- > after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack - > DCC_HAVE_ASM_GOTO-D"KBUILD_STR(s)=#s" - > D"KBUILD_BASENAME=KBUILD_STR(empty)" -D"KBUILD_MODNAME=KBUILD_STR(empty)" -c > -o scripts/mod/empty.o scripts/mod/empty.c > > > So it calls gcc directly. > > I see we don't like gcc called directly from the tracker[1], but this is for > packages/ebuild. Should this bug block that tracker or it is invalid? > > > [1]: https://bugs.gentoo.org/show_bug.cgi?id=cc-directly > Its invalid. Kbuild has its own documented way to do cross compiles and replace out the compiler (granted only gcc works for building the official Linux tree, there has been efforts to use clang and icc but those are not mainlined). -- Doug Goldstein
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-08-12 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-08-12 23h59 UTC. Removals: net-wireless/iwl1000-ucode 2012-08-06 15:41:29 ulm kde-misc/kdocker2012-08-07 11:48:37 kensington net-misc/ferm 2012-08-07 19:16:38 kensington sys-apps/whdd 2012-08-10 14:51:56 maksbotan media-fonts/font-adobe-source-sans-pro 2012-08-12 14:32:04 ssuominen Additions: dev-perl/Sub-Exporter-Progressive 2012-08-06 11:21:07 tove dev-games/tiled 2012-08-06 14:32:28 kensington sys-firmware/iwl1000-ucode 2012-08-06 15:30:25 ulm games-arcade/retrobattle2012-08-06 16:41:53 hasufell dev-ruby/temple 2012-08-06 18:06:12 graaff x11-misc/kdocker2012-08-07 11:39:01 kensington app-text/liblangtag 2012-08-07 11:42:43 scarabeus www-servers/ocsigenserver 2012-08-07 18:32:35 aballier net-firewall/ferm 2012-08-07 19:12:37 kensington dev-ml/camldbm 2012-08-07 19:31:34 aballier profiles/releases/freebsd-9.1 2012-08-07 20:46:10 aballier dev-ml/eliom2012-08-07 20:50:07 aballier games-rpg/tmw 2012-08-07 22:19:15 hasufell dev-util/ninja 2012-08-08 03:02:16 ottxor games-strategy/dunelegacy 2012-08-09 20:44:51 hasufell media-libs/fdk-aac 2012-08-10 09:44:31 lu_zero sys-block/whdd 2012-08-10 14:47:56 maksbotan net-misc/uftp 2012-08-10 15:16:27 maksbotan x11-libs/colord-gtk 2012-08-10 19:03:00 tetromino dev-java/jcommander 2012-08-10 23:32:31 flameeyes net-analyzer/jmx2munin 2012-08-10 23:33:46 flameeyes sys-apps/gsmartcontrol 2012-08-12 12:33:40 ssuominen media-fonts/font-adobe-source-sans-pro 2012-08-12 14:19:06 ssuominen net-analyzer/gsm-receiver 2012-08-12 18:44:18 chithanh -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-wireless/iwl1000-ucode,removed,ulm,2012-08-06 15:41:29 kde-misc/kdocker,removed,kensington,2012-08-07 11:48:37 net-misc/ferm,removed,kensington,2012-08-07 19:16:38 sys-apps/whdd,removed,maksbotan,2012-08-10 14:51:56 media-fonts/font-adobe-source-sans-pro,removed,ssuominen,2012-08-12 14:32:04 Added Packages: dev-perl/Sub-Exporter-Progressive,added,tove,2012-08-06 11:21:07 dev-games/tiled,added,kensington,2012-08-06 14:32:28 sys-firmware/iwl1000-ucode,added,ulm,2012-08-06 15:30:25 games-arcade/retrobattle,added,hasufell,2012-08-06 16:41:53 dev-ruby/temple,added,graaff,2012-08-06 18:06:12 x11-misc/kdocker,added,kensington,2012-08-07 11:39:01 app-text/liblangtag,added,scarabeus,2012-08-07 11:42:43 www-servers/ocsigenserver,added,aballier,2012-08-07 18:32:35 net-firewall/ferm,added,kensington,2012-08-07 19:12:37 dev-ml/camldbm,added,aballier,2012-08-07 19:31:34 profiles/releases/freebsd-9.1,added,aballier,2012-08-07 20:46:10 dev-ml/eliom,added,aballier,2012-08-07 20:50:07 games-rpg/tmw,added,hasufell,2012-08-07 22:19:15 dev-util/ninja,added,ottxor,2012-08-08 03:02:16 games-strategy/dunelegacy,added,hasufell,2012-08-09 20:44:51 media-libs/fdk-aac,added,lu_zero,2012-08-10 09:44:31 sys-block/whdd,added,maksbotan,2012-08-10 14:47:56 net-misc/uftp,added,maksbotan,2012-08-10 15:16:27 x11-libs/colord-gtk,added,tetromino,2012-08-10 19:03:00 dev-java/jcommander,added,flameeyes,2012-08-10 23:32:31 net-analyzer/jmx2munin,added,flameeyes,2012-08-10 23:33:46 sys-apps/gsmartcontrol,added,ssuominen,2012-08-12 12:33:40 media-fonts/font-adobe-source-sans-pro,added,ssuominen,2012-08-12 14:19:06 net-analyzer/gsm-receiver,added,chithanh,2012-08-12 18:44:18 Done.
[gentoo-dev] Re: Kernel calls gcc directly: fine?
On Sun, 12 Aug 2012 16:19:59 +0200 Agostino Sarubbo wrote: > So it calls gcc directly. > > I see we don't like gcc called directly from the tracker[1], but this is for > packages/ebuild. Should this bug block that tracker or it is invalid? > > > [1]: https://bugs.gentoo.org/show_bug.cgi?id=cc-directly We have no business controlling how software is built outside the package manager. This is a make default, it's not kernel specific. -- gcc-porting you were never more here, expanse getting broader toolchain, wxwidgets though bigger boats been done by less water @ gentoo.org signature.asc Description: PGP signature
