Re: [gentoo-dev] [PATCH eutils] Introduce has_iuse() for IUSE checks.
On Wed, 14 Sep 2011 17:32:37 -0700
Brian Harring wrote:
> On Thu, Sep 15, 2011 at 12:15:59AM +0100, Ciaran McCreesh wrote:
> > On Wed, 14 Sep 2011 11:19:35 -0400
> > Mike Frysinger wrote:
> > > however, why wont this work sanely in src_* or pkg_* funcs ? the
> > > env there is the one constructed by the PM which includes the
> > > merged IUSE values.
> >
> > It's not. We deliberately don't specify that the PM passes fixed up
> > values for IUSE, DEPEND etc back into the ebuild, since Portage's
> > behaviour for global variables has varied considerably over the
> > years.
>
> That's not varied; the implementation for eclass/ebuild stacking has
> been pretty consistant for phase funcs.
>
> Either way, candidate for eapi5 if it's worth ensuring it's
> accessible to the phases...
Is that actually useful? Isn't that just a waste of time serializing
all that data back, of which most isn't suitable for non-specialized
parsing?
If we really need to access ${IUSE}, I think we should go for something
IUSE-specific.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michal, On 09/14/11 10:56, Michal Hrusecky wrote: > Hi, > > new versions of eclasses after hopefully fixing most of the > comments. > The download eclass speaks about ``openSUSE Build Service'' while the other calls it the ``Open Build Service''. I note that the command line tool dev-util/osc also speaks about ``Open Build Service''. Others have remarked on this, but could you please explain why there are (going to be) ebuilds that don't/cannot use the full eclass? What numbers are we talking about? How about using open-build-service in the name of the eclass(es)? Finally, has this seen any testing in an overlay? Marijn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5xqtgACgkQp/VmCx0OL2w+aACffzDKZkDMOiKE55hh5CAS3b27 JA0AnRDZmVM3W/BuLBK0VPQEmIsYh0u6 =S84c -END PGP SIGNATURE-
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Wed, 7 Sep 2011 23:53:50 +0100 Ciaran McCreesh wrote: > On Wed, 07 Sep 2011 18:47:17 -0400 > "Aaron W. Swenson" wrote: > > I second the allowing dots in USE flag names. Definitely would be > > helpful for declaring version related USE flags. > > You know you won't be able to mention such flags in the base profile, > right? At least not for a year or more, until the base profile's eapi > can be set to something other than 0. Could you point me to at least a single program not supporting dots in useflags? My quick check shows that all PMs handle them well, quse and euse as well. The only backwards-compat issue I see is repoman complaining. But this can be changed easily. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, 15 Sep 2011 09:35:21 +0200 Michał Górny wrote: > Could you point me to at least a single program not supporting dots > in useflags? My quick check shows that all PMs handle them well, quse > and euse as well. Hrm, it's rather disappointing that they're accepted everywhere. That really shouldn't happen... My excuse for Paludis is that I never quite got around to passing in additional flags to validation of names, and dots are legal in exheres-0, so they're currently accepted everywhere. I'll probably get around to fixing that at some point. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, 15 Sep 2011 08:55:08 +0100 Ciaran McCreesh wrote: > On Thu, 15 Sep 2011 09:35:21 +0200 > Michał Górny wrote: > > Could you point me to at least a single program not supporting dots > > in useflags? My quick check shows that all PMs handle them well, > > quse and euse as well. > > Hrm, it's rather disappointing that they're accepted everywhere. That > really shouldn't happen... My excuse for Paludis is that I never quite > got around to passing in additional flags to validation of names, and > dots are legal in exheres-0, so they're currently accepted everywhere. And may I remind you that lately you deliberately changed PMS for all EAPIs to satisfy invalid paludis behavior? And you knew that it caused actual breakages. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, 15 Sep 2011 10:01:56 +0200 Michał Górny wrote: > On Thu, 15 Sep 2011 08:55:08 +0100 > Ciaran McCreesh wrote: > > On Thu, 15 Sep 2011 09:35:21 +0200 > > Michał Górny wrote: > > > Could you point me to at least a single program not supporting > > > dots in useflags? My quick check shows that all PMs handle them > > > well, quse and euse as well. > > > > Hrm, it's rather disappointing that they're accepted everywhere. > > That really shouldn't happen... My excuse for Paludis is that I > > never quite got around to passing in additional flags to validation > > of names, and dots are legal in exheres-0, so they're currently > > accepted everywhere. > > And may I remind you that lately you deliberately changed PMS for all > EAPIs to satisfy invalid paludis behavior? And you knew that it caused > actual breakages. Huh? Not sure what you're on about here. Accepting invalid input is in the "annoying because it leads to broken code appearing to work" category, which is very different from "doing the wrong thing for valid code". PMS by and large doesn't mandate validation of input (since Portage doesn't do it at all). Think of it as being like C, where dereferencing an invalid pointer might still work (so it's an error for a program to do it, but not an error for a compiler to allow such an operation to succeed), as opposed to languages like Java that require that all memory accesses be checked. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] obs eclasses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Marijn - 9:35 15.09.11 wrote: > Hi Michal, > > On 09/14/11 10:56, Michal Hrusecky wrote: > > Hi, > > > > new versions of eclasses after hopefully fixing most of the > > comments. > > > > The download eclass speaks about ``openSUSE Build Service'' while the > other calls it the ``Open Build Service''. I note that the command > line tool dev-util/osc also speaks about ``Open Build Service''. Things are a little bit complicated. Once upon a time, there were some people unhappy with the process of building packages for SUSE/openSUSE and they created server application and called it "openSUSE Build Service". As "openSUSE Build Service" is quite a long name, everybody started calling it just 'obs'. Even developers themselves. As obs supported building packages for many distributions and was open source, some other companies and organizations started using it (for example Meego). Some didn't even know what 'obs' stands for and assumed, that 'o' is for 'Open'. But some other knew and was reluctant to use it because of openSUSE in it's name. So it got renamed to 'Open Build Service' (so the 'obs' abbreviation will still work). But the original first running publicly available instance is still called 'openSUSE Build Service'. So we've got a software, which is called "Open Build Service" and tools like dev-util/osc and it's plugins (obs services - what is second eclass intended for) that works with any instance. And we've got "openSUSE Build Service" which is basically build.opensuse.org server running Open Build Service :-D And as some SUSE guys are lazy to be a good upstream, they publish some source code and packages just through the openSUSE Build Service (that's what is the first eclass good for). > Others have remarked on this, but could you please explain why there > are (going to be) ebuilds that don't/cannot use the full eclass? What > numbers are we talking about? Currently, there are two more ebuilds that can make a use of obs-download.eclass: 'dev-util/osc' and 'dev-util/suse-build'. It is not that much of code duplication, but I think it could make ebuilds more readable. > How about using open-build-service in the name of the eclass(es)? I personally dislike long file names and obs is well known abbreviation (in my google search, second link is http://guild.opensuse.org and first http://en.wikipedia.org/wiki/OBS which also list OBS as Open Build Service), although a little bit ambiguous. If it would be hard requirement for getting them in, I would consider expanding the 'obs', but personally I would prefer not to. > Finally, has this seen any testing in an overlay? Only locally - on my computer. Currently I have 3 services (osc plugins) that I needed to commit stuff with osc from git. - -- Michal Hrusecky -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iF4EAREIAAYFAk5xtNwACgkQpMQOFjUY7FXlQwEAqyoRWVzPxdq7Bf43wnPaeCXr o/jw7aKw8bCYokTEDlgA/306yyqBmePvSast4nOJJSg6KPi6QcLusC81QJJlKu9K =I8KK -END PGP SIGNATURE-
[gentoo-dev] udev and /usr
Hi Devs, Not sure if you are aware of the discussions on the gentoo-user list about the upcoming change where systemd and udev require /usr to be available prior to starting of udev. I would like to know what the position of the Gentoo developers is with regarding this and how best to deal with this. There have been several use-cases mentioned in the other list describing the need for a seperate /usr and /var partition. I also have these on seperate partitions. The use for an initrd/initramfs/... will create an additional layer of complexity a lot of us users are not really waiting for, especially as we are not seeing any issues with our current systems. It's also one extra thing that can go wrong and it is not clear how we could solve the situation where we messed something up with the initramfs and can't get to the tools in single-usermode to try and fix it. That is if we can even get access to the machine in question. I have raised a possible alternative on the other list and would like to know how you, the Developers, feel about it. My idea is, to me at least, simple. "udev" is split into 2 parts: 1) "udevd", which creates the /dev-tree based on the events it currently gets 2) "actiond" processes all the actions "udevd" puts in a seperate queue. I think that if "udevd" is started at boot-time and "actiond" only after "localmount" has finished, there shouldn't be the situation where a script in the udev-configuration fails because of missing files. Even if it does, then this can be handled in "actiond" itself and placed in a retry-queue. With a smaller udev, the chances of it failing should also be less. (less code-lines to check) and as long as the /dev-entries are created, these can be used to manually mount the other partitions to get to the point where the system can be fixed to get it back to a workable state. If, in the currently planned form, udev fails, it will be necessary to use a rescue-cd/usb to boot the system, try to fix it inside a chroot where it's not easy to check what is actually going wrong during the boot-process as the different tools can then not be run with the error-messages printed to the console. Kind regards, Joost Roeleveld
Re: [gentoo-dev] udev and /usr
On 09/15/2011 07:33 AM, Joost Roeleveld wrote: > The use for an initrd/initramfs/... will create an additional layer of > complexity a lot of us users are not really waiting for, especially as we are > not seeing any issues with our current systems. Like it or not, it's the simplest possible solution if you want separate /usr. The plan is to provide a minimal initramfs that won't contain any modules, so it won't have to be rebuilt for each kernel. See the "/usr vs. initramfs redux" thread: http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.xml -- Thanks, Zac
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 08:07:35 AM Zac Medico wrote:
> On 09/15/2011 07:33 AM, Joost Roeleveld wrote:
> > The use for an initrd/initramfs/... will create an additional layer of
> > complexity a lot of us users are not really waiting for, especially as
> > we are not seeing any issues with our current systems.
>
> Like it or not, it's the simplest possible solution if you want separate
> /usr. The plan is to provide a minimal initramfs that won't contain any
> modules, so it won't have to be rebuilt for each kernel. See the "/usr
> vs. initramfs redux" thread:
>
> http://archives.gentoo.org/gentoo-dev/msg_020fa80d72c84c5b587b90d8001264ef.x
> ml
Zac,
Thank you for your response, however, I do have a few questions about this.
Where will this default initramfs actually need to be placed? Also, how will
we be able to deal with situations where this script fails?
If Gentoo does decide to follow the initramfs-route, why not simply implement
/etc/init.d/localmount in the initramfs? Why require users to figure out which
filesystems are needed for udev?
Also, I was actually hoping for a reply to the rest of my email as well,
especially the idea for splitting udev into 2 seperate processes.
What I'm thinking off would be the following in pseudo-code:
--- process 1 ---
while(wait_for_event())
{
kevent* pkEvent = NULL;
if(get_waiting_kernel_event(pkEvent)) // returns true if an event was
waiting
{
action_event = process_kernel_event(pkEvent);
if (action_event != NULL)
{
put_action_event(pkEvent);
}
}
}
--
--- process 2 ---
while(wait_for_event())
{
aevent* paEvent = NULL;
if(get_waiting_action_event(paEvent)) // returns true if an event was
waiting
{
process_action_event(paEvent);
}
}
---
In "human" that would be:
The kernel puts events in the new-dev-event-queue that process 1 picks up.
process 1 creates the /dev-entrie(s) and, if there is an action to be taken,
puts the action in the new-action-event-queue.
Process 2 will then pick up this action from the new-action-event-queue and
will process this.
If, as a side-effect, of the action processed by process 2, a new device
appears for the kernel, the kernel will simply put a corresponding event in
the new-dev-event-queue.
I don't see why this option would be ignored. Especially as the simpler
process 1 should be smaller and as such less likely to contain bugs and any
action that needs to be taken can be done manually to test why something isn't
working correctly if the boot-process, for whatever reason, fails.
I'm not a good enough developer to do build this myself, but I am willing to
try this.
All I'm asking for is the help and advice of more experienced developers with
the design and implementation.
If someone can explain to me why my idea won't work, please let me know.
If someone actually has some ideas on how to implement it, I would really
appreciate it. My current idea is to try to split the 2 parts out of udev and
have it use the same configuration files.
Many thanks,
Joost
Re: [gentoo-dev] udev and /usr
On 09/15/2011 09:04 AM, Joost Roeleveld wrote: > Thank you for your response, however, I do have a few questions about this. > Where will this default initramfs actually need to be placed? It should be similar to how sys-apps/v86d is used for uvesafb support. It installs /usr/share/v86d/initramfs and when you configure your kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" in order to have in included in your kernel image. > Also, how will > we be able to deal with situations where this script fails? It should drop you to a minimal shell. > If Gentoo does decide to follow the initramfs-route, why not simply implement > /etc/init.d/localmount in the initramfs? I think that's pretty close to what we have planned, since the plan is to have the initramfs mount configuration stored on the root filesystem. > Why require users to figure out which > filesystems are needed for udev? Simply mount all filesystems containing files managed by the package manager with the initramfs. Anything else would expose you to the possibility of unsatisfied dependencies. > Also, I was actually hoping for a reply to the rest of my email as well, > especially the idea for splitting udev into 2 seperate processes. In essence, what your doing here is playing a game of "let's see how long we can delay the mounting of essential filesystems". If you play this game, then again, you expose yourself to the possibility of unsatisfied dependencies. Therefore, the only foolproof approach is to mount all essential filesystems as soon as possible (via initramfs). > If someone can explain to me why my idea won't work, please let me know. If your goal is to expose yourself to the possibility of unsatisfied dependencies, they your idea will achieve it. -- Thanks, Zac
[gentoo-dev] Re: [RFC] obs eclasses
Michal Hrusecky posted on Thu, 15 Sep 2011 10:18:36 +0200 as excerpted: >> How about using open-build-service in the name of the eclass(es)? > > I personally dislike long file names and obs is well known abbreviation > (in my google search, second link is http://guild.opensuse.org and first > http://en.wikipedia.org/wiki/OBS which also list OBS as Open Build > Service), although a little bit ambiguous. If it would be hard > requirement for getting them in, I would consider expanding the 'obs', > but personally I would prefer not to. Taking a hint from the existing eclass name patterns, I'd strongly urge open-build.eclass or the like, over obs.eclass, which is intuitively read as "obsolete" (or in a medical context, obstetrics), here. Similarly with its vars and functions. obs_* is simply not immediately readable to many of those who may end up looking at ebuilds using it (I'm not the only one who has mentioned it), and were it me proposing it, I'd be particularly anxious to avoid the negative implications and confusion of someone reading "obsolete" into such references. But of course I'm not the primary target audience or the person that's going to end up typing it in repeatedly, so... -- 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] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Thu, Sep 15, 2011 at 09:35:21AM +0200, Micha?? G??rny wrote: > On Wed, 7 Sep 2011 23:53:50 +0100 > Ciaran McCreesh wrote: > > > On Wed, 07 Sep 2011 18:47:17 -0400 > > "Aaron W. Swenson" wrote: > > > I second the allowing dots in USE flag names. Definitely would be > > > helpful for declaring version related USE flags. > > > > You know you won't be able to mention such flags in the base profile, > > right? At least not for a year or more, until the base profile's eapi > > can be set to something other than 0. > > Could you point me to at least a single program not supporting dots > in useflags? My quick check shows that all PMs handle them well, quse > and euse as well. pmerge -pv sys-apps/portage[it.validate.atom.use.flags.just.not.make.conf] ~harring
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 11:07 AM, Zac Medico wrote: > On 09/15/2011 07:33 AM, Joost Roeleveld wrote: > > The use for an initrd/initramfs/... will create an additional layer of > > complexity a lot of us users are not really waiting for, especially as we > are > > not seeing any issues with our current systems. > > Like it or not, it's the simplest possible solution if you want separate > /usr. The plan is to provide a minimal initramfs that won't contain any > modules, so it won't have to be rebuilt for each kernel. See the "/usr > vs. initramfs redux" thread: > > It should be noted that the alternative is to use a more full-featured initramfs like dracut, which will also be updated to support mounting /usr (it already parses /etc/fstab to remount root anyway). The minimal initramfs will not contain mdadm or lvm tools, so it is basically suitable for booting systems that don't currently require an initramfs. Of course, something like dracut is more likely to require you to rebuild the initramfs every time you update your kernel, and won't simply be a static image like the simplified one. The simplified initramfs could be compiled into the kernel as Zac suggests (this is probably the most foolproof method), or it could be loaded from /boot using the appropriate grub settings. Note that dracut does drop you to a shell if it fails (this is configurable), but by default this shell is dash, not bash. No doubt it would work fine either way, but bash is likely to be a little slower. I don't think RAM use is likely to be a problem - it should be completely de-allocated before init runs.
Re: [gentoo-dev] udev and /usr
On 15/09/2011 16:33, Joost Roeleveld wrote: > Hi Devs, > > Not sure if you are aware of the discussions on the gentoo-user list about > the > upcoming change where systemd and udev require /usr to be available prior to > starting of udev. systemd seems more and more just a support burden for no gain... lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
[gentoo-dev] x32 fun pants
ive converted my system over to x86/amd64/x32 multilib for funs. but i can see how some people wont want all three all the time. so the question is how we want to make this available to users at the release/profile level. background: x32 is a new ABI that runs on 64bit x86_64 processors. see [1]. you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+. KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. instead, reusing "amd64". only downside is the existing USE=amd64 behavior, but we can address that by making MULTILIB_ABIS a USE_EXPAND (i think this came up before with the portage multilib discussion). release wise, we could ship a single multilib stage (x86/amd64/x32) and make it easy to convert to a subset. that way we still need only one. other thoughts ? -mike [1] https://sites.google.com/site/x32abi/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 04:33:01PM +0200, Joost Roeleveld wrote: > The use for an initrd/initramfs/... will create an additional layer of > complexity a lot of us users are not really waiting for, especially as we are > not seeing any issues with our current systems. See below on the existing udev retry queue that is hiding many of the issues from you. This hidden issues are also negatively affecting boot times (failures and retries take time). > My idea is, to me at least, simple. > "udev" is split into 2 parts: > 1) "udevd", which creates the /dev-tree based on the events it currently gets > 2) "actiond" processes all the actions "udevd" puts in a seperate queue. This needs to be taken to the upstream udev list. The problem is that there is a bit of a catch-22 in running some udev rules: 0. You're going to have to declare interdependencies between ALL udev rules. This is because udev rules could be usable independently, or they could be interrelated (first rule sets some state variable or file, second one consumes it). 1. While the binary invoked by a given rule might reside entirely on a mounting that is already available, how do you ensure that the other mountpoints required by said binary are ALSO available (the bluetooth and ALSA rules actually need /var, what if you have a bluetooth keyboard? [see footnote]). 2. If the udev rule fails because the filesystem was not yet mounted, how does udev know that is safe to retry? Do we have to start declaring every file used (opened, dlopen'd, linked against) by a given rule? The upstream discussions I've been party to previously (both on lists and in person), have been trying to avoid needing a full dependency system in udev, because it's a huge degree of additional complexity. > I think that if "udevd" is started at boot-time and "actiond" only after > "localmount" has finished, there shouldn't be the situation where a script in > the udev-configuration fails because of missing files. > Even if it does, then this can be handled in "actiond" itself and placed in a > retry-queue. udev has a retry queue already, see udev-postmount: === # Run the events that failed at first udev trigger udevadm trigger --type=failed -v === (upstream is actually planning to remove it, because of problems of rules with side-effects to being run multiple times, amongst other things). > With a smaller udev, the chances of it failing should also be less. (less > code-lines to check) and as long as the /dev-entries are created, these can > be > used to manually mount the other partitions to get to the point where the > system can be fixed to get it back to a workable state. The problem is NOT in the udev codebase. It's in udev rules. Even at the rule level, it's mostly rules for packages other than udev itself. > If, in the currently planned form, udev fails, it will be necessary to use a > rescue-cd/usb to boot the system, try to fix it inside a chroot where it's > not > easy to check what is actually going wrong during the boot-process as the > different tools can then not be run with the error-messages printed to the > console. No, you're gotten the failure case wrong. Ok, so take the minimal initramfs as I proposed on this list as the "working" case. Let's say for some reason the initramfs doesn't load at all, so you have only / mounted when you go into the rootfs init. If you had a setup that was complex enough to require udev to come up for mounting /usr, you're going to end up at a real shell on your rootfs by one of the following means: - Pressing I for interactive boot, selecting shell (if you have not locked it down) - Passing init=/bin/sh to your boot loader. The problem case that does NOT exist here is anything more complicated; because if you have something like root-on-LVM, or encrypted root, you already have an initramfs. If the initramfs itself does exist, but fails to mount anything, you also get a rescue shell from the initramfs. Footnotes: -- A bluetooth keyboard as your system keyboard is a very interesting test case here. It's the only keyboard you can get on some tablet systems, because the onscreen keyboard isn't available until your graphics are running are running. I've had a media-centre box with a bluetooth keyboard in the past as well. Side-effects of having only a Bluetooth keyboard: - No ability to have ANY system input until bluetooth is online. - This means no ability to control GRUB, or activate interactive boot early on. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 signature.asc Description: Digital signature
Re: [gentoo-dev] x32 fun pants
Hi all! Is it accepted for merge into kernel mainline for 3.2? Actualy this abi looks like n32 mips abi. PS why not merge all x86 abis into one keyword? because x86_32 x86_64 x86_x32 are only abis of x86. Also we dont have different keywords for different mips abis (64bit and 32bit ones) On Thu, 15 Sep 2011 15:34:06 -0400, Mike Frysinger wrote: ive converted my system over to x86/amd64/x32 multilib for funs. but i can see how some people wont want all three all the time. so the question is how we want to make this available to users at the release/profile level. background: x32 is a new ABI that runs on 64bit x86_64 processors. see [1]. you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+. KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. instead, reusing "amd64". only downside is the existing USE=amd64 behavior, but we can address that by making MULTILIB_ABIS a USE_EXPAND (i think this came up before with the portage multilib discussion). release wise, we could ship a single multilib stage (x86/amd64/x32) and make it easy to convert to a subset. that way we still need only one. other thoughts ? -mike [1] https://sites.google.com/site/x32abi/ -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: > On 09/15/2011 09:04 AM, Joost Roeleveld wrote: > > Thank you for your response, however, I do have a few questions about > > this. Where will this default initramfs actually need to be placed? > > It should be similar to how sys-apps/v86d is used for uvesafb support. > It installs /usr/share/v86d/initramfs and when you configure your > kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" in > order to have in included in your kernel image. Will this be set somewhere globally to the initramfs automatically? And doesn't this mean that a new kernel will need to be build just to satisfy this? I'm trying to think of how best to avoid users who are not aware to get caught with non-booting systems. Wouldn't automatic inclusion into grub.conf be a better approach? Not sure if grub.conf can handle a "global" setting for initramfs. > > Also, how will > > we be able to deal with situations where this script fails? > > It should drop you to a minimal shell. But, with udev then failing, will there be the /dev-entries to mount the different partitions to fix the environment? > > If Gentoo does decide to follow the initramfs-route, why not simply > > implement /etc/init.d/localmount in the initramfs? > > I think that's pretty close to what we have planned, since the plan is > to have the initramfs mount configuration stored on the root filesystem. But still require a seperate configuration file for this? > > Why require users to figure out which > > filesystems are needed for udev? > > Simply mount all filesystems containing files managed by the package > manager with the initramfs. Anything else would expose you to the > possibility of unsatisfied dependencies. On my desktop, that would mean the following list: /usr/ /var/ /opt/ /tmp/ /opt/tmp/ > > Also, I was actually hoping for a reply to the rest of my email as well, > > especially the idea for splitting udev into 2 seperate processes. > > In essence, what your doing here is playing a game of "let's see how > long we can delay the mounting of essential filesystems". If you play > this game, then again, you expose yourself to the possibility of > unsatisfied dependencies. Therefore, the only foolproof approach is to > mount all essential filesystems as soon as possible (via initramfs). True, but I don't have any scripts configured for udev on my desktop. My server has some scripts related to Xen, and those are all under /etc/xen/... In this case, would it still be necessary to use an initramfs? > > If someone can explain to me why my idea won't work, please let me know. > > If your goal is to expose yourself to the possibility of unsatisfied > dependencies, they your idea will achieve it. No, my goal is to come up with a different solution to this problem which, on my system and possibly also on a lot of other systems, doesn't actually exist. -- Joost
Re: [gentoo-dev] x32 fun pants
On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote: > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. > instead, reusing "amd64". only downside is the existing USE=amd64 > behavior, but we can address that by making MULTILIB_ABIS a > USE_EXPAND (i think this came up before with the portage multilib > discussion). Hrm, wouldn't that be more like x86 keyword? AFAICS the type sizes for x86 and x32 would match. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Thu, 15 Sep 2011 22:03:53 +0200 Joost Roeleveld wrote: > I'm trying to think of how best to avoid users who are not aware to > get caught with non-booting systems. Guess we could try to detect a few common cases and die in pkg_setup() whenever the failure is imminent. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 4:03 PM, Joost Roeleveld wrote: > On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: > > It should be similar to how sys-apps/v86d is used for uvesafb support. > > It installs /usr/share/v86d/initramfs and when you configure your > > kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" in > > order to have in included in your kernel image. > > Will this be set somewhere globally to the initramfs automatically? > And doesn't this mean that a new kernel will need to be build just to > satisfy > this? > > I'm trying to think of how best to avoid users who are not aware to get > caught > with non-booting systems. > > Wouldn't automatic inclusion into grub.conf be a better approach? Not sure > if > grub.conf can handle a "global" setting for initramfs. > > Well, the only way to set a kernel config parameter is to rebuild the kernel. There might be some way to extract the built-in initramfs (every kernel has one) and replace it with the new one without rebuilding it, but I doubt most users would prefer that we mount /boot and start modifying their kernel images. Changes to grub.conf will only be properly merged if /boot is mounted, if grub is installed (don't laugh - I checked and since my system was migrated so many times I don't actually have the package installed any longer), and the user actually merges the changes in. Fiddling with grub.conf isn't exactly risk-free either. I think something like this is best handled via news. Note also that depending on your definition of "broken" the separate /usr situation is already broken. It will probably steadily become more broken over time, so when it stops booting altogether for any particular user might happen anytime from a year ago to never. Rich
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 10:03:53PM +0200, Joost Roeleveld wrote: > On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: > > On 09/15/2011 09:04 AM, Joost Roeleveld wrote: > > > Thank you for your response, however, I do have a few questions about > > > this. Where will this default initramfs actually need to be placed? > > > > It should be similar to how sys-apps/v86d is used for uvesafb support. > > It installs /usr/share/v86d/initramfs and when you configure your > > kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" in > > order to have in included in your kernel image. > Will this be set somewhere globally to the initramfs automatically? > And doesn't this mean that a new kernel will need to be build just to satisfy > this? > > I'm trying to think of how best to avoid users who are not aware to get > caught > with non-booting systems. > > Wouldn't automatic inclusion into grub.conf be a better approach? Not sure if > grub.conf can handle a "global" setting for initramfs. Grub doesn't support a global initramfs setting, but you can build a static initramfs for v86d if needed. > > > Also, how will > > > we be able to deal with situations where this script fails? > > It should drop you to a minimal shell. > But, with udev then failing, will there be the /dev-entries to mount the > different partitions to fix the environment? Yes, /dev is provided by devtmpfs already, and that is populated by the kernel. > > > If Gentoo does decide to follow the initramfs-route, why not simply > > > implement /etc/init.d/localmount in the initramfs? > > I think that's pretty close to what we have planned, since the plan is > > to have the initramfs mount configuration stored on the root filesystem. > But still require a seperate configuration file for this? The configuration file isn't actually required, but it's there in case you want to specify MORE filesystems to mount before switching to the rootfs init. There are two files to load from the rootfs: 1. /etc/fstab 2. /etc/minimal-filesystems.cfg [exact name undecided] The list is in the second file, just one mountpoint per line. Defaults to /usr, /var If the file is not available, the default is also /usr, /var. For each filesystem for the minimal list, use the line from fstab to mount it. This covers getting the device, mountpoint and mount options. There is a catch to this: If those non-root filesystems live on LVM or something complex, you're going to need to use a more advanced initramfs, genkernel/dracut/roll-your-own. > On my desktop, that would mean the following list: > /usr/ > /var/ Only these two should be needed to early-boot the system successfully. > True, but I don't have any scripts configured for udev on my desktop. > My server has some scripts related to Xen, and those are all under > /etc/xen/... > > In this case, would it still be necessary to use an initramfs? Where is /usr, and do you have any udev rules that need /var? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 09:31:45 PM Luca Barbato wrote: > On 15/09/2011 16:33, Joost Roeleveld wrote: > > Hi Devs, > > > > Not sure if you are aware of the discussions on the gentoo-user list > > about the upcoming change where systemd and udev require /usr to be > > available prior to starting of udev. > > systemd seems more and more just a support burden for no gain... Myself and a lot of others on the gentoo-user list agree with this. Especially as there are plenty of installations where udev works without /usr mounted. -- Joost
Re: [gentoo-dev] x32 fun pants
On Thursday, September 15, 2011 16:12:00 Michał Górny wrote: > On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote: > > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. > > instead, reusing "amd64". only downside is the existing USE=amd64 > > behavior, but we can address that by making MULTILIB_ABIS a > > USE_EXPAND (i think this came up before with the portage multilib > > discussion). > > Hrm, wouldn't that be more like x86 keyword? AFAICS the type sizes for > x86 and x32 would match. the sizeof(long) and sizeof(void*) are the same between x86 and x32. however, that's about the only thing. for example, x32 gets access to 64bit registers when working with 64bit types (long long) and the tuple is x86_64-pc-linux- gnu. in general, it seems to be closer to amd64 than x32. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] udev and /usr
On 09/15/2011 01:03 PM, Joost Roeleveld wrote: > On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: >> On 09/15/2011 09:04 AM, Joost Roeleveld wrote: >>> Thank you for your response, however, I do have a few questions about >>> this. Where will this default initramfs actually need to be placed? >> >> It should be similar to how sys-apps/v86d is used for uvesafb support. >> It installs /usr/share/v86d/initramfs and when you configure your >> kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" in >> order to have in included in your kernel image. > > Will this be set somewhere globally to the initramfs automatically? > And doesn't this mean that a new kernel will need to be build just to satisfy > this? You could also pass it as an initrd via your bootloader, like rich0 said in his reply. > I'm trying to think of how best to avoid users who are not aware to get > caught > with non-booting systems. > > Wouldn't automatic inclusion into grub.conf be a better approach? Not sure if > grub.conf can handle a "global" setting for initramfs. Maybe so. I'm not involved the implementation. I was just telling you the obvious stuff that I've gleaned from the discussions. >>> Also, how will >>> we be able to deal with situations where this script fails? >> >> It should drop you to a minimal shell. > > But, with udev then failing, will there be the /dev-entries to mount the > different partitions to fix the environment? I the preferred approach is to enable CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y, so that the kernel populates /dev for you automatically. >>> If Gentoo does decide to follow the initramfs-route, why not simply >>> implement /etc/init.d/localmount in the initramfs? >> >> I think that's pretty close to what we have planned, since the plan is >> to have the initramfs mount configuration stored on the root filesystem. > > But still require a seperate configuration file for this? I guess it could probably just use fstab. Again, I'm not involved in the implementation of all this. >>> Why require users to figure out which >>> filesystems are needed for udev? >> >> Simply mount all filesystems containing files managed by the package >> manager with the initramfs. Anything else would expose you to the >> possibility of unsatisfied dependencies. > > On my desktop, that would mean the following list: > /usr/ > /var/ > /opt/ > /tmp/ > /opt/tmp/ > >>> Also, I was actually hoping for a reply to the rest of my email as well, >>> especially the idea for splitting udev into 2 seperate processes. >> >> In essence, what your doing here is playing a game of "let's see how >> long we can delay the mounting of essential filesystems". If you play >> this game, then again, you expose yourself to the possibility of >> unsatisfied dependencies. Therefore, the only foolproof approach is to >> mount all essential filesystems as soon as possible (via initramfs). > > True, but I don't have any scripts configured for udev on my desktop. > My server has some scripts related to Xen, and those are all under > /etc/xen/... > > In this case, would it still be necessary to use an initramfs? Well, as long as your essential filesytems aren't mounted before init is called, there's always the possibility that some issue of unsatisfied dependencies will arise in the future. Therefore, the most foolproof and future-proof approach is to have them all mounted before init is called. >>> If someone can explain to me why my idea won't work, please let me know. >> >> If your goal is to expose yourself to the possibility of unsatisfied >> dependencies, they your idea will achieve it. > > No, my goal is to come up with a different solution to this problem which, on > my system and possibly also on a lot of other systems, doesn't actually exist. If a problem doesn't exist now, that doesn't mean one won't arise in the future. As said, the most future-proof approach is to have them all mounted before init is called. -- Thanks, Zac
Re: [gentoo-dev] x32 fun pants
On Thursday, September 15, 2011 16:00:14 Alexey Shvetsov wrote: please dont top post > Is it accepted for merge into kernel mainline for 3.2? no. i was just being optimistic. i'm running 3.1-rc4 atm with a smallish patch to make it work. > Actualy this abi looks like n32 mips abi. yeah, a lot of the reasons behind the creation of n32 were behind the creation of the x32 abi. > PS why not merge all x86 abis into one keyword? because x86_32 x86_64 > x86_x32 are only abis of x86. Also we dont have different keywords for > different mips abis (64bit and 32bit ones) that'd be nice :) -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 16:14:20 Michał Górny wrote: > On Thu, 15 Sep 2011 22:03:53 +0200 Joost Roeleveld wrote: > > I'm trying to think of how best to avoid users who are not aware to > > get caught with non-booting systems. > > Guess we could try to detect a few common cases and die in pkg_setup() > whenever the failure is imminent. yeah, no. pkgs shouldnt be divining the properties of the kernel used to boot the system and aborting based on their guess. `ewarn` would probably be fine though -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 02:29:20 PM Rich Freeman wrote: > On Thu, Sep 15, 2011 at 11:07 AM, Zac Medico wrote: > > On 09/15/2011 07:33 AM, Joost Roeleveld wrote: > > > The use for an initrd/initramfs/... will create an additional layer > > > of > > > complexity a lot of us users are not really waiting for, especially > > > as we> > > are > > > > > not seeing any issues with our current systems. > > > > Like it or not, it's the simplest possible solution if you want separate > > /usr. The plan is to provide a minimal initramfs that won't contain any > > modules, so it won't have to be rebuilt for each kernel. See the "/usr > > > vs. initramfs redux" thread: > It should be noted that the alternative is to use a more full-featured > initramfs like dracut, which will also be updated to support mounting /usr > (it already parses /etc/fstab to remount root anyway). > > The minimal initramfs will not contain mdadm or lvm tools, so it is > basically suitable for booting systems that don't currently require an > initramfs. Of course, something like dracut is more likely to require you > to rebuild the initramfs every time you update your kernel, and won't simply > be a static image like the simplified one. > > The simplified initramfs could be compiled into the kernel as Zac suggests > (this is probably the most foolproof method), or it could be loaded from > /boot using the appropriate grub settings. Is there an option in Grub to add a "default" initramfs that is used for all boot-options that can be overriden per boot-set? In other words, if I don't specify an initramfs for a kernel, that this default is then automatically applied? And will this then also work when using Xen where the kernel is already passed as a module? > Note that dracut does drop you to a shell if it fails (this is > configurable), but by default this shell is dash, not bash. No doubt it > would work fine either way, but bash is likely to be a little slower. I > don't think RAM use is likely to be a problem - it should be completely > de-allocated before init runs. It is my understanding all the options need to be specified every time dracut is run to create an initramfs. If this becomes mandatory, will this be added to the "make" script of the kernel-sources and as such, make this more specific? Another issue arrises where some of the tools are updated that are also in the initramfs. Will we then still need to remember to also update the initramfs if these are needed? My server currently uses mdadm raid1 for /, /boot and swap and raid1+lvm for the rest. This works without the need of an initramfs. Will this still work? Or will I need to be using dracut instead? Please note, I'm not the only one using this option as it was taking directly from the Gentoo guides: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml -- Joost
Re: [gentoo-dev] udev and /usr
On 9/15/11 1:14 PM, Michał Górny wrote: > On Thu, 15 Sep 2011 22:03:53 +0200 > Joost Roeleveld wrote: > >> I'm trying to think of how best to avoid users who are not aware to >> get caught with non-booting systems. > > Guess we could try to detect a few common cases and die in pkg_setup() > whenever the failure is imminent. Even better in pkg_pretend if you can use EAPI=4 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 4:40 PM, Joost Roeleveld wrote: > > It is my understanding all the options need to be specified every time > dracut > is run to create an initramfs. If this becomes mandatory, will this be > added > to the "make" script of the kernel-sources and as such, make this more > specific? > There are no plans to make dracut mandatory, unless you're putting root on lvm or luks or something, and a good initramfs is already needed for that. I think /etc/dracut.conf already has just about anything you'd want to be persistent across runs. > > Another issue arrises where some of the tools are updated that are also in > the > initramfs. Will we then still need to remember to also update the initramfs > if > these are needed? > > Potentially - if the tools in the initramfs won't work. That seems unlikely though - on-disk formats don't really change much and all stuff like mdadm and lvm tools do is find stuff and pass it along to the kernel which does the real work. If you migrate your root from raid1 to raid17 and the old initramfs doesn't understand raid17 then you'll have a problem. I imagine that if you migrate to raid17, however, you'd have put some thought into this. > My server currently uses mdadm raid1 for /, /boot and swap and raid1+lvm > for > the rest. This works without the need of an initramfs. > > Will this still work? Or will I need to be using dracut instead? > > I suspect that if /usr is on raid1+lvm that you might need dracut. I'm not 100% sure on that, since in theory the initramfs can find all it needs on root in this case. However, the goal was to keep it simple. I'd defer to somebody actually involved with the simple image. Rich
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 09:27:06AM -0700, Zac Medico wrote: > On 09/15/2011 09:04 AM, Joost Roeleveld wrote: > > Thank you for your response, however, I do have a few questions about this. > > Where will this default initramfs actually need to be placed? > > It should be similar to how sys-apps/v86d is used for uvesafb support. > It installs /usr/share/v86d/initramfs and when you configure your > kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" in > order to have in included in your kernel image. Actually, we are looking at installing the initramfs image directly in /boot, then you will have to configure your boot loader to use it. William pgpkKPGLROdhr.pgp Description: PGP signature
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 07:41:57 PM Robin H. Johnson wrote: > On Thu, Sep 15, 2011 at 04:33:01PM +0200, Joost Roeleveld wrote: > > The use for an initrd/initramfs/... will create an additional layer of > > complexity a lot of us users are not really waiting for, especially as > > we are not seeing any issues with our current systems. > > See below on the existing udev retry queue that is hiding many of the > issues from you. This hidden issues are also negatively affecting boot > times (failures and retries take time). I don't actually mind too much about the boot time. If there are retries like this, I would expect this to be visible in the system logs. > > My idea is, to me at least, simple. > > "udev" is split into 2 parts: > > 1) "udevd", which creates the /dev-tree based on the events it currently > > gets 2) "actiond" processes all the actions "udevd" puts in a seperate > > queue. > This needs to be taken to the upstream udev list. > > The problem is that there is a bit of a catch-22 in running some udev > rules: > 0. You're going to have to declare interdependencies between ALL udev >rules. This is because udev rules could be usable independently, or >they could be interrelated (first rule sets some state variable or >file, second one consumes it). Either udev does this already and the execution sequence is always the same. In which case my suggestion above would follow the same sequence as the queue would be on a First-in First-out basis. Or, if udev doesn't do this yet, udev will end up having the same problem. > 1. While the binary invoked by a given rule might reside entirely on a >mounting that is already available, how do you ensure that the other >mountpoints required by said binary are ALSO available (the bluetooth >and ALSA rules actually need /var, what if you have a bluetooth >keyboard? [see footnote]). This is why I would suggest the "actiond" process to be started after localmount. > 2. If the udev rule fails because the filesystem was not yet mounted, >how does udev know that is safe to retry? Do we have to start >declaring every file used (opened, dlopen'd, linked against) by a >given rule? See my reply to "1". > The upstream discussions I've been party to previously (both on lists > and in person), have been trying to avoid needing a full dependency > system in udev, because it's a huge degree of additional complexity. I don't see why it would not be possible to pause actioning of these scripts till the boot-process says all required mounts are available. I see this as a "solution" for the situation where someone decides to use less-common hardware and force this solution onto everyone else. If I would want to put my /usr filesystem on a bluetooth harddrive (for instance my mobile phone), then I would not expect to have this work without a lot of extra effort. > > I think that if "udevd" is started at boot-time and "actiond" only after > > "localmount" has finished, there shouldn't be the situation where a > > script in the udev-configuration fails because of missing files. > > Even if it does, then this can be handled in "actiond" itself and placed > > in a retry-queue. > > udev has a retry queue already, see udev-postmount: > === > # Run the events that failed at first udev trigger > udevadm trigger --type=failed -v > === This is a retry-queue. That's a good start already, but why not redo this queue and put ALL the scripts into that queue untill after localmount? > (upstream is actually planning to remove it, because of problems of > rules with side-effects to being run multiple times, amongst other > things). If this mechanism would be used to have all external scripts run after localmount for the first time, these side-effects shouldn't happen. > > With a smaller udev, the chances of it failing should also be less. > > (less > > code-lines to check) and as long as the /dev-entries are created, these > > can be used to manually mount the other partitions to get to the point > > where the system can be fixed to get it back to a workable state. > > The problem is NOT in the udev codebase. It's in udev rules. Even at the > rule level, it's mostly rules for packages other than udev itself. Yes, but as I already stated, the problem-rules do not exist on all systems. My systems for instance don't have any pointing to anything other then /etc/... These scripts also don't call anything that isn't mounted at the time. That system has been running without incident for several years. Why do I suddenly have to make that system more complex? > > If, in the currently planned form, udev fails, it will be necessary to > > use a rescue-cd/usb to boot the system, try to fix it inside a chroot > > where it's not easy to check what is actually going wrong during the > > boot-process as the different tools can then not be run with the > > error-messages printed to the console. > > No, you're gotten the failure case w
Re: [gentoo-dev] x32 fun pants
On Thu, 15 Sep 2011 16:33:48 -0400 Mike Frysinger wrote: > On Thursday, September 15, 2011 16:12:00 Michał Górny wrote: > > On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote: > > > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. > > > instead, reusing "amd64". only downside is the existing USE=amd64 > > > behavior, but we can address that by making MULTILIB_ABIS a > > > USE_EXPAND (i think this came up before with the portage multilib > > > discussion). > > > > Hrm, wouldn't that be more like x86 keyword? AFAICS the type sizes > > for x86 and x32 would match. > > the sizeof(long) and sizeof(void*) are the same between x86 and x32. > however, that's about the only thing. for example, x32 gets access > to 64bit registers when working with 64bit types (long long) and the > tuple is x86_64-pc-linux- gnu. in general, it seems to be closer to > amd64 than x32. -mike I'm rather thinking about potential issues. But OTOH packages fixed for amd64 should probably work with x32 as well. Excluding asm code which would probably need a third variant then. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] x32 fun pants
On Thursday, September 15, 2011 17:03:07 Michał Górny wrote: > On Thu, 15 Sep 2011 16:33:48 -0400 Mike Frysinger wrote: > > On Thursday, September 15, 2011 16:12:00 Michał Górny wrote: > > > On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote: > > > > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. > > > > instead, reusing "amd64". only downside is the existing USE=amd64 > > > > behavior, but we can address that by making MULTILIB_ABIS a > > > > USE_EXPAND (i think this came up before with the portage multilib > > > > discussion). > > > > > > Hrm, wouldn't that be more like x86 keyword? AFAICS the type sizes > > > for x86 and x32 would match. > > > > the sizeof(long) and sizeof(void*) are the same between x86 and x32. > > however, that's about the only thing. for example, x32 gets access > > to 64bit registers when working with 64bit types (long long) and the > > tuple is x86_64-pc-linux- gnu. in general, it seems to be closer to > > amd64 than x32. > > I'm rather thinking about potential issues. But OTOH packages fixed for > amd64 should probably work with x32 as well. Excluding asm code which > would probably need a third variant then. yes, inline asm might need tweaking as pointers/longs are no longer 64bits. so any code that assumes "#ifdef __x64_64__ == sizeof(void*) == 8" and does so in their assembly might break. they'll need to have gcc take care of it by leveraging the constraints, or checking the __LP64__ define in addition to __x64_64__. but i'd rather not introduce another KEYWORD when we can simply p.mask the package, or disable the asm when ABI == x32. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 01:45:23PM -0700, "Paweee Hajdan, Jr." wrote: > On 9/15/11 1:14 PM, Michał Górny wrote: > > On Thu, 15 Sep 2011 22:03:53 +0200 > > Joost Roeleveld wrote: > > > >> I'm trying to think of how best to avoid users who are not aware to > >> get caught with non-booting systems. > > > > Guess we could try to detect a few common cases and die in pkg_setup() > > whenever the failure is imminent. > > Even better in pkg_pretend if you can use EAPI=4 Which will misbehave if the kernel is one of the things to be updated. pkg_pretend shouldn't really be used for that unfortunately. ~brian
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 04:54:38 PM Rich Freeman wrote: > On Thu, Sep 15, 2011 at 4:40 PM, Joost Roeleveld wrote: > > It is my understanding all the options need to be specified every time > > dracut > > is run to create an initramfs. If this becomes mandatory, will this be > > added > > to the "make" script of the kernel-sources and as such, make this more > > specific? > > There are no plans to make dracut mandatory, unless you're putting root on > lvm or luks or something, and a good initramfs is already needed for that. > > I think /etc/dracut.conf already has just about anything you'd want to be > persistent across runs. That would be a good starting point. Having to type a lengthy commandline each time I update the kernel and/or toolstack will become troublesome and problems will easily occur. Will the ebuild automatically add all the different modules into the /etc/dracut.conf ? Please note, I am asking these questions to put my mind at ease and hopefully be able to explain all this back to the people on gentoo-user. > > Another issue arrises where some of the tools are updated that are also > > in the > > initramfs. Will we then still need to remember to also update the > > initramfs if > > these are needed? > > Potentially - if the tools in the initramfs won't work. That seems unlikely > though - on-disk formats don't really change much and all stuff like mdadm > and lvm tools do is find stuff and pass it along to the kernel which does > the real work. If you migrate your root from raid1 to raid17 and the old > initramfs doesn't understand raid17 then you'll have a problem. I imagine > that if you migrate to raid17, however, you'd have put some thought into > this. Migrating to raid17 (mirrored raid7, where there can be 3 failed disks per raid7?) would require some thought already. > > My server currently uses mdadm raid1 for /, /boot and swap and raid1+lvm > > for > > the rest. This works without the need of an initramfs. > > > > Will this still work? Or will I need to be using dracut instead? > > I suspect that if /usr is on raid1+lvm that you might need dracut. I'm not > 100% sure on that, since in theory the initramfs can find all it needs on > root in this case. However, the goal was to keep it simple. I'd defer to > somebody actually involved with the simple image. If this is the case, then, to me, this is a major regression. As the current toolstack does not need an initramfs. All the lvm-tools are installed on / by default. None of the required tools are under /usr. -- Joost
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 04:27:35 PM Rich Freeman wrote: > On Thu, Sep 15, 2011 at 4:03 PM, Joost Roeleveld wrote: > > On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: > > > It should be similar to how sys-apps/v86d is used for uvesafb > > > support. > > > It installs /usr/share/v86d/initramfs and when you configure your > > > kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" > > > in > > > order to have in included in your kernel image. > > > > Will this be set somewhere globally to the initramfs automatically? > > And doesn't this mean that a new kernel will need to be build just to > > satisfy > > this? > > > > I'm trying to think of how best to avoid users who are not aware to get > > caught > > with non-booting systems. > > > > Wouldn't automatic inclusion into grub.conf be a better approach? Not > > sure if > > grub.conf can handle a "global" setting for initramfs. > > Well, the only way to set a kernel config parameter is to rebuild the > kernel. There might be some way to extract the built-in initramfs (every > kernel has one) and replace it with the new one without rebuilding it, but I > doubt most users would prefer that we mount /boot and start modifying their > kernel images. I wasn't actually talking about changing kernels, but was wondering if grub.conf has some option for a "global" initramfs. I couldn't find anything in the manpage. > Changes to grub.conf will only be properly merged if /boot is mounted, if > grub is installed (don't laugh - I checked and since my system was migrated > so many times I don't actually have the package installed any longer), and > the user actually merges the changes in. Fiddling with grub.conf isn't > exactly risk-free either. I know, which is why I was asking for a "default" option for the initrd/module part. > I think something like this is best handled via news. And perhaps also an announcement on gentoo-user. I think a lot of users are subscribed to there. > Note also that depending on your definition of "broken" the separate /usr > situation is already broken. It will probably steadily become more broken > over time, so when it stops booting altogether for any particular user might > happen anytime from a year ago to never. In what way is it broken? I've only seen comments about where some udev-rules seem to expect /usr to be present when run and udev not properly handling these cases. (I know this is the very short version) If an installation works and none of the udev-rules depend on /usr (or /var, ) then a seperate /usr should not be considered "broken". My desktop is up-to-date and none of my udev-rules even have a "RUN+=" part. Only my server has these for Xen-devices and these aren't run until "xendomains" starts and this is quite late in the boot-sequence. All my machines have /usr on LVM. -- Joost
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 08:31:51 PM Robin H. Johnson wrote: > On Thu, Sep 15, 2011 at 10:03:53PM +0200, Joost Roeleveld wrote: > > On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: > > > On 09/15/2011 09:04 AM, Joost Roeleveld wrote: > > > > Thank you for your response, however, I do have a few questions > > > > about > > > > this. Where will this default initramfs actually need to be > > > > placed? > > > > > > It should be similar to how sys-apps/v86d is used for uvesafb > > > support. > > > It installs /usr/share/v86d/initramfs and when you configure your > > > kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" > > > in > > > order to have in included in your kernel image. > > > > Will this be set somewhere globally to the initramfs automatically? > > And doesn't this mean that a new kernel will need to be build just to > > satisfy this? > > > > I'm trying to think of how best to avoid users who are not aware to get > > caught with non-booting systems. > > > > Wouldn't automatic inclusion into grub.conf be a better approach? Not > > sure if grub.conf can handle a "global" setting for initramfs. > > Grub doesn't support a global initramfs setting, but you can build a > static initramfs for v86d if needed. Ok, was afraid there wasn't. If there was, it would make things easier. > > > > Also, how will > > > > we be able to deal with situations where this script fails? > > > > > > It should drop you to a minimal shell. > > > > But, with udev then failing, will there be the /dev-entries to mount the > > different partitions to fix the environment? > > Yes, /dev is provided by devtmpfs already, and that is populated by the > kernel. If /dev is already populated by devtmpfs with the stuff for mounting what can currently already be mounted without an initramfs. Won't that be sufficient to have udev started *after* localmount? Eg. the following configuration: Kernel has the "devtmpfs" option localmount mounts the local filesystems using the devtmpfs /dev-tree udev is configured to start after localmount > > > > If Gentoo does decide to follow the initramfs-route, why not > > > > simply > > > > implement /etc/init.d/localmount in the initramfs? > > > > > > I think that's pretty close to what we have planned, since the plan > > > is > > > to have the initramfs mount configuration stored on the root > > > filesystem.> > > But still require a seperate configuration file for this? > > The configuration file isn't actually required, but it's there in case > you want to specify MORE filesystems to mount before switching to the > rootfs init. > > There are two files to load from the rootfs: > 1. /etc/fstab > 2. /etc/minimal-filesystems.cfg [exact name undecided] > > The list is in the second file, just one mountpoint per line. > Defaults to /usr, /var > If the file is not available, the default is also /usr, /var. > > For each filesystem for the minimal list, use the line from fstab to > mount it. This covers getting the device, mountpoint and mount options. Why not try to mount all the filesystems in /etc/fstab in the minimal script automatically unless there is a list (not commented out) in /etc/minimal- filesystems.cfg ? > There is a catch to this: > If those non-root filesystems live on LVM or something complex, you're > going to need to use a more advanced initramfs, > genkernel/dracut/roll-your-own. This means that on a system where I currently don't need an initramfs, I suddenly need a full-grown initramfs. > > On my desktop, that would mean the following list: > > /usr/ > > /var/ > > Only these two should be needed to early-boot the system successfully. > > > True, but I don't have any scripts configured for udev on my desktop. > > My server has some scripts related to Xen, and those are all under > > /etc/xen/... > > > > In this case, would it still be necessary to use an initramfs? > > Where is /usr, and do you have any udev rules that need /var? I followed the following guide: http://www.gentoo.org/doc/en/gentoo-x86+raid+lvm2-quickinstall.xml I have /usr on LVM which is on top of mdadm-raid1 on the server. My desktop has the same, except for the raid1-part. I don't have any udev-rules needing anything outside of /. Eg. they don't need /usr or anything else that is not part of the root- filesystem. The xen-scripts might, but those devices only appear when starting the PV- domains. And those don't start until well after everything else. -- Joost
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 01:34:50 PM Zac Medico wrote: > On 09/15/2011 01:03 PM, Joost Roeleveld wrote: > > But, with udev then failing, will there be the /dev-entries to mount the > > different partitions to fix the environment? > > I the preferred approach is to enable CONFIG_DEVTMPFS=y and > CONFIG_DEVTMPFS_MOUNT=y, so that the kernel populates /dev for you > automatically. Will this be sufficient for "localmount" to get the system to work correctly? It is my understanding that some udev-scripts are the actual problem that is being solved with this? I wasn't aware of these kernel options also being required. > >>> Also, I was actually hoping for a reply to the rest of my email as > >>> well, especially the idea for splitting udev into 2 seperate > >>> processes.>> > >> In essence, what your doing here is playing a game of "let's see how > >> long we can delay the mounting of essential filesystems". If you play > >> this game, then again, you expose yourself to the possibility of > >> unsatisfied dependencies. Therefore, the only foolproof approach is to > >> mount all essential filesystems as soon as possible (via initramfs). > > > > True, but I don't have any scripts configured for udev on my desktop. > > My server has some scripts related to Xen, and those are all under > > /etc/xen/... > > > > In this case, would it still be necessary to use an initramfs? > > Well, as long as your essential filesytems aren't mounted before init is > called, there's always the possibility that some issue of unsatisfied > dependencies will arise in the future. Therefore, the most foolproof and > future-proof approach is to have them all mounted before init is called. With systemd, one of these is the dbus-stack. Yes, I'm aware of this. But, if systemd isn't used, init should work. Or have I missed something about init being deprecated for systemd? I think systemd is nice for desktops/laptops. But on servers it seems to be overkill to me and as I umount filesystems as part of my backup-scripts, having something force-mount them in the background is going to kill those scripts. But this bit is off-topic. > >>> If someone can explain to me why my idea won't work, please let me > >>> know.>> > >> If your goal is to expose yourself to the possibility of unsatisfied > >> dependencies, they your idea will achieve it. > > > > No, my goal is to come up with a different solution to this problem > > which, on my system and possibly also on a lot of other systems, > > doesn't actually exist. > If a problem doesn't exist now, that doesn't mean one won't arise in the > future. As said, the most future-proof approach is to have them all > mounted before init is called. Or, if I am not mistaken, before udev is started when not using systemd. -- Joost
Re: [gentoo-dev] udev and /usr
On Thursday, September 15, 2011 03:56:19 PM William Hubbs wrote: > On Thu, Sep 15, 2011 at 09:27:06AM -0700, Zac Medico wrote: > > On 09/15/2011 09:04 AM, Joost Roeleveld wrote: > > > Thank you for your response, however, I do have a few questions > > > about this. Where will this default initramfs actually need to be > > > placed? > > > > It should be similar to how sys-apps/v86d is used for uvesafb support. > > It installs /usr/share/v86d/initramfs and when you configure your > > kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" in > > order to have in included in your kernel image. > > Actually, we are looking at installing the initramfs image directly in > /boot, then you will have to configure your boot loader to use it. William, This, to me, seems like the obvious solution. However, to make the change as unobtrusive as possible for the majority of users. Wouldn't it be possible to have grub support a "default initrd" in the grub.conf and use that unless the grub-entry specifies it's own? This is just an idea that I have. Not sure how much work this would bring. It would still not catch the situation on my server where the kernel is passed with the same mechanism to the xen-hypervisor and as such, the "defeault initrd" would then be ignored. But on my desktop, this would work automagically. -- Joost
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 11:00:47PM +0200, Joost Roeleveld wrote: > > See below on the existing udev retry queue that is hiding many of the > > issues from you. This hidden issues are also negatively affecting boot > > times (failures and retries take time). > I don't actually mind too much about the boot time. If there are retries like > this, I would expect this to be visible in the system logs. udev does not log rule failures to the best of my knowledge. > > The problem is that there is a bit of a catch-22 in running some udev > > rules: > > 0. You're going to have to declare interdependencies between ALL udev > >rules. This is because udev rules could be usable independently, or > >they could be interrelated (first rule sets some state variable or > >file, second one consumes it). > Either udev does this already and the execution sequence is always the same. > In which case my suggestion above would follow the same sequence as the queue > would be on a First-in First-out basis. > Or, if udev doesn't do this yet, udev will end up having the same problem. It doesn't do it presently. The worst case I've seen is having an early rule that succeeds, but gives different results w/ /var mounted vs. not mounted. This rule didn't actual fail, so it does not get retried... > > 1. While the binary invoked by a given rule might reside entirely on a > >mounting that is already available, how do you ensure that the other > >mountpoints required by said binary are ALSO available (the bluetooth > >and ALSA rules actually need /var, what if you have a bluetooth > >keyboard? [see footnote]). > This is why I would suggest the "actiond" process to be started after > localmount. That's too late. What about all the udev rules required to get the device nodes for localmount to succeed? Anyway, take your proposed split actiond/udev solution to the upstream udev list. I don't believe that we have the manpower to develop it here. If we did develop it here, I don't believe it will gain enough traction amongst other distros, and we'll be stuck supporting it. I personally don't think your split solution covers the usage cases well enough, but that's an actual decision best left to the upstream udev developers. Please take the discussion there, and don't pursue it on this list. > > The upstream discussions I've been party to previously (both on lists > > and in person), have been trying to avoid needing a full dependency > > system in udev, because it's a huge degree of additional complexity. > I don't see why it would not be possible to pause actioning of these scripts > till the boot-process says all required mounts are available. You still have to declare which scripts need to be paused, and/or which rules inside the scripts need to be paused. Even worse are cases where mounting some of localmount entries requires those scripts to have completed. > I see this as a "solution" for the situation where someone decides to use > less-common hardware and force this solution onto everyone else. I'm trying to get as little forced on us as possible. Gentoo is one of the few distros at this point that doesn't already require initramfs. While we're going to carry on supporting not requiring an initramfs as long as possible (and documenting what is needed for that), we also don't want this to become a stumbling block for users that just want their system to work, and with how upstream udev and other projects are going, there is a real possibility of breakage caused by their code, far more than the potential of breakage because /usr failed to mount. > If I would want to put my /usr filesystem on a bluetooth harddrive (for > instance my mobile phone), then I would not expect to have this work without > a > lot of extra effort. While that is in the realms of extreme, having /usr or /var on NFS isn't extreme at all. > > udev has a retry queue already, see udev-postmount: > > === > > # Run the events that failed at first udev trigger > > udevadm trigger --type=failed -v > > === > This is a retry-queue. That's a good start already, but why not redo this > queue and put ALL the scripts into that queue untill after localmount? See above, about rules that are required for localmount to be able to complete. The most prevalent ones would probably be devices by-uuid and by-label. Those symlinks come from udev... > > > With a smaller udev, the chances of it failing should also be less. > > > (less > > > code-lines to check) and as long as the /dev-entries are created, these > > > can be used to manually mount the other partitions to get to the point > > > where the system can be fixed to get it back to a workable state. > > > > The problem is NOT in the udev codebase. It's in udev rules. Even at the > > rule level, it's mostly rules for packages other than udev itself. > > Yes, but as I already stated, the problem-rules do not exist on all systems. > My systems for instance don't have any pointing to anythi
Re: [gentoo-dev] udev and /usr
On Fri, 16 Sep 2011 00:13:15 +0200 Joost Roeleveld wrote: > I think systemd is nice for desktops/laptops. But on servers it seems > to be overkill to me and as I umount filesystems as part of my > backup-scripts, having something force-mount them in the background > is going to kill those scripts. > But this bit is off-topic. It's all about replacing 'umount' with 'systemctl stop'. But if you don't use automount, I don't think systemd will actually interfere. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
2011-09-15 09:55:08 Ciaran McCreesh napisał(a): > On Thu, 15 Sep 2011 09:35:21 +0200 > Michał Górny wrote: > > Could you point me to at least a single program not supporting dots > > in useflags? My quick check shows that all PMs handle them well, quse > > and euse as well. > > Hrm, it's rather disappointing that they're accepted everywhere. That > really shouldn't happen... My excuse for Paludis is that I never quite > got around to passing in additional flags to validation of names, and > dots are legal in exheres-0 There is no reason for Gentoo to be worse than Exherbo and not allow dots in USE flags. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
On Fri, Sep 16, 2011 at 01:21:55AM +0200, Arfrever Frehtes Taifersar Arahesis wrote: > 2011-09-15 09:55:08 Ciaran McCreesh napisał(a): > > On Thu, 15 Sep 2011 09:35:21 +0200 > > Michał Górny wrote: > > > Could you point me to at least a single program not supporting dots > > > in useflags? My quick check shows that all PMs handle them well, quse > > > and euse as well. > > > > Hrm, it's rather disappointing that they're accepted everywhere. That > > really shouldn't happen... My excuse for Paludis is that I never quite > > got around to passing in additional flags to validation of names, and > > dots are legal in exheres-0 > > There is no reason for Gentoo to be worse than Exherbo and not allow dots in > USE flags. Seriously Arfrever, drop the rhetoric here, and go fix the profile compatibility issue. Everytime you bring up dot's in use, you ignore compatibility, and every damn time it gets brought up I keep having to repeat this. It's not productive and this has repeated for at least a year now. People who want this need to sort the compat issue rather than sticking their heads in the sand. ~brian
Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting
2011-09-16 01:54:44 Brian Harring napisał(a):
> On Fri, Sep 16, 2011 at 01:21:55AM +0200, Arfrever Frehtes Taifersar Arahesis
> wrote:
> > 2011-09-15 09:55:08 Ciaran McCreesh napisał(a):
> > > On Thu, 15 Sep 2011 09:35:21 +0200
> > > Michał Górny wrote:
> > > > Could you point me to at least a single program not supporting dots
> > > > in useflags? My quick check shows that all PMs handle them well, quse
> > > > and euse as well.
> > >
> > > Hrm, it's rather disappointing that they're accepted everywhere. That
> > > really shouldn't happen... My excuse for Paludis is that I never quite
> > > got around to passing in additional flags to validation of names, and
> > > dots are legal in exheres-0
> >
> > There is no reason for Gentoo to be worse than Exherbo and not allow dots
> > in USE flags.
>
> Seriously Arfrever, drop the rhetoric here, and go fix the profile
> compatibility issue.
I suggest to support files with "-${EAPI}" suffix.
Examples:
profiles/package.mask-5
profiles/use.desc-5
profiles/base/package.mask-5
profiles/base/package.use-5
profiles/base/package.use.force-5
profiles/base/package.use.mask-5
profiles/base/use.force-5
profiles/base/use.mask-5
profiles/desc/python_abis.desc-5
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] udev and /usr
On Thu, Sep 15, 2011 at 5:48 PM, Joost Roeleveld wrote: > Will the ebuild automatically add all the different modules into the > /etc/dracut.conf ? > Please note, I am asking these questions to put my mind at ease and > hopefully > be able to explain all this back to the people on gentoo-user. > > Honestly, I'd recommend just trying it out. Dracut right now is as usable as any non-initramfs solution out there and you can always add it as an extra non-default option in grub so that it doesn't mess you up if it doesn't work. I've found that dracut is pretty auto-magic by default and the config file doesn't generally need tampering. Most of the options are to NOT load modules or to minimize the initramfs size by figuring out what modules are actually needed and only load those (which means if you change hardware between boots it could come up short). The modules that are available are controlled by use flags. Actually, I think it is a DRACUT_MODULES variable or something like that (not unlike how X11 handles drivers). Rich
Re: [gentoo-dev] Packages up for grabs due arfrever retirement
I'll take dev-util/global On Wed, Sep 14, 2011 at 3:56 AM, Pacho Ramos wrote: > Due arfrever retirement the following packages need a new maintainer: > > dev-util/global > net-irc/kvirc > net-libs/neon > net-libs/serf > net-misc/cadaver > > > Thanks for taking them
Re: [gentoo-dev] new `usex` helper
On 17:29 Wed 14 Sep , Brian Harring wrote: > On Wed, Sep 14, 2011 at 02:16:41PM -0500, Donnie Berkholz wrote: > > On 19:14 Tue 13 Sep , Brian Harring wrote: > > > On Tue, Sep 13, 2011 at 09:02:28PM -0500, Donnie Berkholz wrote: > > > > On 17:56 Tue 13 Sep , Mike Frysinger wrote: > > > > > useful enough for EAPI ? or should i just stick it into > > > > > eutils.eclass > > > > > ? OR BOTH !? > > > > > > > > I prefer to avoid EAPI whenever possible, as it just makes things > > > > slower > > > > and more complex. > > > > > > Exactly the wrong approach; it winds up with master > > > repositories/overlays cloning the functionality all over the damn > > > place. > > > > Why are people cloning anything if it's in eutils.eclass in gentoo-x86? > > There are more repositories than just gentoo-x86, and overlay is *not* > the only configuration in use. Who else besides you is using any other configuration? Should we really give a crap about the 0.001% population with some weird setup when we're trying to improve things for the 99.999% one? > In the old days of the PM only handling a single overlay stack, what > you're suggesting would be less heinous- heinous in detail, but > pragmatic in reality. These days it's a regressive approach- > requiring everyone to slave gentoo-x86 isn't sane, nor is avoiding > eapi (resulting in people having to duplicate code into each > repository stack). I don't know many people who aren't using gentoo-x86 or a repo that pulls in changes directly from it. -- Thanks, Donnie Donnie Berkholz Council Member / Sr. Developer Gentoo Linux Blog: http://dberkholz.com pgp6FhfQzVVid.pgp Description: PGP signature
[gentoo-dev] Re: udev and /usr
Joost Roeleveld posted on Thu, 15 Sep 2011 22:33:18 +0200 as excerpted: > On Thursday, September 15, 2011 09:31:45 PM Luca Barbato wrote: >> On 15/09/2011 16:33, Joost Roeleveld wrote: >> > >> > Not sure if you are aware of the discussions on the gentoo-user list >> > about the upcoming change where systemd and udev require /usr to be >> > available prior to starting of udev. >> >> systemd seems more and more just a support burden for no gain... > > Myself and a lot of others on the gentoo-user list agree with this. > Especially as there are plenty of installations where udev works without > /usr mounted. As a kde user[1] I tend to agree, but I'm increasingly seeing talk on the gnome side of the "Gnome OS", to include pulse-audio, systemd, policykit, udev/u* (thus forcing lvm as well, at least lvm installation tho nothing forces one to use it... yet, since lvm is required for udisks), etc. Legitimate question, primarily for the gentoo/gnome folks I guess. I simply don't know how it's to work but am honestly rather fearful for the traditional Gentoo policy of letting the local sysadmin decide such things: How serious is this talk, how integrated are they actually talking, and what are the implications for Gentoo's Gnome users? Is gnome 3.5 or 4.0 or whatever going to require pulse-audio and systemd, on ANY distribution, even Gentoo? If not, how much hacking is going to be required by the gentoo/gnome folks to keep those sorts of choices for Gentoo users? Will gentoo simply drop gnome as an option if it forces the issue, or ??? It may be that this is already sorted on the gnome side, or that all this talk of gnome-os is simply hot-air, but like I said, I'm a kde user, so I wouldn't know, tho I'm concerned about its implications for the rest of us (including kde, since it might well end up with similar requirements). And I've not yet seen it mentioned in the gentoo implications context, so I'm compelled to ask. --- [1] Tho the kde side seems headed the same direction, but at a somewhat slower pace and with a bit more of a reputation for at least /some/ respect of user choice, so I expect the issue to come up first and worst with gnome, and gentoo/kde to be able to follow the precedent, to some degree. -- 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
[gentoo-dev] How to handle dependencies on protocol headers?
Often packages depending on X11 libraries will also have to specify the X11 libraries' proto packages in DEPEND. This is because the X11 library itself #includes files provided by the proto package. It's not really that the X11 library depends on this at run-time, so the protocol packages aren't specified in the RDEPEND of the libraries. This is documented in a number of bug reports (see 379545), and it seems that the decision is between - add proto package to dependency list of packages using X11 libs - add proto package to rdepend list of the relevant library itself The first is more correct, I think, but it's also much more annoying. Mesa winds up having x11-proto/inputproto in DEPEND for some long forgotten reason, for instance. The second option is much simpler and less error prone, but removes the ability to depclean the proto packages. It seems that some sort of DEPEND variable that means "I only need this when other packages are building against me" would be useful. Thoughts? Matt
Re: [gentoo-dev] How to handle dependencies on protocol headers?
On Thu, Sep 15, 2011 at 9:32 PM, Matt Turner wrote: > Often packages depending on X11 libraries will also have to specify > the X11 libraries' proto packages in DEPEND. This is because the X11 > library itself #includes files provided by the proto package. It's not > really that the X11 library depends on this at run-time, so the > protocol packages aren't specified in the RDEPEND of the libraries. > > This is documented in a number of bug reports (see 379545), and it > seems that the decision is between > - add proto package to dependency list of packages using X11 libs > - add proto package to rdepend list of the relevant library itself > > The first is more correct, I think, but it's also much more annoying. > Mesa winds up having x11-proto/inputproto in DEPEND for some long > forgotten reason, for instance. Why is it annoying? -A > > The second option is much simpler and less error prone, but removes > the ability to depclean the proto packages. > > It seems that some sort of DEPEND variable that means "I only need > this when other packages are building against me" would be useful. > Thoughts? > > Matt > >
[gentoo-dev] Re: How to handle dependencies on protocol headers?
On Fri, Sep 16, 2011 at 12:32 AM, Matt Turner wrote: > Often packages depending on X11 libraries will also have to specify > the X11 libraries' proto packages in DEPEND. This is because the X11 > library itself #includes files provided by the proto package. It's not > really that the X11 library depends on this at run-time, so the > protocol packages aren't specified in the RDEPEND of the libraries. > > This is documented in a number of bug reports (see 379545), and it > seems that the decision is between > - add proto package to dependency list of packages using X11 libs > - add proto package to rdepend list of the relevant library itself > > The first is more correct, I think, but it's also much more annoying. > Mesa winds up having x11-proto/inputproto in DEPEND for some long > forgotten reason, for instance. > > The second option is much simpler and less error prone, but removes > the ability to depclean the proto packages. > > It seems that some sort of DEPEND variable that means "I only need > this when other packages are building against me" would be useful. > Thoughts? > > Matt Another similar situation: https://bugs.gentoo.org/show_bug.cgi?id=342393
Re: [gentoo-dev] How to handle dependencies on protocol headers?
On Fri, Sep 16, 2011 at 12:36 AM, Alec Warner wrote: > The first is more correct, I think, but it's also much more annoying. > Mesa winds up having x11-proto/inputproto in DEPEND for some long > forgotten reason, for instance. > > Why is it annoying? Because the proto will have to be added as a dependency to a lot of packages, when I think it's needed if and only if the package (r)depends on the X11 library. Because of this, it can be quite prone to missing dependencies. Matt
Re: [gentoo-dev] Re: How to handle dependencies on protocol headers?
On 09/15/2011 09:42 PM, Matt Turner wrote: > On Fri, Sep 16, 2011 at 12:32 AM, Matt Turner wrote: >> Often packages depending on X11 libraries will also have to specify >> the X11 libraries' proto packages in DEPEND. This is because the X11 >> library itself #includes files provided by the proto package. It's not >> really that the X11 library depends on this at run-time, so the >> protocol packages aren't specified in the RDEPEND of the libraries. >> >> This is documented in a number of bug reports (see 379545), and it >> seems that the decision is between >> - add proto package to dependency list of packages using X11 libs >> - add proto package to rdepend list of the relevant library itself >> >> The first is more correct, I think, but it's also much more annoying. >> Mesa winds up having x11-proto/inputproto in DEPEND for some long >> forgotten reason, for instance. >> >> The second option is much simpler and less error prone, but removes >> the ability to depclean the proto packages. >> >> It seems that some sort of DEPEND variable that means "I only need >> this when other packages are building against me" would be useful. >> Thoughts? >> >> Matt > > Another similar situation: > > https://bugs.gentoo.org/show_bug.cgi?id=342393 Maybe the virtual/mesa-build approach that I suggested can be adapted to other similar situations: https://bugs.gentoo.org/show_bug.cgi?id=342393#c23 -- Thanks, Zac
Re: [gentoo-dev] Re: How to handle dependencies on protocol headers?
I like a DEPEND way. But in this way many packages will need to be modified and missing dependencies likely appear. I developed an util to detect missing dependencies https://bugs.gentoo.org/show_bug.cgi?id=autodep Best, Alexander Bersenev On 16.09.2011, at 10:49, Zac Medico wrote: > On 09/15/2011 09:42 PM, Matt Turner wrote: >> On Fri, Sep 16, 2011 at 12:32 AM, Matt Turner wrote: >>> Often packages depending on X11 libraries will also have to specify >>> the X11 libraries' proto packages in DEPEND. This is because the X11 >>> library itself #includes files provided by the proto package. It's not >>> really that the X11 library depends on this at run-time, so the >>> protocol packages aren't specified in the RDEPEND of the libraries. >>> >>> This is documented in a number of bug reports (see 379545), and it >>> seems that the decision is between >>> - add proto package to dependency list of packages using X11 libs >>> - add proto package to rdepend list of the relevant library itself >>> >>> The first is more correct, I think, but it's also much more annoying. >>> Mesa winds up having x11-proto/inputproto in DEPEND for some long >>> forgotten reason, for instance. >>> >>> The second option is much simpler and less error prone, but removes >>> the ability to depclean the proto packages. >>> >>> It seems that some sort of DEPEND variable that means "I only need >>> this when other packages are building against me" would be useful. >>> Thoughts? >>> >>> Matt >> >> Another similar situation: >> >> https://bugs.gentoo.org/show_bug.cgi?id=342393 > > Maybe the virtual/mesa-build approach that I suggested can be adapted to > other similar situations: > > https://bugs.gentoo.org/show_bug.cgi?id=342393#c23 > > -- > Thanks, > Zac >
Re: [gentoo-dev] Re: How to handle dependencies on protocol headers?
On Fri, Sep 16, 2011 at 12:49 AM, Zac Medico wrote: > On 09/15/2011 09:42 PM, Matt Turner wrote: >> On Fri, Sep 16, 2011 at 12:32 AM, Matt Turner wrote: >>> Often packages depending on X11 libraries will also have to specify >>> the X11 libraries' proto packages in DEPEND. This is because the X11 >>> library itself #includes files provided by the proto package. It's not >>> really that the X11 library depends on this at run-time, so the >>> protocol packages aren't specified in the RDEPEND of the libraries. >>> >>> This is documented in a number of bug reports (see 379545), and it >>> seems that the decision is between >>> - add proto package to dependency list of packages using X11 libs >>> - add proto package to rdepend list of the relevant library itself >>> >>> The first is more correct, I think, but it's also much more annoying. >>> Mesa winds up having x11-proto/inputproto in DEPEND for some long >>> forgotten reason, for instance. >>> >>> The second option is much simpler and less error prone, but removes >>> the ability to depclean the proto packages. >>> >>> It seems that some sort of DEPEND variable that means "I only need >>> this when other packages are building against me" would be useful. >>> Thoughts? >>> >>> Matt >> >> Another similar situation: >> >> https://bugs.gentoo.org/show_bug.cgi?id=342393 > > Maybe the virtual/mesa-build approach that I suggested can be adapted to > other similar situations: > > https://bugs.gentoo.org/show_bug.cgi?id=342393#c23 That would no doubt help the case of Mesa, but as can be seen by http://tinderbox.dev.gentoo.org/misc/rindex/x11-proto/ , there are lots of other cases as well. Matt
[gentoo-dev] Re: x32 fun pants
Mike Frysinger posted on Thu, 15 Sep 2011 17:18:43 -0400 as excerpted: > On Thursday, September 15, 2011 17:03:07 Michał Górny wrote: >> On Thu, 15 Sep 2011 16:33:48 -0400 Mike Frysinger wrote: >> > On Thursday, September 15, 2011 16:12:00 Michał Górny wrote: >> > > On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote: >> > > > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. >> > > > instead, reusing "amd64". >> > > Hrm, wouldn't that be more like x86 keyword? AFAICS the type sizes >> > > for x86 and x32 would match. >> > >> > the sizeof(long) and sizeof(void*) are the same between x86 and x32. >> > however, that's about the only thing. for example, x32 gets access >> > to 64bit registers when working with 64bit types (long long) and the >> > tuple is x86_64-pc-linux- gnu. in general, it seems to be closer to >> > amd64 than x32. >> >> I'm rather thinking about potential issues. But OTOH packages fixed for >> amd64 should probably work with x32 as well. Excluding asm code which >> would probably need a third variant then. > > yes, inline asm might need tweaking[.] > they'll need to have gcc take care of it > but i'd rather not introduce another KEYWORD when we can simply p.mask > the package, or disable the asm when ABI == x32. My immediate thought, probably unworkable for some reason but from here it looks useful for at least (what would be) ~x32 and as a jump-start on the number of ~x32 packages, and it should at least prove educational to have it shot down ()... Have an x32 keyword, but at least for ~arch, have the package managers (or profiles) define some "magic" such that ~amd64 AND ~x86 == ~x32 (likely as EAPI-N, if delegated to the package managers). It seems to me that if the package is ~arch keyworded for both ~amd64 and ~x86, it should be reasonable to consider it ~x32 as well, and that would enormously jump-start the available packages list and remove the necessity of adding all those keywords. Further, -x32 could then be used for specific cases where ~x32 was NOT desired from the combined ~x86/~amd64 keywords, and as packages were actually tested stable, they could be x32 stable-keyworded or -x32 keyworded (or profile package.masked) as appropriate. The same could obviously be tried for x32-stable based on x86 AND amd64, but that seems far more problematic, while the existing practice of simply carrying forward ~arch keywords without individually testing each ~arch is only extended slightly, and ~arch users (no matter the arch) should already by policy be prepared to cope with and fix occasional breakage. OK, shoot it down. =:^) Or do as suggested elsewhere and combine all three into ABIs of the same arch keyword, making the issue moot. This is the best excuse we're ever likely to get, for that, and over time as it deprecates, I expect legacy x86 to appreciate the extra arch-team manpower they'd otherwise be losing as they faded into minority and eventually obscurity. And with x32, the cooperation between the two existing arch-abis will need to grow, in any case. But whether it's arch-team politically feasible, I don't know... I believe that's what stopped the idea the last time it came up, but that was before this whole x32 thing, which does quite change things. -- 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] udev and /usr
On Friday, September 16, 2011 12:27:19 AM Michał Górny wrote: > On Fri, 16 Sep 2011 00:13:15 +0200 > > Joost Roeleveld wrote: > > I think systemd is nice for desktops/laptops. But on servers it seems > > to be overkill to me and as I umount filesystems as part of my > > backup-scripts, having something force-mount them in the background > > is going to kill those scripts. > > But this bit is off-topic. > > It's all about replacing 'umount' with 'systemctl stop'. But if you > don't use automount, I don't think systemd will actually interfere. That's something that needs to be looked into. I tell apache to switch to a maintenance-page which is on a filesystem that doesn't get umounted. Then I umount the websites for the backup. The changes to the script would require more work. If openrc stays with a classical init, then I will be happy. Systemd is nice for desktops. And systemctl will try to remount the filesystem when simply using umount: http://archives.gentoo.org/gentoo- user/msg_0883f3103a3fa025cc2121117169a287.xml -- Joost
Re: [gentoo-dev] How to handle dependencies on protocol headers?
On Fri, 16 Sep 2011 00:32:49 -0400 Matt Turner wrote: > Often packages depending on X11 libraries will also have to specify > the X11 libraries' proto packages in DEPEND. This is because the X11 > library itself #includes files provided by the proto package. It's not > really that the X11 library depends on this at run-time, so the > protocol packages aren't specified in the RDEPEND of the libraries. This is a build-against dependency, and it's best expressed either by its own BADEPEND, or (because it's apparently now possible, and because otherwise we'd end up with six or seven *DEPEND variables) by switching to something like DEPENDENCIES with a build-against label. If the Portage guys aren't winding us up when they say that they could handle something like DEPENDENCIES without major code changes these days, then it could be on the cards for EAPI 5. -- Ciaran McCreesh signature.asc Description: PGP signature
