Re: [gentoo-dev] making USE=upnp a global flag

2012-10-01 Thread Olivier Crête
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

2012-09-11 Thread Olivier Crête
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

2012-09-10 Thread Olivier Crête
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)

2012-08-13 Thread Olivier Crête
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

2012-08-09 Thread Olivier Crête
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

2012-08-09 Thread Olivier Crête
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

2012-08-09 Thread Olivier Crête
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

2012-08-07 Thread Olivier Crête
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()

2012-08-06 Thread Olivier Crête
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()

2012-08-06 Thread Olivier Crête
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

2012-07-18 Thread Olivier Crête
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

2012-07-17 Thread Olivier Crête
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

2012-07-17 Thread Olivier Crête
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

2012-07-17 Thread Olivier Crête
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

2012-07-17 Thread Olivier Crête
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

2012-07-17 Thread Olivier Crête
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

2012-07-13 Thread Olivier Crête
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

2012-05-15 Thread Olivier Crête
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

2012-05-14 Thread Olivier Crête
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]

2012-05-10 Thread Olivier Crête
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

2012-05-07 Thread Olivier Crête
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

2012-01-30 Thread Olivier Crête
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

2012-01-06 Thread Olivier Crête
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

2012-01-05 Thread Olivier Crête
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

2012-01-05 Thread Olivier Crête
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

2012-01-05 Thread Olivier Crête
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

2012-01-05 Thread Olivier Crête
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

2012-01-05 Thread Olivier Crête
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

2012-01-05 Thread Olivier Crête
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

2012-01-04 Thread Olivier Crête
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

2012-01-04 Thread Olivier Crête
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

2012-01-04 Thread Olivier Crête
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

2012-01-04 Thread Olivier Crête
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

2012-01-04 Thread Olivier Crête
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

2012-01-03 Thread Olivier Crête
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

2012-01-03 Thread Olivier Crête
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

2012-01-03 Thread Olivier Crête
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

2012-01-03 Thread Olivier Crête
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

2012-01-03 Thread Olivier Crête
On Tue, 2012-01-03 at 22:47 +, Sven Vermeulen wrote:
 On Sun, Jan 01, 2012 at 03:21:47PM -0500, Olivier Crête wrote:
   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).
 
 Yes... but no.
 
 Fedora uses SELinux but using a policy where most domains run unconfined
 (meaning they're allowed to do almost anything) and mostly the
 network-facing services are confined. 

 I just got dracut working on a SELinux system here (took me a few hours to
 compile a SELinux domain for dracut, because the application doesn't work
 with the standard privileges of an administrator) and it boots up (up to
 and including dracut: Switching root) until SELinux is activated. 
 
 From that point onwards, it's dead since its using wrong labels and wrong
 context.
 
 It is SELinux-aware (it mounts the selinuxfs and such) but I think I'll need
 to edit the /usr/lib/dracut/* stuff to get it to boot up properly on a
 SELinux system that doesn't use unconfined domains...
 
 I'll try to get it working the next few days. Once (or when) it does, I'll
 submit the necessary patches to wherever is necessary.

My understanding is that the dracut maintainer recently removed SELinux
support and moved it into systemd. So patches that go in the other
directions aren't likely to go very far. My understanding is also that
it is now systemd doing all the SELinux magic (relabelling, etc), if you
don't want to use systemd, you should at least look at the relevant code
[1] [2] in systemd and do that in your own init system. And if you have
any questions, just ask Lennart, he's actually surprisingly helpful.

[1] http://cgit.freedesktop.org/systemd/tree/src/selinux-setup.c
[2] http://cgit.freedesktop.org/systemd/tree/src/mount-setup.c#n386

-- 
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

2012-01-01 Thread Olivier Crête
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

2012-01-01 Thread Olivier Crête
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

2012-01-01 Thread Olivier Crête
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

2012-01-01 Thread Olivier Crête
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

2012-01-01 Thread Olivier Crête
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

2012-01-01 Thread Olivier Crête
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

2011-12-31 Thread Olivier Crête
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

2011-10-13 Thread Olivier Crête
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

2011-10-13 Thread Olivier Crête
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

2011-09-06 Thread Olivier Crête
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

2011-09-06 Thread Olivier Crête
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?

2011-06-29 Thread Olivier Crête
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?

2011-06-28 Thread Olivier Crête
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

2011-05-17 Thread Olivier Crête
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

2011-05-17 Thread Olivier Crête
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

2011-03-31 Thread Olivier Crête
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!

2011-03-30 Thread Olivier Crête
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

2011-03-24 Thread Olivier Crête
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

2011-03-07 Thread Olivier Crête
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

2010-08-23 Thread Olivier Crête
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

2010-08-23 Thread Olivier Crête
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

2010-07-04 Thread Olivier Crête
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

2010-06-27 Thread Olivier Crête
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

2010-06-27 Thread Olivier Crête
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

2010-06-25 Thread Olivier Crête
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

2010-06-24 Thread Olivier Crête
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

2010-06-21 Thread Olivier Crête
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

2010-06-20 Thread Olivier Crête
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

2009-09-19 Thread Olivier Crête
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

2009-04-08 Thread Olivier Crête
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

2009-03-24 Thread Olivier Crête
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

2009-03-11 Thread Olivier Crête
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?

2009-03-03 Thread Olivier Crête
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

2008-12-08 Thread Olivier Crête
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

2008-12-08 Thread Olivier Crête
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

2008-12-08 Thread Olivier Crête
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)

2008-10-31 Thread Olivier Crête
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

2008-10-28 Thread Olivier Crête
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

2008-09-06 Thread Olivier Crête
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

2008-08-18 Thread Olivier Crête

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?

2008-07-25 Thread Olivier Crête

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

2008-07-16 Thread Olivier Crête
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...

2008-06-19 Thread Olivier Crête

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

2008-02-20 Thread Olivier Crête

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

2007-12-08 Thread Olivier Crête
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

2007-11-20 Thread Olivier Crête
# 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

2007-10-29 Thread Olivier Crête
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

2007-10-05 Thread Olivier Crête
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

2007-10-05 Thread Olivier Crête
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

2007-09-27 Thread Olivier Crête
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

2007-09-10 Thread Olivier Crête
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?

2007-08-31 Thread Olivier Crête
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?

2007-08-15 Thread Olivier Crête
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?

2007-08-15 Thread Olivier Crête
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

2007-07-20 Thread Olivier Crête
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

2007-07-20 Thread Olivier Crête
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

2007-07-19 Thread Olivier Crête
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

2007-07-12 Thread Olivier Crête
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)

2007-07-04 Thread Olivier Crête
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)

2007-06-29 Thread Olivier Crête
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

2007-06-20 Thread Olivier Crête
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


  1   2   >