Re: [gentoo-dev] making USE=upnp a global flag
On Sun, 2012-09-30 at 17:44 +0200, Gilles Dartiguelongue wrote: Le mercredi 19 septembre 2012 à 10:19 +0200, Michał Górny a écrit : Just to make it clear: - USE=upnp for upnp-igd or nat-pmp, - USE=dlna for the video magic and so on. Do I understand correctly? No, TV makers and others advertise UPnP as DLNA (digital living network appliance) but that actually refers to both port forwarding (eg. used in consoles) and to media streaming (eg. PC to TV). DLNA is actually a subset of UPnP with some strict certification rules. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Tue, 2012-09-11 at 20:01 +0200, Luca Barbato wrote: On 9/10/12 11:05 PM, William Hubbs wrote: On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote: On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote: In researching this program, I have found that it and ifplugd, which is the alternative, have been unmaintained for years. Also Debian has declared netplugd to be obsolete in favor of ifplugd. Does anyone have any thoughts about whether we should keep OpenRC support for one or both of these? The ifplugd author recommends you use NetworkManager for dynamic networking scenarios. NM seems bloated though unless you are using a desktop environment. It wants to install 29 dependencies on my box. NM and connman are quite a bit overkill indeed. If you're on a server, you probably want a static configuration anyway, not something dynamic. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote: In researching this program, I have found that it and ifplugd, which is the alternative, have been unmaintained for years. Also Debian has declared netplugd to be obsolete in favor of ifplugd. Does anyone have any thoughts about whether we should keep OpenRC support for one or both of these? The ifplugd author recommends you use NetworkManager for dynamic networking scenarios. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] FYI: multilib-strict no longer in FEATURES of targets/developer/make.defaults (pending on bug 424423)
On Mon, 2012-08-13 at 17:56 -0400, Mike Gilbert wrote: On Mon, Aug 13, 2012 at 2:29 PM, Alexandre Rostovtsev tetrom...@gentoo.org wrote: On Mon, 2012-08-13 at 11:14 -0700, Diego Elio Pettenò wrote: Beside the fact that these would probably have looked better in /usr/libexec See Kay Sievers's comment at https://bugs.freedesktop.org/show_bug.cgi?id=51617 : /usr/lib/pkgname/ is a directory like /usr/libexec/ or even /bin. It shares absolutely zero things with the arch-specific $libdir ,or lib64/. /usr/lib/pkgname/ is the canonical application private directory. It has the multi-lib or arch-specific rules as /bin. So... where should GRUB2 be installing its modules? Currently they get installed in /usr/$(get_libdir)/grub/$cpu-$platform, where cpu and platform are determined by use flags. Should we drop the get_libdir and put them in /usr/lib/grub instead? Should I even worry about it? There really have no reason to be in $(get_libdir) as they're not compiled for the platform implied by $(get_libdir) ! -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Thu, 2012-08-09 at 10:42 +0200, Luca Barbato wrote: On 08/07/2012 09:00 PM, Olivier Crête wrote: I expect that in the not so long term, systemd will become an essential user-space component of desktop Linux, just like crond, syslog, dbus, udev or glibc. Sharing that code just makes sense, that allows As in completely optional and easily replaceable? That would be a nice improvement over the current use it or die attitude. Sure, you can use bionic and use a shell script as your PID 1. But no one would do that as part of a desktop/server computer. Repeat after me: having your first process require anything more than libc is stupid and dangerous. It's lucky that systemd only requires libc, libc-like libraries (libselinux, libcap, libaudit, librt, etc) and it's own libraries (ie, maintained by the systemd team) then? Most ideas behind systemd are interesting, their current implementation is sometimes completely wrong and given the experience with pulseaudio we all know that they won't change even if you provide code for it. This is bullshit, if you have good reasoned arguments, Lennart is a very reasonable guy, but if you just say your ideas are shit, you code is terrible, then yes, he'll just ignore you. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Thu, 2012-08-09 at 13:31 -0500, William Hubbs wrote: On Thu, Aug 09, 2012 at 11:12:46AM -0700, Olivier Crête wrote: Most ideas behind systemd are interesting, their current implementation is sometimes completely wrong and given the experience with pulseaudio we all know that they won't change even if you provide code for it. This is bullshit, if you have good reasoned arguments, Lennart is a very reasonable guy, but if you just say your ideas are shit, you code is terrible, then yes, he'll just ignore you. Sorry to call you on this one, but that is not the experience I had. I proposed adding configure switches to their build system to accomodate source base distros, such as gentoo, who at times want to use udev without systemd. I even went out of the way to make sure that I didn't change their default settings. Look at a thread on their ml called minimal builds along with their wiki page on minimal builds for Lennart's answer. He even went so far as to say that our package managers are broken, and there was absolutely no negotiating this point. We are wrong as far as he is concerned. He has a perfectly reasonable argument that build time is really not something you should be optimising for. Build systems easily become overcomplicated if you try to make everyone happy, you do have to make choices. Anyway, I'm not sure how that's related to the quality or design of systemd. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Questions about SystemD and OpenRC
On Thu, 2012-08-09 at 19:00 -0400, Walter Dnes wrote: On Thu, Aug 09, 2012 at 01:44:25PM -0500, Canek Pel??ez Vald??s wrote On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato lu_z...@gentoo.org wrote: Obviously it is always fun seeing people first say accept it or fork it, then do not keep your fork you are wasting time once somebody starts forking and/or working for an alternative. By all means, fork it. Just allow Gentoo users to use udev/systemd as upstream intended. And while we are at it, don't put OpenRC in the dependency list of baselayout, otherwise it gets pulled in (and sysvinit with it) for all systemd users even if we don't use it at all. Good idea. While we're at it, please also let's not make systemd/udevd/dbus/pam mandatory. Can we also have a desktop that doesn't use X? -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Questions about SystemD and OpenRC
Hi, Let's cut the FUD. On Tue, 2012-08-07 at 08:47 -0400, Sylvain Alain wrote: 1. The SystemD and Udev projetcs are merged now, so what is the impact on the Gentoo on a short term period ? Only the build system is merged, they're still separate binaries. 2. I saw on some lists that Gnome/Kde and Xfce plan to use some SystemD API, so does it means that we will need to install SystemD aside of OpenRC ? The APIs that GNOME is using from systemd are simple, well designed and well documented D-Bus APIs [1][2][3]. They are implemented by simple binaries separate from the core systemd. Legacy init systems can just re-use them as-is. Also, systemd includes logind, which replaces ConsoleKit with a much better design. 4. Finally, is there any reason why Gnome/Kde/Xfce wants to add deps related to SystemD ? I don't understand why these desktops want to depend on a specific Sysint Old versions of GNOME (and KDE, XFCE, etc) had to have distro-specific code for a bunch of things, such as changing the timezone, the system locale or the hostname. Because these things are in separate places in every distribution for historical reason. So every desktop had to re-implement these things for every distribution, making a lot of duplicated code. The goal is to have a single set of tools using a common D-Bus API that you only have to implement once per distribution and that every desktop can use. 3. In a long term vision, can OpenRC still exist on a Gentoo box(OpenRC might be able to boot the box then give the control to SystemD/Udev for the rest of the boot process) or we will need to migrate to SystemD to be able to use Gnome/Kde or Xfce ? I expect that in the not so long term, systemd will become an essential user-space component of desktop Linux, just like crond, syslog, dbus, udev or glibc. Sharing that code just makes sense, that allows distributions to focus on their strength instead of having to maintain a nightmare of shell scripts. Sure you can do a Android and write your own crappier version, but that doesn't gain you anything. Refs: [1] http://www.freedesktop.org/wiki/Software/systemd/hostnamed [2] http://www.freedesktop.org/wiki/Software/systemd/timedated [3] http://www.freedesktop.org/wiki/Software/systemd/localed [4] http://www.freedesktop.org/wiki/Software/systemd/logind -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, 2012-08-06 at 13:56 +0200, Fabian Groffen wrote: While OpenRC is likely perfectly capable of starting/stopping daemons as a normal user (with some tweaks), I expect systemd replacing init, to already have a fair bit of isssues with being just a normal unprivileged user. I may be wrong, of course. However, the notorious reputation of that piece of software aiming for system-domination doesn't really make it sound to me like it ever will be a good match for Prefix. You happen to be wrong. systemd runs perfectly as non-pid-1. Part of Lennart's well published plan for world domination is to use systemd as a session manager, so it would replace gnome-session, etc. Lennart friends are currently pushing kernel patches to make it fully recursive (such as being able to re-parent orphaned processes to the session's systemd instead of the global one. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, 2012-08-06 at 20:28 +0200, Fabian Groffen wrote: On 06-08-2012 11:16:52 -0700, Olivier Crête wrote: On Mon, 2012-08-06 at 13:56 +0200, Fabian Groffen wrote: While OpenRC is likely perfectly capable of starting/stopping daemons as a normal user (with some tweaks), I expect systemd replacing init, to already have a fair bit of isssues with being just a normal unprivileged user. I may be wrong, of course. However, the notorious reputation of that piece of software aiming for system-domination doesn't really make it sound to me like it ever will be a good match for Prefix. You happen to be wrong. systemd runs perfectly as non-pid-1. Part of Lennart's well published plan for world domination is to use systemd as a session manager, so it would replace gnome-session, etc. Lennart friends are currently pushing kernel patches to make it fully recursive (such as being able to re-parent orphaned processes to the session's systemd instead of the global one. Good to know that I'm wrong. I didn't know they pursued world domination too. I wonder how kernel patches go well together with being in an environment unknown to you, or that you cannot control at all, though. Seems there is interest for it to support Prefix then. Looking forward to patches and solutions to complement the challenges of this year's GSoC task. I think they only want to support systemd-in-systemd, not systemd-in-random-init-system. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Wed, 2012-07-18 at 18:24 -0700, Matthew Marlowe wrote: It would be nice if a sensible structure could be proposed and agreed by ALL Linux distributions (coordinated with BSD). +1 If a new file system standard is required, my preferences based on a history of what is worked and changed over the last 20-30 years would be: - OK with requiring / and /usr on the same FS. This has become common practice with virtualization and small system deployments, and I haven't seen any compelling advantage for keeping separate on larger boxes. No one proposes that, the only requirement that you have for modern Linux to work well is that if /usr is on a separate partition, you need to mount it before starting your main system (ie, from an initramfs). - NOT OK with limitation on allowing /var, /opt, /home, or any other common server mount points to require use of initramfs/initrd. There is enough disagreement as to the reliability and ease of maintenance of initramfs/initrd that it should not be needed for common server deployments. This is clearly not needed, /run was even invented to allow /var to be mounted later. - It would be nice if the rootfs used a snapshot based filesystem and if the bootloader was intelligent enough to easily allow admins to boot to older snapshots as an expectation for any standard modern unix system. One of the reasons to put everything in /usr is to allow using a snapshot based FS, so you can run a system where /usr is read-only and where when you can do all upgrade atomically by writing your changes to a read-write snapshot and then switch all at once. So you never have any half-upgraded package on your system. - Ideally, server motherboards would come with flash based storage where sysadmins could install rescue environments as part of a normal unix install, and that the boot loader or bios would be smart enough to provide the option to boot from it automatically whenever a normal boot failed. - NOT OK with removing the distinction between user and system binaries. Essential binaries required to boot and troubleshoot system problems should be located separately from user binaries. Security sensitive or paranoid admins should be able to make the system binary path read-only or completely remove the user binary directory from roots PATH if they so wish. The rescue system should be entirely separate from the main system, so it survives mishandled upgrades. So having that should not hinder how your main system is built. So you should have it as a separate partition or you can even have it an initramfs (ie, in a single file on the main system). - OK with merging / and /usr, but in that case...why not just move everything in /usr to /...but limit /sbin to system binaries and /bin to user ones? This would be horrible for migrations though and possibly confuse many scripts. The idea of putting everything in /usr instead of / is that you can then make /usr read-only and you can share /usr between multiple systems, while / is read-write and contains /root and /etc. - NOT OK with making systemd the default init system anytime in the next few years, it is way too immature and like most major system software changes...probably will take much longer before it really has the standing to propose being a new standard. I fully expect systemd to be the init system of the next iteration of RedHat Enterprise Linux, which is probably the most enterprise of all distributions, with the most QA and support and everything. It's not a side project of dude of his basement, it has the full support of a large team of people at RedHat. There has probably already been more testing done on systemd today than on OpenRC... - What other elements can new filesystems like btrfs offer that should be considered? ext3/ext4 has worked great with the older standards...but it essentially mimicked the capabilities of older file-systems that the original unix standards were based on. Btrfs might change our expectations. I'm assuming that btrfs will be the standard production fs in a few years. The big thing that btrfs brings is snapshots and subvolumes... So it makes it possible to do atomic upgrades and such. Also, you can have apps be subvolumes and also handled atomically. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote: If somebody really is pushing for an all-out /usr move by all means speak up, but I think that basically what everybody is advocating is trying to follow upstream for individual packages. As I've been saying for a while, doing a full merge of /bin, /sbin, /lib into /usr is probably unavoidable in the long term. We should be ready for it, and even try to do it progressively. As currently, the split is entirely arbitrary. Also be ready for a merge of /bin and /sbin.. I'm sure most people can't even explain the difference between them. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 20:37 -0400, Ian Stakenvicius wrote: On 2012-07-17, at 7:07 PM, Olivier Crête tes...@gentoo.org wrote: I'm sure most people can't even explain the difference between them. /sbin is for bins that only root should be able to run. easy. :) Except when it isn't the case, for example /sbin/ifconfig is a good way to find one's ip address, etc. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 20:37 -0400, Ian Stakenvicius wrote: On 2012-07-17, at 7:07 PM, Olivier Crête tes...@gentoo.org wrote: I'm sure most people can't even explain the difference between them. /sbin is for bins that only root should be able to run. easy. :) Or you can try this experiment and see what breaks: chmod og-rwx /sbin/* /usr/sbin/* -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 23:54 -0400, Richard Yao wrote: On 07/17/2012 07:07 PM, Olivier Crête wrote: On Tue, 2012-07-17 at 18:41 -0400, Rich Freeman wrote: If somebody really is pushing for an all-out /usr move by all means speak up, but I think that basically what everybody is advocating is trying to follow upstream for individual packages. As I've been saying for a while, doing a full merge of /bin, /sbin, /lib into /usr is probably unavoidable in the long term. We should be ready for it, and even try to do it progressively. As currently, the split is entirely arbitrary. Also be ready for a merge of /bin and /sbin.. I'm sure most people can't even explain the difference between them. The difference is simple. You put stuff into /sbin when you do not want regular users to be able to select it via tab completion by default. That's certainly not how te FHS explains it. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Opinion against /usr merge
On Tue, 2012-07-17 at 23:24 -0400, Richard Yao wrote: GNOME is part of the GNU project, so we should be safe unless they decide against portability. OpenSuSe and Mageia are other distributions, so they are not upstream for us. With my GNOME hat on: GNOME does not take any marching orders from RMS or anyone else in the GNU project. We will do any changes that we believe are necessary to produce a better end user experience or to make our code more maintainable. If that means adding dependencies that are Linux specific, we will do it. And we have done it before, for example, we have dependencies on udev for certain features. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: udev - mdev
On Fri, 2012-07-13 at 21:10 -0400, Walter Dnes wrote: On Fri, Jul 13, 2012 at 08:40:20PM -0400, Michael Mol wrote I'll venture a guess the solution will be to create a shim daemon which turns around and launches udev. A quicker-and-dirtier solution would be to create a shim daemon that runs under the the name udev, and passes all calls to /sbin/mdev. Seriously, mdev is a just a bad and now useless hack, it does nothing more than using devtmpfs. You do not need udev for a very simple system. If you system is a bit more complicated, than udev is what you want. It works fine on millions of shipping devices. And on any new embedded platform, one should seriously think about using systemd too. It is very lean, replaces most of the giant, unmaintainable shellscripts that you find in many devices with smaller compiled code, and was designed to be a good fit for embedded devices. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stability of /sys api
On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: I *DON'T WANT* a serious framework, I want a lightweight device manager... period... end of story. Stick with the unix principle of one app doing one thing well. mdev is enough for the vast majority of people. For the people who don't want to easily use USB sticks or digital cameras or gsm dongles or really any modern hardware, I'm sure mdev is fine. A static /dev is even fine for you probably. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stability of /sys api
On Mon, 2012-05-14 at 12:31 -0400, James Cloos wrote: WD cat /sys/block/sda/removable WD 0 Note that a 0 there does not imply that the device cannot hotplug. My USB drive reports 0. And I'm sure it works fine with udev? Those who do not understand udev are condemned to reinvent it, poorly. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
Hi, On Thu, 2012-05-10 at 06:34 +0200, Fabio Erculiani wrote: I think expressing my own opinion about Lennart-made software is my right, after all. I would express my opinion about Fabio made software, but I've never heard of any. Firstly, it's almost impossible nowadays to avoid including avahi, systemd and pulseaudio into a desktop distro so, there is no real choice. This issue became a sensible matter for those users who for instance, wanted to have a silly mp3 player working without going through the PA nonsense, really missing the old ALSA-oh-it-was-always-working days. Maybe the reason every sensible distribution uses Avahi, Pulseaudio, etc is because they are better than other solutions out there? Do you think is a fast conspiracy to make your life suck? I believe engineers in every distribution are looking at what's available and picking what they think is the best solution, and it turns out Lennart is pretty damn good at making useful software. Was alsa always working? I remember spending hours trying to figure out the right control in alsamixer and fighting with alsa's arcane configuration languages (it has 3 different ones). And how do you deal with modern technologies like Bluetooth audio without Pulseaudio exactly? Of course, I am not only bringing my personal opinion here, but the one of the majority of users I've been talking with. I think you only hear from users who like to complain, others are just happy that everything works for them thanks to Pulseaudio, systemd, etc. If you think that Lennart does not solve problems, maybe it's because you don't even understand what the problems were? For example, I encourage you to read about how the dynamic latency in PA allows for lower power usage or how modern audio hardware is designed to use a userspace sound server, etc. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Chromium bundled code
On Mon, 2012-05-07 at 18:23 -0400, Walter Dnes wrote:
On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
On 04/05/12 14:35, Walter Dnes wrote:
What could work is a shim or compatability layer that gets
called, and pre-processes requests and forwards them to mdev.
That's my idea =)
and then, look, you have reimplemented udev.
{sigh}
Actually, more like what udev *USED TO BE*, namely a simple devicei
manager.
Maybe Greg understands how udev was and how it should be better than you
do, since he wrote it.
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: news item for changed polkit default group
On Mon, 2012-01-30 at 14:22 +0200, Samuli Suominen wrote: The default value of AdminIdentities changed to group wheel by upstream since version 0.103. You never mention what the old value was.. useful to figure out if it will cause problems. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 2012-01-06 at 19:41 -0500, Walter Dnes wrote: On Wed, Jan 04, 2012 at 01:51:26PM -0500, Olivier Cr?te wrote No no no, the idea is that once all binaries are in /usr, you can easily share /usr between different systems and do updates in a sane way.. You can also mount /usr read-only, but still have / be read-write. One size does not fit all. It breaks Gentoo horribly. Here's my setup waltdnes@d530 / $ du -s /usr 3057917 usr waltdnes@d530 /usr $ du -s /usr/portage 1394646 /usr/portage waltdnes@d530 /usr $ du -s /usr/src 665069 /usr/src In my 3 gig /usr directory, over 2 gigs are devoted to Gentoo-specific stuff that a binary distro like Redhat does not require. What do we do if /usr is read-only? Symlink or bindmount onto it? You don't understand the purpose of read-only /usr. It has nothing to do with source vs binary. It is for when you have many machines that are identical or at least similar. The idea is that you can mount the same /usr on many machines (using NFS or something like that). So you can have a relatively small / as a r/w nfsroot (containing /etc, /var, /tmp, etc, etc), and then share /usr among all the machines in your cluster or machine room or your many user desktops. With the current system, you either have to maintain in sync the /bin, /sbin, /usr, etc separately, making life harder for everyone. But clearly, you've never been the sysadmin of that kind of setup. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 12:08 +0100, Marc Schiffbauer wrote: I meant hight-level only in a way that it is not really needed to boot the very basic things of a system so that I can get a root prompt at the console at least. E.g. you do not need dbus to find and mount the rootfs, fire a getty and shell. Obviously, you can do init=/bin/sh, that's doesn't help you much. I think we're all speaking of a minimually useful system here. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 12:08 +0100, Marc Schiffbauer wrote: I meant hight-level only in a way that it is not really needed to boot the very basic things of a system so that I can get a root prompt at the console at least. E.g. you do not need dbus to find and mount the rootfs, fire a getty and shell. Obviously, you can do init=/bin/sh, that's doesn't help you much. I think we're all speaking of a minimally useful system here. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 20:08 +, Ciaran McCreesh wrote: On Thu, 5 Jan 2012 13:30:24 -0600 William Hubbs willi...@gentoo.org wrote: Or will /etc move to /usr too? No, /etc isn't going anywhere. Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). Obviously, you'd have to reboot if you made any changes to your config files, but that's OK since you can't safely restart daemons anyway. Dude, the systemd people are not crazy. You should try to understand what they do before criticizing. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 21:09 +, Ciaran McCreesh wrote: On Thu, 05 Jan 2012 16:02:09 -0500 Olivier Crête tes...@gentoo.org wrote: On Thu, 2012-01-05 at 20:08 +, Ciaran McCreesh wrote: On Thu, 5 Jan 2012 13:30:24 -0600 William Hubbs willi...@gentoo.org wrote: Or will /etc move to /usr too? No, /etc isn't going anywhere. Are you sure? I heard a rumour that systemd will soon require you to put /etc inside your initrd (since / can't be mounted without it). Obviously, you'd have to reboot if you made any changes to your config files, but that's OK since you can't safely restart daemons anyway. Dude, the systemd people are not crazy. You should try to understand what they do before criticizing. I don't claim they're crazy. I claim they're sacrificing functionality, correctness, loose coupling, simplicity, well defined behaviour, understandability and stability in order to implement questionable new shiny things. The only thing I see them sacrificing is loose coupling, they provide more functionality than any other init system, more correctness (seriously, did you ever read most init scripts out there?), more well defined behavior (all systemd systems boot exactly the same), more stability (I'll claim that Lennart's C is better than any of the boot-time shell scripts I've seen) and well understandability depends who much you can understand C. Probably a bit less understandable for sysadmins, but since they can just play with config files, it's probably easier to understand in the end (and much less prone to breaking than mucking around shell scripts). -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: news item for sys-apps/systemd - /usr migration
Hi, On Thu, 2012-01-05 at 20:29 -0500, Alexandre Rostovtsev wrote: Negative effects of removing the /bin/systemd symlink on 2021-05-01: an unknown number of users who had forgotten to update their grub.conf will discover that they can no longer boot their systems. I would suggest not removing the symlink unless there is a technical reason why its presence is undesirable. Doing aggressive migrations like that should really be avoided.. But we know that the real long term solution is to have a /bin - /usr/bin symlink. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Fri, 2012-01-06 at 08:44 +0800, Patrick Lauer wrote: On 01/06/12 05:26, Olivier Crête wrote: [snip] The only thing I see them sacrificing is loose coupling, they provide more functionality than any other init system, more correctness (seriously, did you ever read most init scripts out there?), more well defined behavior (all systemd systems boot exactly the same), more stability (I'll claim that Lennart's C is better than any of the boot-time shell scripts I've seen) and well understandability depends who much you can understand C. Probably a bit less understandable for sysadmins, but since they can just play with config files, it's probably easier to understand in the end (and much less prone to breaking than mucking around shell scripts). As you apparently have no idea what a sysadmin does I'd appreciate it if people like you didn't try to guess what would make things better and instead listened to people that have more than their desktop to run. (Hint: It's not pressing reset buttons) I know what they do.. play in random scripts until whatever they're trying to hack together it seems to work, because oh well, its just a one time thing.. and then when stuff breaks they call Red Hat's support line. Given the choice between a single line of shell ( cat $urandom_seed /dev/urandom ) or 145 lines of undocumented C (which, if naively modified by me, might just make systemd segfault) ... there is no choice. Actually, you don't have to do that, systemd does it for you and takes care of all the annoying details [1]. That said, you can trivially disable systemd-random-seed-save.service and systemd-random-seed-load.service and instead write a unit file that runs whatever you want. You don't HAVE to do any C to run stuff from systemd, but it does provide many things written in C that are much more solid than the shell equivalents. I do agree with you on one point - most init scripts are really bad code, but that doesn't mean shell is bad, it means that you need to educate people and file bugs. I've laughed at SLES' /etc/bashrc, I read most of upstart and wondered how ... why ... is it can be drunk tiem? Still that doesn't mean that rewriting it in bad C is in any way more agreeable, and you just made debugging exquisitely painful. Yey. The big reason for C vs shell scripts is that the type of people who write them are not the same.. The type of people who write shell scripts tend to hack together stuff until it works. The people who write C tend to think about the problem for a long time and then write a complete solution that tries to take into account all of the possible error scenarios. [1] http://cgit.freedesktop.org/systemd/tree/src/random-seed.c -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 18:12 +0100, Ulrich Mueller wrote: On Wed, 4 Jan 2012, Michał Górny wrote: What mistakes? The mistake of introducing a pointless separation based on a rule of thumb which becomes more and more blurry over time, and hacking packages just to make it work. There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. The problem is that to boot a modern system, you need a shitload of stuff. For example, modern network filesystems often have secure authentication and probably LDAP too, so that means we need to move ldap and openssl into / and all the dependencies. Also, anything that installs a udev rule needs to be in /, and the list goes on an on. Very soon, you have almost everything in /... This rule made sense in the 80s, but it doesn't match the modern world anymore. Some longer explanations: http://www.freedesktop.org/wiki/Software/systemd/separate-usr-is-broken https://fedoraproject.org/wiki/Features/UsrMove Here is a list of packages on your system that will break if you start udev without /usr mounted: egrep 'usb-db|pci-db|FROM_DATABASE|/usr' /*/udev/rules.d/* |cut -f 1 -d : | sort -u | xargs qfile -e -- Olivier Crête tes...@gentoo.org Gentoo Developer
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Here is a prime example of why vertical integration should really be called a horrible mess of tight coupling... You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. -- Olivier Crête tes...@gentoo.org Gentoo Developer
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Thu, 2012-01-05 at 07:27 +1300, Kent Fredric wrote: 2012/1/5 Ulrich Mueller u...@gentoo.org On Wed, 4 Jan 2012, Michał Górny wrote: There's really nothing pointless or blurry about this separation. The FHS has a nice definition: The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Given that these tools are being moved to /usr and/or duplicated to in initrd , what is the point of a root filesystem anyway now? Just to mount other things on? Just to store /etc ? Or will /etc move to /usr too? /usr/etc somewhat horrifies me. No no no, the idea is that once all binaries are in /usr, you can easily share /usr between different systems and do updates in a sane way.. You can also mount /usr read-only, but still have / be read-write. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 19:30 +0100, Marc Schiffbauer wrote: * Olivier Crête schrieb am 04.01.12 um 18:40 Uhr: On Wed, 2012-01-04 at 15:54 +, Ciaran McCreesh wrote: On Wed, 4 Jan 2012 16:51:12 +0100 Michał Górny mgo...@gentoo.org wrote: /bin/systemctl libdbus-1.so.3 = /usr/lib64/libdbus-1.so.3 Here is a prime example of why vertical integration should really be called a horrible mess of tight coupling... You clearly have failed to realize that d-bus is a now the bus for system messaging and is as much part of the system as syslog or bash. Probably even more so, for example, in Fedora 17, you'll be able to boot without syslog or bash, but you need d-bus. If this was true, we will soon have problems with linux systems that windows had in 1995. IMO a system should *always* be bootable without that high level stuff. And by bootable I mean that you can get a root prompt at least. d-bus is not high-level stuff... For example, you can't use bluetooth without d-bus. Even Android has it.. That said, in the new systemd world, bash is.. Since it's only a UI tools (just like gnome-shell for example). Since you don't need it to boot. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
On Wed, 2012-01-04 at 21:45 +0100, Marc Schiffbauer wrote: That said, in the new systemd world, bash is.. Since it's only a UI tools (just like gnome-shell for example). Since you don't need it to boot. Yeah right. Having dbus for bluetooth is much more important than having a shell. Please remember that there are *way* more server systems running linux without any graphical desktop at all than desktop systems. Please remember that servers and desktops are dwarfed by the number of embedded systems running Linux. Probably more devices are sold running Linux in a single day than the total number of servers in the world... But well, this isn't a number's game. D-Bus is the system bus and bluetooth is just one example of a system level component that uses it. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Hi, On Mon, 2012-01-02 at 10:41 +0200, Eray Aslan wrote: On 2012-01-01 11:50 PM, Olivier Crête wrote: systemd/dracut/etc handles /usr on its own filesystem just fine. What is required is that /usr must be mounted before the pivot_root away from the initramfs. RedHat made some bad design decisions on RPM (.rpmnew files anyone?) and udev. Udev was probably salvagable before systemd but noone has the motivation or the man-power to manage the huge delta that would result now. It would probably amount to forking udev. So people are following along even if they are unhappy. This is completely unrelated to RPMs. And udev was not developed by RedHat, but by a Gentoo developer who works for Suse, then it was maintained by a Suse dev who just very recently joined RedHat. Plus Redhat did not support in-place upgrades last time I checked. So they don't really care for a lot of problems that are important for us. There is a good reason for that, because in-place upgrades are impossible to do safely (and RedHat customers don't accept weird breakages like Gentoo users do). For example, if you replace a library or even a resource file (like a .ui file for GtkBuilder), the only way to make it work is to make sure that no currently running application is using it. And that just can't happen with system libraries like glibc or system packages like udev or dbus. So the only safe way to upgrade those is to reboot. Regarding the original question, I belive there are 2 issues here: 2. Migrating /bin to /usr/bin, /sbin to /usr/sbin etc. For the second point, we should hold on as long as we deem appropriate. Then reconsider and -most probably- move ahead with the migration. Main point is not to break existing installations by making the move too quickly. Give sysadmins time to to adjust, resize partitions if necessary etc. Do not go for half way solutions (i.e. number 2 in the original email). I don't see what breakage would be caused by a big-bang update (move everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really doubt any system has a /usr so tight that adding the couple things that are in / to /usr/bin would break it.. Btw, this also includes /lib* to /usr/lib*. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 2012-01-03 at 12:36 -0600, William Hubbs wrote: On Tue, Jan 03, 2012 at 11:40:02AM -0500, Ian Stakenvicius wrote: Side note - if /lib is getting moved, does that mean /lib/modules is moving to /usr/lib/modules too? So kernel modules are no longer on root? This is an interesting question. I haven't heard one way or the other what is happening with /lib/modules. I doubt the kernel will move its install location, they're a very conservative bunch. But I heard that kmod will start looking for modules in /usr/lib/modules ... -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 2012-01-03 at 13:02 -0600, William Hubbs wrote:
On Tue, Jan 03, 2012 at 01:50:25PM -0500, Olivier Crête wrote:
I don't see what breakage would be caused by a big-bang update (move
everything in /sbin,/bin/,usr/sbin to usr/bin and add symlinks. I really
doubt any system has a /usr so tight that adding the couple things that
are in / to /usr/bin would break it.. Btw, this also includes /lib*
to /usr/lib*.
I think the best way to do this part of it is going to be to just follow
the upstream packages. When they release a new version that installs in
/usr, just allow that to happen. Eventually there will be very little in
/{bin,sbin,lib}, maybe nothing besides a couple of symbolic links like
/bin/sh.
I am not for what fedora is doing with the
/bin-/usr/bin, /sbin-/usr/sbin and /lib-/usr/lib symlinks.
At least the upstreams that work for RedHat and Suse (and that's almost
all system packages) will come to expect that these symlinks exist. For
example, I just heard that kmod will expect kernel modules
in /usr/lib/modules even though the kernel installs them
in /lib/modules.. So yes, upstream will force these symlinks on us too.
A couple years ago, Gentoo was the forward looking distribution, ready
to try radical changes that break existing assumption, like our init
scripts with dependencies or our early use of udev. These days, I see so
much resistance to progress, it makes me sad.
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Tue, 2012-01-03 at 14:35 -0500, Rich Freeman wrote: 2012/1/3 Olivier Crête tes...@gentoo.org: A couple years ago, Gentoo was the forward looking distribution, ready to try radical changes that break existing assumption, like our init scripts with dependencies or our early use of udev. These days, I see so much resistance to progress, it makes me sad. I think the key is to keep huge changes optional to start with. This one feels like it is being pushed upon us. I don't really have a big problem with moving to /usr and all that. However, I do have some concerns with the larger direction that everybody is taking with vertical integration (which this is just a part of). For example, if eventually you can't run gnome without systemd where does that leave bsd gentoo users? Gentoo is about choice, and various upstream efforts are moving in the direction of giving users only one choice - take it or leave it. How do you install KDE and Gnome on the same system when they eventually want different sysvinit implementations. Will the RedHat and Ubuntu of the future have no more in common than Tivo and Android do today? Well, don't worry, the KDE people don't have the will or the means to make their own init system.. And rumor is that Ubuntu may be switching to systemd in the near future too. With a Linux kernel, you already need some Linux specific things like udev, ifconfig/ip, etc. In the new world, you also have a Linux specific init system. The BSD people are free to do whatever they want, they can try to keep up with the Linux kernel, but good luck to them. Or they can stay in the 80s. My advice to them is to admit that Linux is so far ahead that they can't catch up and just join us. Honestly, we should not promote choice at the expense of quality, maintainability and reliability and these are the decisions that have been made by the udev/systemd/etc upstreams. All of the init systems of each Linux distribution has been doing the same thing in slightly incompatible ways, so everyone has to maintain separate init scripts, on each distro you have to remember where to set things like the hostname (/etc/conf.d/hostname, /etc/hostname, /etc/rc.d/hostname, /etc/system/hostname, etc/wtf), etc. One of the key goals of systemd is to reduce this confusion by standardising the boot process across all distributions. Vertical integration is the only way we can make things Just Work for the users, we tried to do abstraction layers (HAL for example), but it has been a failure. In the GNOME project, we're trying to make the Linux desktop awesome, and we plan to fix any part of the puzzle that would prevent us from achieving that goal. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 2012-01-01 at 01:33 -0600, Matthew Thode wrote: On Sun, 01 Jan 2012 02:12:22 -0500 Olivier Crête tes...@gentoo.org wrote: All of my systems currently have a seperate /usr that is mounted at boot. Unfortunately I do agree that this is not something that we can fight. This was brought up earlier and the only thing we can do for people like myself (who mount /usr at boot) is to create a simple initramfs that only has the purpose of mounting /usr at boot. The main thing I don't like about initramfs is that we have to regenerate it any time we update the packages that get included in it. That's why you have dracut to do it for you. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: rfc: locations of binaries and separate /usr
Hi,
On Sun, 2012-01-01 at 12:46 -0600, William Hubbs wrote:
I don't think the /{bin,sbin,lib} and /usr/sbin directories should be
deleted.
However, what I would like to see is that the package maintainers would
be responsible for creating any compatibility symlinks their package
needs, not portage. I don't think it is a good idea to have portage or
any package manager controling the migration.
The other option is to do mv /bin/* /sbin/* /usr/sbin/* /usr/bin; and
then create symlinks from the other dirs to /usr/bin.. That can be done
in big move, it's the way Fedora is going to do it.
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 2012-01-01 at 15:33 +0800, Patrick Lauer wrote: On 01/01/12 15:12, Olivier Crête wrote: Hi, On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote: I have been working with robbat2 on solutions to the separate /usr issue (That is why I have specifically cc'd him on this email) which will allow people to not use an initramfs. If we migrate everything off of the root fs to /usr, all of those solutions become moot. On the other hand, if we don't migrate, we run the risk of eventually having our default configuration not supported by upstream. I think the general consensus among other distros is that initramfs is the new /. Many core elements of the Linux system will start installing themselves in /usr, starting with udev, so we won't have a choice anyway. Also, I doubt it's currently possible to boot a Gentoo system without /usr mounted anyway. initramfs is the new / ... and no one asked if maybe that doesn't really make sense? That people are now actively working on forcing one big system partition is annoying, but I really don't see the need to add a layer or two of complexification just because, well, why not. We're absolutely not forcing a single system partition. We're just saying that the bits required to mount all the partitions you want should be in an initramfs. 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. I also don't see a good reason to not adopt dracut, Make it work and I'll reconsider it, until then genkernel wins by default. re-implementing something that already works and is maintained by a competent upstream seems wasteful to me. I really don't see why people resist using an initramfs so much. What does it add, apart from time to the boot process? For some setups (like my notebook with luks+lvm) there's no reasonable way around it, but on my desktop it's worse than useless. I don't see how it adds time to the boot process. Either you have a single big partition (and then you don't even need an initramfs), or you have multiple partitions and then most of the time is mounting them anyway. The udev/kmod/systemd/dracut effort to standardise the base userspace of Linux is probably scary for quite a few Gentoo-ers as it means that the end result of an installed Gentoo system will be less differentiated than it was before. But it still is a step in the right direction as most of these standardized pieces are much better than what we currently have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 and unmaintained upstream shows that even a relatively large distribution like us can't maintain a competitive base system solution, Eh what? I don't see an advantage in replacing a known-good solution with some random stuff that mostly doesn't work yet just because it's the future. Random stuff that was well though to work together and works well enough that all other major distros are adopting it. adopting the udev/kmod/systemd way will allow us to use all the work that they are doing and instead concentrate on making a better system. Better means no lennartware to me. I want to be able to fully debug init script failures, which systemd makes very hard to impossible. On some machines I have changes in the startup that would mean having to hack up something in C and hope that it doesn't crash init for systemd (what the blp?) You can start services with a shell scripts in systemd, you just have to aim the .service unit file to you shellscript.. Please don't try to bring the GnomeOS vision of having MacOS without paying for it to my computing experience ... Honestly, so many things just work on MacOS and just need hours of tweaking for us.. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 2012-01-01 at 08:53 +, Sven Vermeulen wrote: On Sat, Dec 31, 2011 at 07:59:47PM -0600, William Hubbs wrote: 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. I use a separate /usr with LVM on all my systems. My root partition uses RAID1. And I never had the need for an initramfs of any kind. Also, there are some major hurdles to take when it comes to getting an initramfs working with SELinux. Most initramfs implementations I saw are not SELinux aware, so all changes they make to the system either result in failures when they try, or failures when the root-switch occurs. dracut fully supports SELinux (it's used in Fedora which has this SELinux horror on by default). 3) Try to maintain things the way they are as long as possible. I'm all for this one. But if people really want to focus on initramfs, I'd appreciate some documentation help on it. Not only on how to create one, but also why it is necessary, how to manage initramfs'es, the concepts underlying, etc. Short version: use dracut. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 2012-01-01 at 14:51 -0600, Dale wrote: Olivier Crête wrote: On Sun, 2012-01-01 at 01:33 -0600, Matthew Thode wrote: On Sun, 01 Jan 2012 02:12:22 -0500 Olivier Crêtetes...@gentoo.org wrote: All of my systems currently have a seperate /usr that is mounted at boot. Unfortunately I do agree that this is not something that we can fight. This was brought up earlier and the only thing we can do for people like myself (who mount /usr at boot) is to create a simple initramfs that only has the purpose of mounting /usr at boot. The main thing I don't like about initramfs is that we have to regenerate it any time we update the packages that get included in it. That's why you have dracut to do it for you. Which is keyworded at this point. Stable users do what? This is a discussion about the future... Changing keywords is trivial if we care. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
On Sun, 2012-01-01 at 20:23 +, Ciaran McCreesh wrote: On Sun, 01 Jan 2012 15:21:24 -0500 Olivier Crête tes...@gentoo.org wrote: Honestly, so many things just work on MacOS and just need hours of tweaking for us.. The problem with just works is that when it breaks, it can't be fixed. Not being able to handle /usr on its own filesystem is a perfect example of this. systemd/dracut/etc handles /usr on its own filesystem just fine. What is required is that /usr must be mounted before the pivot_root away from the initramfs. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: locations of binaries and separate /usr
Hi, On Sat, 2011-12-31 at 19:59 -0600, William Hubbs wrote: I have been working with robbat2 on solutions to the separate /usr issue (That is why I have specifically cc'd him on this email) which will allow people to not use an initramfs. If we migrate everything off of the root fs to /usr, all of those solutions become moot. On the other hand, if we don't migrate, we run the risk of eventually having our default configuration not supported by upstream. I think the general consensus among other distros is that initramfs is the new /. Many core elements of the Linux system will start installing themselves in /usr, starting with udev, so we won't have a choice anyway. Also, I doubt it's currently possible to boot a Gentoo system without /usr mounted anyway. 1) Start migrating packages along with upstream and have everyone who has a separate /usr (including me by the way) start using an initramfs of some kind, either dracut or one that we generate specifically for gentoo. The reason I suggest the initramfs, is, unfortunately if we migrate everything, nothing else would work. I also don't see a good reason to not adopt dracut, re-implementing something that already works and is maintained by a competent upstream seems wasteful to me. I really don't see why people resist using an initramfs so much. The udev/kmod/systemd/dracut effort to standardise the base userspace of Linux is probably scary for quite a few Gentoo-ers as it means that the end result of an installed Gentoo system will be less differentiated than it was before. But it still is a step in the right direction as most of these standardized pieces are much better than what we currently have. The OpenRC/baselayout-2 fiasco, not much better than baselayout-1 and unmaintained upstream shows that even a relatively large distribution like us can't maintain a competitive base system solution, adopting the udev/kmod/systemd way will allow us to use all the work that they are doing and instead concentrate on making a better system. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 2011-10-12 at 18:49 +0100, Ciaran McCreesh wrote: On Wed, 12 Oct 2011 23:00:23 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Then please continue with udev in package.mask and kindly stop trying to impose your workflow on the rest of the world. Isn't the point here that the desktop / GNOME OS guys are trying to impose their deep integration, tight coupling workflow upon the rest of the world? We're imposing our deep integration because it's the only way to make a compelling platform that just works, forcing users to tell the computer something the computer already knows is just plain lazy and stupid. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Suggestion for getting rid of udev
On Wed, 2011-10-12 at 00:40 -0400, Walter Dnes wrote: Hi all Recently, there was a firestorm on the gentoo-user list over the idea that udev would eventually require /usr to be on the same physical parition as /, or else use initramfs, which is its own can of worms. I'm not a programmer, let alone a developer. Rather than merely ranting, I went and searched for an alternative. You completely misunderstand what Kay wants, what we are saying that is that you need to mount /usr at the same time as you mount /, which you can still do in your initramfs, etc. That said, we, the GNOME upstream, think that having a separate /usr is a completely stupid idea. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: using /libexec
Hi, On Tue, 2011-09-06 at 13:46 -0500, William Hubbs wrote: we just got the following bug report for openrc today [1]. The solution to that bug is probably to use /lib*/.. instead of /lib/... as the path you use ? On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and this causes breakage in openrc. That sounds like an openrc bug to me. The simplest fix for this would be for us to add /libexec to baselayout and start using it for platform-agnostic code. We have /usr/libexec, so I don't know why we don't have /libexec. Should we? /usr/libexec is not for platform-agnostic code, it is for platform dependant executables that are not meant to be executed directly by the user. /usr/lib/X/Y and /usr/libexec/Y should be exactly the same. You may want to put all the executables in /usr/libexec anyway, as having separate / and /usr is a outdated idea anyway, and most of the other distros will make that completely impossible very soon. Be bold. Fedora is even going to make /lib, /bin and /sbin symlinks to /usr. My 2 cents (as the guy who made the /lib-/lib64 link in the first place). -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: using /libexec
On Tue, 2011-09-06 at 16:45 -0500, William Hubbs wrote: On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote: On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote: The simplest fix for this would be for us to add /libexec to baselayout and start using it for platform-agnostic code. We have /usr/libexec, so I don't know why we don't have /libexec. Should we? same answer as last time people have asked about /libexec: no. we dont need it, and it's ugly cruft that no other distro ive seen uses, and this isnt something we need to differentiate Gentoo. The same thing should be applied to /usr/libexec then shouldn't it? (just asking for more info here) /usr/libexec is used by almost all major distros (except Debian), it has been standardin Red Hat since before the FHS existed. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On Wed, 2011-06-29 at 11:08 +0200, Patrick Lauer wrote: On 06/29/11 03:07, Olivier Crête wrote: Hi, On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote: The background is that /etc/init.d/functions.sh is a link to /lib/rc/functions.sh, which is part of openrc. Other init systems, like systemd, are coming along which completely replace sysvinit and do not use openrc's init scripts at all. However, since things other than init scripts are using /etc/init.d/functions.sh, all gentoo users are forced to have openrc on their systems whether they use its init scripts or not. As you can see in the bug, I am working on creating a minimalist version of openrc that can be installed to allow users to have access to the functions that are in functions.sh regardless of whether or not they are using openrc's init system. I'm not convinced that this is the best approach, so any input would be greatly appreciated. As long as we have Gentoo-style init scripts in the tree, we will need these functions to be available. So yes, they should probably be in a separate package from openrc itself to ease the transition to the bright systemd future. We tolerate the systemd madness as long as it doesn't interfere with other things. But as OpenRC has some rare features (being able to start and stop stuff and being reasonably fast among them) and there's no replacement at the moment I see no reason to add a convoluted mess of insanity just to feel good. I think you're missing how systemd is above and beyond OpenRC (and all other init systems). It has stuff like using cgroups to guarantee that all the processes associated with a service have stopped (openrc doesn't do that), it provides very fast boot (openrc doesn't do that), it can activate services on demand (openrc doesn't do that), etc.. And you also underestimate the amount of momentum that Lennart has managed to amass behind systemd. I expect that much sooner than you think, we won't have a choice but to switch to systemd as many core components will start depending on it. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
Hi, On Tue, 2011-06-28 at 17:10 -0500, William Hubbs wrote: The background is that /etc/init.d/functions.sh is a link to /lib/rc/functions.sh, which is part of openrc. Other init systems, like systemd, are coming along which completely replace sysvinit and do not use openrc's init scripts at all. However, since things other than init scripts are using /etc/init.d/functions.sh, all gentoo users are forced to have openrc on their systems whether they use its init scripts or not. As you can see in the bug, I am working on creating a minimalist version of openrc that can be installed to allow users to have access to the functions that are in functions.sh regardless of whether or not they are using openrc's init system. I'm not convinced that this is the best approach, so any input would be greatly appreciated. As long as we have Gentoo-style init scripts in the tree, we will need these functions to be available. So yes, they should probably be in a separate package from openrc itself to ease the transition to the bright systemd future. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: use of the /run directory
On Wed, 2011-05-18 at 01:18 +0530, Nirbheek Chauhan wrote: Maybe you should use /var/tmp for that? Or ~/tmp/ ? OTOH, we could use an rc.conf configuration variable to control whether /tmp is mounted as tmpfs. Having /tmp and /var/tmp as tmpfs sounds like a terrible idea.. I don't think we should facilitate it in any way. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, 2011-05-17 at 23:20 +0300, Panagiotis Christopoulos wrote: Yes, I can do that. But the real question here, from my perspective, is why we need /run, /var/run or /tmp on tmpfs. Other distros do it is not an answer. The main reason is that you want /run to be writable super early in the boot process, before even / has been fscked and re-mounted. That means you can do stuff like starting udevd in parallel with fsck of / which means faster boot. This is one of the things required to get 1 second boot. See http://lwn.net/Articles/436012/ -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Lastrite: gst-plugins-v4l and xfce4-icon-theme
On Thu, 2011-03-31 at 11:18 +0300, Samuli Suominen wrote: # Samuli Suominen ssuomi...@gentoo.org (31 Mar 2011) # Deprecated and doesn't build since linux-headers-2.6.38. Use gst-plugins-v4l2 # instead. Masked for removal in 30 days. See bug 359647. media-plugins/gst-plugins-v4l Can we stay the execution of gst-plugins-v4l until 2.6.38 is stable? In our stable 2.6.36 release, some drivers have not yet been ported to v4l2. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Please enhance your USE descriptions!
On Wed, 2011-03-30 at 21:56 +0200, Amadeusz Żołnowski wrote: The main problem is that user might not know what kind of “foo” support it is. For example I have “pango” USE flag in sys-boot/plymouth. What would explain to you something like: “Enables support for x11-libs/pango”? And how you would compare it with “Adds support for printing text on splash screen and text prompts, e.g. for password”? I'm sorry, but that's a terrible example.. In this case, it shouldn't be a use flag at all. We shoudl avoid having use flag where the description is Adds support for not being completely broken -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rejecting unsigned commits
On Thu, 2011-03-24 at 17:59 -0400, Mike Frysinger wrote: is there any reason we should allow people to commit unsigned Manifest's anymore ? generating/posting/enabling a gpg key is ridiculously easy and there's really no excuse for a dev to not have done this already. I didn't know we still allowed that.. I guess the CVS server should just reject unsigned Manifests.. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Bugzilla 4 migration
On Mon, 2011-03-07 at 20:47 +0100, Michał Górny wrote: On Mon, 7 Mar 2011 15:48:19 +0100 Tobias Klausmann klaus...@gentoo.org wrote: On Mon, 07 Mar 2011, Mike Frysinger wrote: If *anybody* can't use SSL for any reason please yell so that we can decide if we leave it as it is (plain + encrypted) or not. Is there any *real* reason to force SSL? It is *hell* slow. it should of course be force for logging in If it is enforced for login, it should be enforced for logged in sessions, cf. Cookie stealing (for a POC: Firesheep). And no, restricting the login cookie to an IP is *not* safe enough. Why does everyone assume it needs to be enforced? If user is interested in protecting his/her data, he/she can simply use https://. If he/she is not, there is no real reason to enforce slower (and not always supported) SSL. Maybe it's not to protect the user, but to protect the Gentoo infrastructure.. And really, SSL has been supported by every browser for the last 15 years. And it is not in any way slow or slower than non-SSL. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Mon, 2010-08-23 at 17:05 +0200, Gilles Dartiguelongue wrote: Le lundi 05 juillet 2010 à 08:57 +, Duncan a écrit : [lots of stuff about bashisms and posix] So let's stabilize OpenRC and be done with it, and /then/ we can debate where we want to go from there. YES, let's get it stable. However please consider not re-adding bashisms and/or not make it less POSIX shell compliant than it already is at light speed. It is a great thing that openrc tries to achieve and allows more use of openrc than basic desktop/server gentoo usage (think embedded and other distros). At least one other distro did this move a while ago (debian) and I don't think they will go back. Seeing they are also moving to a dependency based init system, they probably could just run a fork of openrc (for their init scripts are not exactly compatible with what we do). Other distributions are going one step further and are going for shell-free boot. We should follow that lead. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On Mon, 2010-08-23 at 19:09 +0100, Mike Auty wrote: On 23/08/10 18:26, Olivier Crête wrote: Other distributions are going one step further and are going for shell-free boot. We should follow that lead. Why? Presumably they're doing it by writing programs that do their own parsing and executing, which means they'll need a maintainer just for that program and they'll have to go through a few iterations to get the initial bugs out, and then people will have to learn how to use the different-yet-again language that goes with it. Why not rely on a prebuilt parser that devs already have to know to look after ebuilds? Systemd uses ini style files for configuration (and symlinks). So there really isn't much of a parser in there. And obviously, they're going through some bugfixing right now, so when F14/F15 are out there, we can just take their complete solution ;) -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] The future of sys-apps/openrc in Gentoo
On Sun, 2010-07-04 at 18:15 -0400, Mike Frysinger wrote: which is trivial to fix and anyone with commit privs could have done. it certainly doesnt warrant a paniced the sky is falling message. I think this is a great occasion to dump our stupid custom crap and switch to SystemD, PolicyKit, NetworkManager, etc. Anyone with half a brain already dropped our stuff. And the lack of use of modern tools is the reason I don't use Gentoo on my work computer anymore. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote: Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then just drop the old ebuild. These arches will slowly lose stable keywords until their stable tree gets to a size that they can manage. And everyone will be winners. That said, when dropping the old keywords, you have to be careful to drop the stable keyword on all dependencies too so as to not drop break the tree for them. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Policy for late/slow stabilizations
On Sun, 2010-06-27 at 18:54 +0300, Markos Chandras wrote: On Sun, Jun 27, 2010 at 11:47:49AM -0400, Olivier Crête wrote: On Sun, 2010-06-27 at 18:04 +0300, Markos Chandras wrote: Moreover, slow arches introduce another problem as well. If a package is marked stabled for their arch, but this package is quite old, and they fail to stabilize a new version, we ( as maintainers ) can't drop the very old ( and obsolete ) version of this package because we somehow will break the stable tree for these arches. How should we act in this case? Keep the old version around forever just to say that hey, they do have a stable version for our exotic arch. I'd propose waiting a bit longer than 30 days.. Maybe 90 days, and then just drop the old ebuild. These arches will slowly lose stable keywords until their stable tree gets to a size that they can manage. And everyone will be winners. That said, when dropping the old keywords, you have to be careful to drop the stable keyword on all dependencies too so as to not drop break the tree for them. When dropping an old *stable* ebuild, which in most cases this will be the only stable ebuild that these arches will have for this packages, the next world update will be ugly since there will be no *stable * candidates for that package anymore. In this case, stable users will start filling package.keywords leading to ~testing migration. So I am not sure if this is the correct approach to deal with this but I can't think of anything else That's ok. That way those users will know that no one from the arch team maintains that packages and they will know it has a lower level of QA. And the users will be able to make a choice. Instead of pretending that it is maintained. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Fri, 2010-06-25 at 13:00 +0400, Peter Volkov wrote: В Птн, 25/06/2010 в 14:19 +0530, Arun Raghavan пишет: On 25 June 2010 14:15, Peter Volkov p...@gentoo.org wrote: В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет: [...] Or you could review the changes before pushing (since in git these operations are separate). And live with the consequences of your mistakes! No. We are humans and thus mistakes are unavoidable. He didn't say don't make mistakes. He said, be careful and if mistakes happen, so be it. And I disagreed. This is unacceptable since we are talking about credits to our users. It's like paying salary to random person and blaming tools after that. You can just make a new commit with just a message saying Hey, last time I was wrong, this is from A, not B if you care enough. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On Thu, 2010-06-24 at 20:59 +0200, Luca Barbato wrote: On 04/13/2010 01:25 PM, Peter Volkov wrote: В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет: * It makes zero sense to manually manage ChangeLogs in git[1] Once I had stupid cutpaste mistake and entered wrong credits in ChangeLog. I don't see how to resolve this issue in case ChangeLog's will be generated from git log and until somebody suggests how to edit ChangeLogs generated from git I think have to keep ChangeLogs in gentoo-x86. We could abuse git-note Or you could review the changes before pushing (since in git these operations are separate). And live with the consequences of your mistakes! -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: New global USE flag: introspection
On Mon, 2010-06-21 at 09:07 +, Duncan wrote: Paweł Hajdan, Jr. posted on Mon, 21 Jun 2010 09:04:03 +0200 as excerpted: On 6/21/10 8:53 AM, Arun Raghavan wrote: On 21 June 2010 11:43, Alexis Ballier aball...@gentoo.org wrote: introspection: Add gobject-introspection support, allowing for the dynamic generation of bindings for various languages gobject-introspection ? exceedingly verbose introspection is similarly too general. gobj-bindings ? Bindings is a common enough term in use flag descriptions, etc, that users should at least have an idea what it means. Introspection? Not so much. It's not the bindings... It's introspection data that describes the API. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New global USE flag: introspection
On Sun, 2010-06-20 at 20:12 +0530, Arun Raghavan wrote: I'd like to propose a new global USE-flag: introspection. ... Any objections? I'll wait till Wed (June 23rd) before adding this if there aren't any. Do we really want it to be a USE flag ? I would force it on always for everyone. Due to the direction in which GNOME is heading, it will be required by the core desktop anyway. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Stabilization of Python 3.1
On Sat, 2009-09-19 at 12:21 -0500, Dale wrote: Dirkjan Ochtman wrote: On Sat, Sep 19, 2009 at 19:06, Alex Legler a...@gentoo.org wrote: What is the point of stabilizing it if users shouldn't use it as main interpreter? Just leave it in ~arch until it can be safely used. Making it easily available so that people can port stuff, so that the entire world may be able to use it as their main interpreter sooner? Seriously, it's out there, there's no reason to keep it from stable. Just prevent people from making python invoke 3.x and everything will be fine. Isn't ~arch supposed to be for testing? Isn't that the point of having ~arch? ~arch is for testing ebuilds, not the upstream package -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Ideas for a (fast) EAPI=3
On Thu, 2009-04-09 at 04:51 +0300, Mart Raudsepp wrote: --disable-dependency-tracking: == possible breakage of (custom) configure scripts that don't accept unknown arguments. Would be nice to pass that for most packages, but doing it always with econf seems slightly inappropriate, given the above. Don't think this is an item for fast-tracked EAPI-3. I'm not a big fan either of this one either, when stuff is patched, you may not want that disabled. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] media-video/mpeg4ip to give out or give up
Hello, mpeg4ip is dead upstream and has various bugs [1] (some we patch, some we don't). I'll package.mask/remove it if no one wants to take it over (and effectively become upstream). [1] http://bugs.gentoo.org/show_bug.cgi?id=190959 -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Maintainence of /usr/portage/skel.* and some updates for skel.ebuild
On Tue, 2009-03-10 at 20:42 +0100, Thomas Sachau wrote: I would like to know, if there is some policy about editing skel.* files or who owns/maintains them. Additionally, i suggest some changes to skel.ebuild: -fix the comment for inherit (afaik $(getlibdir) is provided by multilib eclass) -comment out the inherit line -comment out DEPEND and RDEPEND -remove the || die from econf -comment out the complete src_compile It may also be a good time to think about updating skel.eclass to use EAPI=2 -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] How to speed up maintenance and other Gentoo work?
On Wed, 2009-03-04 at 03:26 +0100, Peter Alfredsen wrote:
On Wed, 04 Mar 2009 04:01:36 +0200
Mart Raudsepp l...@gentoo.org wrote:
I'm collecting ideas from the wider development and contributing
community on how to help maintainers and contributors get work done
quicker, or rephrased - how to get more done in the limited time we
have.
Something like what Debian does where a central service monitors
upstream ftp and notifies you when a bump is available.
Per-package eclasses - eblits standardized.
Crazy idea: Not-quite-eclasses. Some way to share small bits of code
between packages, though the code may not be eclass-worthy. We all know
the use-cases:
[[ -f ChangeLog ]] \
{ dodoc ChangeLog || die ChangeLog exists but cannot be dodoc'ed ; }
And bits of code of that ilk.
Maybe we could use the dev wiki for that kind of stuff?
Having a wiki.gentoo.org would be even better...
--
Olivier Crête
tes...@gentoo.org
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 01:00 +0100, Jean-Marc Hengen wrote: So this is about, if the current policy for using EAPI 2 in the tree is really good or it should be improved, when introducing future EAPI's, where portage supporting that EAPI is still unstable. My proposal would be, to only use new EAPI with a new version or revision and also let the last non new EAPI version for unstable packages in the tree. This would allow users of that unstable package with stable portage to not downgrade or maintain their local version or forced to upgrade portage. This would be a start. I guess, I'm not the only one, having such a setup and it prevent user's like me testing unstable packages. I need my PC on a daily basis, I can't afford, having it to reinstall, only because I played with unstable software. That's why I'm strict, when it comes to system packages or important packages to me (and I have to congratulate the gentoo devs for their work, my system just works like a charm and I'm very happy with gentoo, only hardware failures could make me headaches). So what I expect, is to find out, if setups like mine can or should be somehow supported. I'm fine, when the outcome is, that I won't be supported, then I know and should rethink my strategy to manage my gentoo boxes. As a arch developer and mostly stable user, I also find this very frustrating. I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 00:11 +, Ciaran McCreesh wrote: On Mon, 08 Dec 2008 19:09:50 -0500 Olivier Crête [EMAIL PROTECTED] wrote: I'd like to go further and ask that for the next EAPI change, we only allow ebuilds using it into the tree once a version of portage that supports it has gone stable. And then, not make any ebuild with the new EAPI stable for 60 more days so that the new EAPI related code in portage can be tested properly. The can be tested properly phase is when it's in ~arch... That also means that to pull a significant number of ebuilds it forces mostly everyone to test it.. and that part is annoying.. The testing should be two phased, the first for regression (against existing ebuilds), and once thats stable, then we can test with new ebuilds... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 2 policy for portage tree
On Tue, 2008-12-09 at 00:29 +, Ciaran McCreesh wrote: On Mon, 08 Dec 2008 19:25:44 -0500 Olivier Crête [EMAIL PROTECTED] wrote: The testing should be two phased, the first for regression (against existing ebuilds), and once thats stable, then we can test with new ebuilds... Uh, regression testing's handled by the package manager's extensive set of unit tests, which can cover this with targetted accuracy with much more reliability than making sure random ebuilds still work. We all know that portage doesn't have an extensive testing suite... And that test suites can't cover all the cases that the whole tree does... What you're suggesting here is making everyone wait four more months for no increase in safety. I'm not suggesting waiting any longer, just not pushing ebuilds into the tree until we have a stable enough version of portage that handles them (and if we do, then lets mark it as stable..). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Flags to punt (including: kerberos USE flag)
On Fri, 2008-10-31 at 19:44 -0700, Josh Saddler wrote: mikmod - Seriously, how many folks make it a habit to listen to .MOD music all the time? Even netlabels like Monotonik, which started *out* as .mod, make it harder to find their old .mod stuff. Agree ldap - Punt for the same reasons kerberos is being punted. Thats used by some public services like keyserver.pgp.com, so I think it should stay there. eds - Down with more Evolution things! Though possibly not ideal for Gnome user? That's a non-starter, we need to keep it in the gnome panel to have the nice integration.. There is an argument to be made that it shouldn't be a use flag in the panel maybe. esd - no one should be using Enlightenment Sound Daemon, period. Ain't it deprecated, anyway? No worky? DIE DIE.. Maybe we should replace it with pulseaudio ? emboss - Seriously. Who needs the European Biology Open Software Suite on a *desktop* oriented system? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] giving up app-laptop/i8kutils
Hi, My Inspiron has died so I can no longer test app-laptop/i8kutils, so I can't really maintain it anymore. If any dev wants to take it, its all yours. If there is a user who want to maintain it, I can proxy. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] FHS compliant KDE install and multi-version support
On Sun, 2008-09-07 at 02:05 +, Jorge Manuel B. S. Vicetto wrote: I've been thinking on a different method. With this method [3], we would keep using the major.minor slots (4.1, 4.2, etc) so we also wouldn't break the invariancy. We would allow users to select whether to have an FHS compliant install or not (the way to allow that still needs to be discussed) and we would set the prefix based on that. In case the user wants an FHS compliant install, the eclasses would block all kde packages on other slots - except 3.5 (uses other eclasses) and the live versions (for the above reason that it will always be installed under /usr/kde/live-version). The big problem with that idea is that upgrading from one version to another will be very painful as portage will yell with a million blockers. The only proper way to do it is to stop the /usr/kde madness for everyone and just install everything in /usr like everyone else does, if upstream wanted it to be parallel installable, they would have made it that way (like gnome 1.x vs gnome 2.x). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages up for grabs
On Mon, 2008-08-18 at 16:18 +0100, Tony Chainsaw Vroon wrote: sys-auth/thinkfinger I have a thinkpad with the right hardware, so I can take this one, did you already pimp out your other thinkpad packages? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Should 'imlib' USE flag be on by default in x86 and amd64 desktop profiles?
On Fri, 2008-07-25 at 15:00 -0400, Jim Ramsay wrote: I've run into it a few times now that fluxbox users running Gentoo wonder why they can't get icons to work in the fluxbox menus. The short answer is that 'imlib' is off by default in many profiles, including default-linux/amd64/2007.0/desktop and default-linux/x86/2007.0/desktop I know that I could turn it on by default for fluxbox only using EAPI-1, but since it's a global USE flag, the profiles may be a better place. I think imlib is something most desktop users would want, since it lets them see all those pretty graphics. Comments? Concerns? imlib is unmaintained/deprecated. So I don't think it makes sense to push it by default to users using GNOME/KDE at least (because they have better image loading libraries). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer
Re: [gentoo-dev] system set no longer in part of world set
On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote: This brings out the fun of circular depends. I don't really know how to address this but a lot of packages are going to have to be updated to contain proper depends. i.e. C based apps will need RDEPEND=virtual/libc. C++ packages will need a stdc++ depend. Adding a dep to libc almost everywhere seems extremely wrong to me. I though we had decided many times that it was a bad idea. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Removing .la files...
On Thu, 2008-06-19 at 14:08 +0200, Rémi Cardona wrote: Why only plugins? What's to stop an application from loading a normal library using libtool's dlopen wrapper (perhaps so it can fail gracefully if the library is missing, for example)? Nothing per se, but I have yet to see any FOSS application dlopen() gtk+ or libpng. FOSS is the keyword here... the flash plugin dlopens a bunch of stuff -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Keyword amd64 - x86_64
On Thu, 2008-02-21 at 16:27 +1100, Andrew Cowie wrote: On Wed, 2008-02-20 at 19:42 -0600, Ryan Hill wrote: But I agree, rekeywording amd64 to x86_64 would probably be more work than it's worth. Can we not just hardwire an alias into the emerge codebase? I must admit, from a purely optical standpoint, the idea of saying my system is amd64 when it is nothing of the sort really grates. If, internally, it just translated x86_64 to amd64 wouldn't that be ok? I really don't see the problem with AMD64, why it would be more wrong than ia32 or x86 (based on Intel's product numbers!). AMD64 was invented by AMD and they get to pick the name for it. The keyword amd64 in Gentoo when Intel was still dismissing AMD64... -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: net-im/gaim and its plugins
net-im/gaim is now called pidgin, I've masked it and all of its plugins, it will be removed in 30 days # Olivier Crete [EMAIL PROTECTED] (08 Dec 2007) # Remove gaim and its plugins (now its called pidgin) net-im/gaim app-accessibility/festival-gaim net-im/gaim-blogger net-im/gaim-bnet net-im/gaim-meanwhile net-im/gaim-snpp x11-plugins/autoprofile x11-plugins/bangexec x11-plugins/gaim-assistant x11-plugins/gaim-encryption x11-plugins/gaim-extprefs x11-plugins/gaim-galago x11-plugins/gaim-hotkeys x11-plugins/gaim-latex x11-plugins/gaim-otr x11-plugins/gaim-rhythmbox x11-plugins/gaim-slashexec x11-plugins/gaim-xfire x11-plugins/gaimosd x11-plugins/ignorance x11-themes/gaim-smileys -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites for sys-auth/pam_keyring
# Olivier Crete [EMAIL PROTECTED] (20 Nov 2007) # There is now a better version include in gnome-base/gnome-keyring sys-auth/pam_keyring It will be gone in one month. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Quick last rites for x11-plugins/gaim-libnotify
Two days ago, I removed the beta versions of gaim 2.x, gaim-libnotify depended on it. It has never been So it has been removed from the tree. It is now called x11-plugins/pidgin-libnotify. The rest of gaim will soon follow -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] new-style virtual/editor
On Fri, 2007-05-10 at 11:46 -0700, Donnie Berkholz wrote: How many packages depend on virtual/editor? Should it be a virtual at all? Tester_ !rdep virtual/editor jeeves virtual/editor - app-admin/sudo sys-process/fcron I think the answer is none that really should, I would favor just removing virtual/editor. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] new-style virtual/editor
On Fri, 2007-05-10 at 20:27 +0100, Stephen Bennett wrote: On Fri, 5 Oct 2007 11:46:29 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: How many packages depend on virtual/editor? Should it be a virtual at all? The system set depends on it, and last I knew didn't allow for any-of deps. Does it really depend on it ? Or is it just a convenient dep so its installed as part of the stage1 ? Why not just put nano in the system (which is was gets pulled into the stages anyway). I see that both sudo and fcron, while they have some versions that depend on virtual/editor actually hardcode nano as the default. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Bugzilla improvements
On Wed, 2007-26-09 at 19:04 -0700, Robin H. Johnson wrote: I went and processed a bunch of pending Bugzilla bugs, and thought folk might be interested in the changes. - Do not reply note at the top of bugmail, and a related Reply-To header. [Bug #181172] Is this really required? It pushes the real content even farther down the window. Or if you really want to keep it for new users, please allow us to disable that. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] net-im/centericq needs a new maintainer
On Sat, 2007-13-01 at 15:39 -0500, Olivier Crête wrote: On Tue, 2007-09-01 at 09:35 +0100, Sune Kloppenborg Jeppesen wrote: net-im/centericq is without an ebuild maintainer and has an open security bug #160793 https://bugs.gentoo.org/show_bug.cgi?id=160793 Anyone willing to take care of this package in the future, please update metadata.xml and CC yourself on the bug. Its also unmaintained upstream and is showing its age. Its now masked and will be removed in 30 days if no one comes forward, and becomes a new quasi-upstream. net-im/centericq has now been removed from the tree. Replacements include centerim and finch (pidgin with ncurses use flag) -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: GPL violations with net-misc/vpnc?
On Fri, 2007-31-08 at 16:31 +0200, Christian Faulhammer wrote: Alexis Ballier [EMAIL PROTECTED]: While we are not distributing binaries, I could easily add a USE flag to enable it; the user compiles it himself, so it is all fine. But now regard the existence of binary hosts, are they distributions of then illegal binaries? isn't bindist useflag made for this purpose ? Great. Thanks...so what is common practice? Should the ebuild die, telling people a feature will not be included or just exclude it with an ewarn only? With bindist, you should just disable any non-distributable feature and print a ewarn.. Dieing is not nice since its used to build the stages, etc. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-15-08 at 14:10 +0100, Roy Marples wrote: OK, so whilst we're gearing up for hopefully the last baselayout-2 release candidate I thought I would pose to the list a question I've been struggling with for some time. Should hotplugged services affect dependencies by default? (Note, this is not about enabling hotplugged services by default which is another topic for debate. Want to talk about that, start a new thread - but save your breath as I have a laptop and think hotplugging is good :P) By default we've always been YES. But I'm starting now that this should be NO. I believe services that don't bind to a specific address should probably only depend on net.lo, not net. So then we separate this that really need the network (and probably only a specific interface and then the user should modify the script to depend on that interface) and those that use the network, but don't really need it (like sshd, etc). That said, I now use networkmanager (to be able to easily select wifi networks), I don't know how integrated into the whole baselayout-2. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Should hotplugged services affect dependencies by default?
On Wed, 2007-15-08 at 15:02 +0100, Roy Marples wrote: On Wed, 2007-08-15 at 10:09 -0400, Olivier Crête wrote: I believe services that don't bind to a specific address should probably only depend on net.lo, not net. Well, they can actually depend on a specific net service too. For example, I have this on my home server in /etc/conf.d/lighttpd RC_NEED=net.vpn You can add those RC_NEED/USE/AFTER/BEFORE directives to any conf.d/ file and it will append to the stuff in the init script. If you can do that, then well, everything else should just depend on net.lo (and not wait for service plugging then). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] net-im/pidgin protocols
On Fri, 2007-20-07 at 00:57 +0100, Olivier Crête wrote: On Thu, 2007-19-07 at 15:22 -0700, Chris Gianelloni wrote: On Thu, 2007-07-19 at 16:02 -0600, Jim Ramsay wrote: I'm all for doing it now in the profile, but it's not my package. Perhaps someone from the net-im herd can make this decision? Well, as someone who spends a lot of time working on/with profiles, I say go for it. Since these changes would only affect the one package and wouldn't pull in any strange dependencies on people, we should probably do it as high in the profile structure as possible (base? default-linux?) so it hits the most users. I'd like to hear from net-im, as they're ultimately responsible, but I don't really see the harm in doing it, so we probably should as it will reduce headaches for our users. Talking with my net-im hat, I'd say go for it.. Except for silc and zephyr (which may or may not work very well) and should probably stay off. Again with my net-im hat, I've removed the MSN use flag from net-im/pidgin-2.0.2 (the latest version). The other protocols are rarely used and have nasty dependencies and will stay as use flags. I consider this discussion closed. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: net-im/pidgin protocols
On Fri, 2007-20-07 at 14:40 -0700, Chris Gianelloni wrote: Anyway, if nobody objects and nobody beats me to it, I'll add the USE flags for the common protocols to package.use in the profiles. Now, the real question is what should I enable? All of the ones that have no major dependencies are enabled by default and have been for a while... The other should really stay off by default. I don't think adding it them to the profiles is wise.. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] net-im/pidgin protocols
On Thu, 2007-19-07 at 15:22 -0700, Chris Gianelloni wrote: On Thu, 2007-07-19 at 16:02 -0600, Jim Ramsay wrote: I'm all for doing it now in the profile, but it's not my package. Perhaps someone from the net-im herd can make this decision? Well, as someone who spends a lot of time working on/with profiles, I say go for it. Since these changes would only affect the one package and wouldn't pull in any strange dependencies on people, we should probably do it as high in the profile structure as possible (base? default-linux?) so it hits the most users. I'd like to hear from net-im, as they're ultimately responsible, but I don't really see the harm in doing it, so we probably should as it will reduce headaches for our users. Talking with my net-im hat, I'd say go for it.. Except for silc and zephyr (which may or may not work very well) and should probably stay off. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ML changes
On Thu, 2007-12-07 at 13:24 -0700, Mike Doty wrote: We're going to change the -dev mailing list from completely open to where only devs can post, but any dev could moderate a non-dev post. devs who moderate in bad posts will be subject to moderation themselves. in addition the gentoo-project list will be created to take over what -dev frequently becomes. there is no requirement to be on this new list. What are the proposed guidelines for the different between -project and -dev? What goes where? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)
On Wed, 2007-04-07 at 22:11 +1000, Paul de Vrieze wrote:
On Sat, 30 Jun 2007 01:12:02 Olivier Crête wrote:
On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
Paul de Vrieze wrote:
There are various problems that need to be addressed for cross
development and (especially) multilib/abi. One of the other ones that
you didn't mention is some kind of subpackage support. For example when
one installs 32 bit gtk+ to use binary firefox on an 64bit system it
can share the headers and docs etc. with the 64 bit version. Removing
either of them must however still preserve those files.
A quick and dirty way implies that:
- only the main abi can install stuff /usr/
The secondary need to be able to install into their /usr/${libdir} ..
its actually the only place where stuff from the non-main abis should be
imho.
If one requires synchronized versions, there should in 99% of the cases not
be
any issue with header files and documentation. It will be equal, so can be
shared. It might indeed be an option to require the main abi to be always
present.
I really don't see how it can be made to work in a generic wait without
requiring that all sub-arches use the same version as the main arch and
without requiring that the main arch be installed (if we were a binary
distro, we could do a common package and a bunch of sub-packages, but
now we can't).
Paul
ps. for include headers it is rather straightforward to make forwarding
headers with architecture dependent redirects (using the architecture
defines) in case the headers are not arch independent.
In theory, headers in /usr/include should be arch independant. You if
you at glib, it installs its arch dependant header in /usr/lib
--
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)
On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
Paul de Vrieze wrote:
There are various problems that need to be addressed for cross development
and
(especially) multilib/abi. One of the other ones that you didn't mention is
some kind of subpackage support. For example when one installs 32 bit gtk+
to
use binary firefox on an 64bit system it can share the headers and docs
etc.
with the 64 bit version. Removing either of them must however still
preserve
those files.
A quick and dirty way implies that:
- only the main abi can install stuff /usr/
The secondary need to be able to install into their /usr/${libdir} ..
its actually the only place where stuff from the non-main abis should be
imho.
- includes live in their /usr/$arch/include/
- docs may live /usr/$arch/usr/share/doc/ or just be suppressed.
lu
--
Luca Barbato
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
Olivier Crête
[EMAIL PROTECTED]
Gentoo Developer
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-20-06 at 00:47 -0400, Mike Frysinger wrote: there are many files out there that contain critical information about your system ... however, there are certainly cases where the admin fully knows what they're doing and they want to create a binary package of their system with these sensitive files ... so where to meet in the middle. any other potential ideas ? (pretend my idea here isnt the greatest thing since Robot Chicken) I will claim that almost any file in /etc is potentially sensitive (even if it does not contain passwords, if may contain other informations interesting to a cracker). And even if we did what you propose, we'd run the risk of missing some and giving the user a false sense of security. Maybe we should document somewhere that the only way to make bin pkg that are safe for public distribution is to do emerge -b or -B .. And that pkgs built with quickpkg may contain sensitive information. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-20-06 at 21:35 +0100, Ciaran McCreesh wrote: On Wed, 20 Jun 2007 16:27:27 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: being able to generate binary packages that actually reflect the live $ROOT is desirable Is being able to generate redistributable binary packages that reflect the live ROOT desirable? Yes, it is, if you want to redistribute them to trusted parties (like other computers you own). -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
