Re: [gentoo-dev] reproducible builds

[Canek Peláez Valdés]

On Feb 4, 2018 12:04, "Matt Turner"  wrote:

On Sun, Feb 4, 2018 at 7:25 AM, Samuel Bernardo
 wrote:
> Hi,
>
> I send this email to know the opinion of gentoo developers about
> registering gentoo profiles in the context of reproducible-builds.org

Reproducible builds makes sense when you're distributing binaries to
users. That's not typically the case with Gentoo.

What would this even mean in the context of a source-based distro?


It would mean that we all could reproduce the exact same bugs given the
CFLAGS/USE/etc. combination.

Many groups are working on this from different fronts; if the results
stabilize at some point, Gentoo could use that to at least give the users
the option of enabling reproducible builds.

Regards.

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Canek Peláez Valdés]

On Fri, May 27, 2016 at 10:02 AM, Brian Dolbec <dol...@gentoo.org> wrote:
[snip]
> I'll be really sad when gtk2 is totally abolished in Gentoo. :(
> I suppose I'll have to break down and switch to KDE maybe.
>
> In my opinion the upstream gtk developers have gone somewhat bonkers
> with their cartoonish changes to the look, feel and generally
> un-intuitive user interface.  The new file selector is irritating to use
> despite getting all the old behaviour settings I know of set, the lack
> of the ability to paste a path into it, forcing you to navigate
> directory by directory, and other BS behaviour...

What's wrong with Ctrl-L to open the "Enter location or URL" text
field and pasting the path there?

Regards.
-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-dev] usr merge

[Canek Peláez Valdés]

On Sat, Apr 9, 2016 at 2:49 PM, Philip Webb <purs...@ca.inter.net> wrote:
> 160409 Canek Peláez Valdés wrote:
>> You use LILO : that means, you don't use UEFI :
>> that means, almost certainly, you don't use recent hardware.
>
> I've always used Lilo, which is simple + reliable :
> I never see questions re it here, but there are many re Grub.
> I do use recent hardware, a cutting-edge machine I built  6 mth ago .
> When setting it up, I suppressed UEFI in the BIOS settings :
> isn't that what anyone not running M$ would do ?

I just disabled secure boot, although it's possible to use it with
Linux. However it would require to manually sign everything from boot
loader to kernel modules, since Gentoo has no infrastructure to do
that. Maybe a future project.

I don't "supress" UEFI, since it's *obviously* so much better than
BIOS, and since bootctl (the program formerly known as gummiboot) it's
incredible easy to use. You don't even notice it's there.

Also, I'm not sure, but I believe there are motherboards where you
don't have the option to "supress" UEFI, since they simply don't have
BIOS anymore. I could be wrong; but even if that's the case, I'm
pretty sure in the future BIOS will get relegated to a niche market,
if it doesn't completely disappear.

Seriously, UEFI is s much better.

Regards.
-- 
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

[gentoo-dev] Re: [gentoo-dev] Bug №504116, /etc/init.d/functions.sh

[Canek Peláez Valdés]

On Sat, Dec 20, 2014 at 5:35 AM, Сергей protsero...@gmail.com wrote:
 There is a bug (https://bugs.gentoo.org/show_bug.cgi?id=504116).
 Though it had been reported long time ago, many bugs, which this bug
 depends on, are not even confirmed (see my comment:
 https://bugs.gentoo.org/show_bug.cgi?id=504116#c3). There is also no
 response to my comment, seems like all the activity about this bug has
 stopped. Is it so?

It hasn't stopped, is just that the devs don't exactly know how to
continue. In particular, with glibc and all of the toolchain packages,
there is a lot of historical cruft in the ebuilds and associated
eclasses. The devs are discussing how to move on forward with this;
the issue of /etc/init.d/functions.sh is secondary or even tertiary to
this. Check [1] for an example thread of the kind of discussion
happening.

I've been using my own functions.sh file for years. At its core, is
basically a cosmetic issue; functions.sh never provided nothing more
than a few shell functions to print pretty messages on the console.

Regards.

[1] http://thread.gmane.org/gmane.linux.gentoo.devel/93994/
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-dev] systemd + postgresql is non-obvious to me

[Canek Peláez Valdés]

On Mon, Sep 1, 2014 at 10:46 AM, Aaron W. Swenson titanof...@gentoo.org wrote:
 On 2014-08-22 14:07, Rich Freeman wrote:
 On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson titanof...@gentoo.org 
 wrote:
  On the whole, I'm displeased with the systemd alternative for
  controlling PostgreSQL. It's significantly hampered and doesn't allow
  as much flexibility as the initscript. The major issue being trying to
  nicely shut down the server instead of jumping straight to murder.
 

 It looks like the package installs a service file provided by
 upstream, so you might want to direct your complaint there unless it
 really is a systemd limitation.

 Delayed response, I've been looking into this as I've been working on
 unifying the ebuilds, but I can't find where upstream is providing the
 systemd unit. The only one I have is the one we've made.

It is included in:

http://dev.gentoo.org/~titanofold/postgresql-initscript-2.6.tbz2

It doesn't says who the author is; but he or she was the one deciding
to wait five minutes (TimeoutSec=300) for the server to stop (and also
to disable the OOM killer: OOMScoreAdjust=-1000).

Regards.
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

Re: [gentoo-dev] systemd + postgresql is non-obvious to me

[Canek Peláez Valdés]

On Fri, Aug 22, 2014 at 1:07 PM, Rich Freeman ri...@gentoo.org wrote:
 On Fri, Aug 22, 2014 at 1:23 PM, Aaron W. Swenson titanof...@gentoo.org 
 wrote:
 On the whole, I'm displeased with the systemd alternative for
 controlling PostgreSQL. It's significantly hampered and doesn't allow
 as much flexibility as the initscript. The major issue being trying to
 nicely shut down the server instead of jumping straight to murder.


 It looks like the package installs a service file provided by
 upstream, so you might want to direct your complaint there unless it
 really is a systemd limitation.

 Checking the latest version in portage it calls:
 ExecStop=/usr/@LIBDIR@/postgresql-@SLOT@/bin/pg_ctl stop -D
 ${DATA_DIR} -s -m fast

 I'm no postresql expert, but according to the manpage that should
 bring the server to a screeching, but still controlled, halt.  Perhaps
 you would prefer setting it to -m smart instead of -m fast.

 If so override it in /etc/systemd/system.  I generally recommend using
 drop-ins for this, but I'm not sure if doing a drop-in for ExecStop
 will override the existing value, or simply cause systemd to run both
 commands (which means that whichever runs first will control how it
 stops).

It's the same as with ExecStart=; it gets added to a list, and all of
them are executed in the same order as they appear in the unit file.
In a drop-in, you can reset the list like this:

ExecStop=
ExecStop=new_and_only_command_to_be_executed

 Systemd shouldn't begin killing processes without mercy until the
 process invoked in ExecStop terminates, so it should not terminate
 until the process has finished graceful shutdown.

If ExecStop= wasn't specified, systemd would immediaely kill all the
service processes; from [1]: If this option [ExecStop] is not
specified, the process is terminated immediately when service stop is
requested, which kinda sounds like jumping straight to murder.

That the upstream unit file is configured otherwise, shows that
PostgreSQL upstream itself thinks that's a bad idea. No fault on
systemd's part.

Regards.

[1] http://www.freedesktop.org/software/systemd/man/systemd.service.html
-- 
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

[gentoo-dev] Thank you

[Canek Peláez Valdés]

Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs, so
you can go on your daily business if you don't want to read the rest
of it. No biggie.

I just want to say THANK YOU to all of our Gentoo developers. I've
been using Gentoo since ca. 2002 (damn, that's more than a decade),
and I've seen a lot of flamewars and bikeshedding on the -dev mailing
list.

However, you guys get the job done, and although there are some things
that I would like to have sooner (or would have liked to have
earlier), in the end the people working keep pushing the necessary
changes so the distribution keeps going, and (if so desired) using new
and interesting technologies.

More importantly, the developers and the bureaucratic structures they
have created don't get (too much) in the way of individual or small
groups of developers pushing for progress. In general at least; there
will be always someone resisting change, but in general Gentoo keeps
advancing, and the council and the other bureaucratic structures don't
punish people for just wanting to have more new and cool features in
the distribution.

I've never said Thank You to all our developers in all these years
using Gentoo, but after seeing the discussion the Debian CTTE is
having related to the default init they should use[1][2][3] (including
bureaucratic maneuvers, dilatory tactics, legalese interpretation of
their rulings, etc.), I think the time is long overdue for me to do
it.

Thank you for all the work you guys do and have done.
Thank you for not penalize progress.
Thank you for not being so rigid.
Thank you for keeping the distribution moving and evolving.
And finally, just thank you.

From a proud Gentoo+systemd+GNOME 3 user, thank you.

Regards.

[1] https://lists.debian.org/debian-ctte/2014/01/threads.html
[2] https://lists.debian.org/debian-ctte/2014/02/threads.html
[3] http://lwn.net/Articles/584227/#Comments
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Canek Peláez Valdés]

On Sun, Aug 11, 2013 at 2:31 AM, Pacho Ramos pa...@gentoo.org wrote:
 El dom, 11-08-2013 a las 08:41 +0300, Samuli Suominen escribió:
 On 09/08/13 12:51, Pacho Ramos wrote:
  El vie, 09-08-2013 a las 11:26 +0200, Chí-Thanh Christopher Nguyễn
  escribió:
  Pacho Ramos schrieb:
  If OpenBSD can do it, then Gentoo can do it, too. So would you accept 
  ebuild
  patches that make it possible to install Gnome 3.8 without systemd 
  again?
  Only make it possible, not turn it into a configuration which the Gnome 
  team
  supports.
 
  We have discussed this some times in the team, the problem is that we
  don't think we should provide by default a setup that is not working
  properly: powermanagement, multiseat support and gdm service handling
 
  I don't say that it should be the default.
 
  Also, if that people reports problems, we would
  close them as WONTFIX - migrate to systemd
 
  That's what I meant when I wrote not a configuration that Gnome team 
  supports.
 
  - You can ignore the warnings, news and suggestions and, even moving
  from udev to systemd ebuild, keep booting with openRC and using systemd
  as device manager
  - You can put systemd in package.provides to even keep running udev
 
  The good part about package.provided is that users definitely know that 
  they
  are running an unsupported configuration with it. The bad part is that
  putting systemd in package.provided is a bit dangerous, as this can lead 
  to
  udev unmerge on depclean if you are not careful.
 
 
  This makes me think what is the problem with people moving to systemd as
  udev provider (even running openrc) :/

 Because sys-apps/systemd is installed in wrong directory structure in /usr
 I still carry systemd in my local overlay instead of using it from
 Portage, just to put it in / as per upstream recommendation :-/
 We have tried to reach consensus, but there is a disagreement that we
 have left at We agree that we don't agree.

 Pushing that aside, there is also the heavy dependencies of
 sys-apps/systemd in comparison to sys-fs/udev


 Maybe the second point could be solved having some kind of minimal USE
 flag for systemd building it with only the minimum set for running udev
 without adding so many dependencies. Regarding the first issue, I have
 also seen that will be nearly impossible to reach a consensus because we
 are currently in a strange intermediate situation: we don't have a setup
 ready to run without /usr but neither /usr merge work :|

 Then, I guess will have to live with this two alternatives more time :/,
 but people running Gnome will need to keep /usr mounted and, then, they
 won't suffer the first problem of place installation.

systemd doesn't support separated /usr without an initramfs, so there
is no problem now that GNOME requires it.

  Also, the extra
 dependencies won't be so extra for gnome users, letting them to move
 to systemd ebuild easily

And there is that. Although the only hard (runtime) dependencies of
systemd-206-r3 are:

sys-apps/dbus
sys-apps/util-linux
sys-libs/libcap
sys-apps/baselayout
sys-apps/hwids

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Canek Peláez Valdés]

On Sat, Aug 10, 2013 at 6:10 PM, Mike Auty ike...@gentoo.org wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 10/08/13 23:42, Wulf C. Krueger wrote:
 On 09.08.2013 02:26, Mike Auty wrote:
 I could be a KDE developer, or a Gentoo documenter, or work on
 mplayer.  All those people are open source contributors and
 necessary ones, but that doesn't mean that any of them
 necessarily has the skills or the time to look after udev.  Does
 that invalidate their opinion on the choices of upstream project
 they rely on?

 Yes, it does.

 In that situation then, developers are only developing for themselves?
  What's more likely is that they've taken a gamble that most users
 will simply accept their changes, which they deem as necessary to move
 forward.

 That would be fine if there were alternative options, but as more and
 more things are vertically integrated the choices made by one
 project are knocking over into others.  Before I could simply ignore
 systemd and choose something else, now I'm having to choose between
 using both Gnome and systemd, or neither.

 It is a difficult choice, but just as Gnome has chosen to forsake my
 desire for a simplistic init system at the expense of a little boot
 speed and some features I've never needed in the past, I'm having to
 walk away to some other less well developed desktop environment.  The
 cost of ignoring their users opinions is losing the users themselves.
  I don't know how many users they'll have to lose before someone
 decides to take the ship in a new direction, but I would like to see
 how many they stand to lose, by asking those who care to speak up and
 find a way of being heard before the damage is too much to repair...

We have been having this discussion since GNOME 3.0 came out, and some
would argue that since GNOME 2.0, or even before.

The GNOME project will go where the developers of the GNOME project
decide to, period. There is MATE if you really want the old GNOME 2,
Cinnamon if you only want something similar to the old interface, or
KDE/Xfce/E17 if you want to switch. Arguing with the GNOME developers
like they don't know what they are doing is pointless at best, and
frankly insulting at worst.

They thought deeply about the changes that are being made to the
desktop, and they discussed it and reached a consensus about what the
direction of the project is; you can usually read about in the mailing
lists, Planet GNOME, or even watch the videos from the GUADEC
presentations. You can of course disagree with that direction: but
acting like they, poor things, don't know what they are doing and need
that someone go an tell them so they can know before the damage is
much to repair, is quite condescending.

People have been predicting the dead of GNOME since before the 1.0
version came out, but right now it has more contributors than ever in
the past, and at least half a dozen companies actually pay money to
people to work in it, so perhaps they actually know what they are
doing. But even if they don't, there are a couple forks you can try or
several alternatives you can switch to if the damage is too much to
repair.

And at the end of the day, all that code is 100% Free Software, with
public repositories with all the history of the components of the
project for all the world to see and use.

The GNOME developers already made their decision. The GNOME
maintainers in Gentoo followed through (like they have been doing in
almost every other distro). Now it's up to each user to decide if she
keeps using GNOME (and therefore switches, if necessary, to systemd
since 3.8), or if she stops using it.

Arguing about it is quite useless.

Regards from a  (very happy, very proudly) GNOME+systemd Gentoo user.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Canek Peláez Valdés]

On Fri, Aug 9, 2013 at 7:14 AM, viv...@gmail.com viv...@gmail.com wrote:
 On 08/09/13 13:38, Pacho Ramos wrote:
 El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
 On 08/09/2013 07:26 PM, Tom Wijsman wrote:
 On Fri, 09 Aug 2013 19:31:22 +0800
 Patrick Lauer patr...@gentoo.org wrote:

 You just removed the upgrade path for users.
 The upgrade path is to install systemd or to implement openrc support.

 Invalid upgrade path.

 The upgrade path is to install Fedora is about as reasonable, and also
 not acceptable.


 The upgrade path is to run systemd, not migrate to fedora. As simply as
 such


 is systemd useful if not run with PID=1 ? Honest question

(Answering as a GNOME+systemd user since 2011).

AFAIU, systemd is completely useless if it isn't running as PID 1. In
particular (and the reason systemd is now a hard requirement for
GNOME), logind will not work correctly (if at all) if systemd isn't
PID 1. All the cgroups handling (for one) is non existent (or
completely different) in OpenRC.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Canek Peláez Valdés]

On Fri, Aug 9, 2013 at 8:54 AM, Michał Górny mgo...@gentoo.org wrote:
 Dnia 2013-08-09, o godz. 14:14:12
 viv...@gmail.com viv...@gmail.com napisał(a):

 On 08/09/13 13:38, Pacho Ramos wrote:
  El vie, 09-08-2013 a las 19:39 +0800, Patrick Lauer escribió:
  On 08/09/2013 07:26 PM, Tom Wijsman wrote:
  On Fri, 09 Aug 2013 19:31:22 +0800
  Patrick Lauer patr...@gentoo.org wrote:
 
  You just removed the upgrade path for users.
  The upgrade path is to install systemd or to implement openrc support.
 
  Invalid upgrade path.
 
  The upgrade path is to install Fedora is about as reasonable, and also
  not acceptable.
 
 
  The upgrade path is to run systemd, not migrate to fedora. As simply as
  such
 
 
 is systemd useful if not run with PID=1 ? Honest question

 Not a honest question but either honest troll, or you're awfully lazy
 and just making noise here.

 So the answer is: yes, it's quite useful when run with PID!=1. It's
 called systemd user instance (something OpenRC totally can't handle)
 and it can be used to manage user services.

I forgot thtat when I answered, but that requires that systemd is also
running as PID 1. If I understand the question correctly (and I didn't
perceived any trollism), it was about if you can install systemd,
but run OpenRC as PID 1, and have everything working.

In that case, the answer is no.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Canek Peláez Valdés]

On Fri, Aug 9, 2013 at 9:50 AM, Alon Bar-Lev alo...@gentoo.org wrote:
 On Fri, Aug 9, 2013 at 5:44 PM, Chí-Thanh Christopher Nguyễn
 chith...@gentoo.org wrote:
 Alon Bar-Lev schrieb:
 On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman ri...@gentoo.org wrote:
 On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer patr...@gentoo.org wrote:
 You just removed the upgrade path for users.

 Just install systemd.  There really isn't any practical alternative.
 Gentoo with systemd is as Gentooish a configuration as Gentoo with
 OpenRC, or Gentoo with libav, or Gentoo with emacs.
 Again, I repeat my-self.

 Please stop writing these statements!

 There was no decision to support Gentoo using any other layout than
 openrc (baselayout).

 I think there may be a misunderstanding here. He only said that if you
 want to run Gnome 3.8, then switch to systemd. Because the Gnome team
 will not support any other configuration.

 He did not say that everyone should install systemd, nor that you need
 to support such a configuration.

 So users will have gnome working but not any other component? How can
 this a good service for  users?

For the record, everything I use (desktop, laptop, media center,
servers, etc.) uses Gentoo with systemd. Several of them doesn't have
GNOME (the servers obviously don't even have X). All the components
in my use cases (which I confess are really standard) work.

In my experience, if it works in Gentoo with OpenRC, it will work with
systemd (and, IMHO, sometimes better).

The other way around is, obviously as per this whole thread, not true.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: Re: Re: [gentoo-dev] Re: Making systemd more accessible to normal users

[Canek Peláez Valdés]

On Wed, May 22, 2013 at 9:39 PM, Daniel Campbell dlcampb...@gmx.com wrote:
 On 05/20/2013 10:34 PM, Canek Peláez Valdés wrote:
 On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell dlcampb...@gmx.com wrote:
 On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote:
 On Sun, May 19, 2013 at 9:34 AM, Peter Stuge pe...@stuge.se wrote:
 J. Roeleveld wrote:
 I don't see how this will avoid the issue of a limited amount of
 inodes.
 That is what I usually run out of before the disk is full when
 storing lots of smaller files.

 I guess the number of unit files is on the order of hundreds

 (Sorry, sent email before it was ready).

 Laptop running full GNOME:

 # find /usr/lib/systemd/system -type f | wc
 154 1547012

 Server running Apache+MySQL+Mailman+Squid+Other services:

 # find /usr/lib/systemd/system -type f | wc
 121 1215560

 And as you said, you can always use INSTALL_MASK. If 154 files are
 going to deplete your inodes, I think your problem lies somewhere
 else.

 Regards.
 --
 Canek Peláez Valdés
 Posgrado en Ciencia e Ingeniería de la Computación
 Universidad Nacional Autónoma de México


 That's missing the point. If you don't run systemd, having unit files is
 pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
 like a hack instead of something more robust. Why include systemd unit
 files (by default, with no systemd USE flag, thanks to the council...)
 on a system that's not using it? 154 files isn't negligible unless
 you're flippant with your system and don't care about bloat. Unused
 software sitting around *is* a waste of disk-space.

 Unit files are not software; they are data.

 And I believe you are the one missing the point. I don't run OpenRC; I
 don't need no files in /etc/init.d. But you don't see me (nor any
 other systemd user) complaining about pointless scripts in
 /etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with my
 life.

 Non-systemd users should do the same for files under /usr/lib/systemd,
 if they really are that worried about systemd infecting their
 systems. Complaining about a council-decided policy (and, I believe,
 backed up by the developers that matter, including the OpenRC
 maintainers) is just beating on a dead horse.

 Get over it.

 Some people (like myself) came to Gentoo to avoid putting systemd on
 their systems and to make use of the great choice that Gentoo allows.
 This push to make systemd a first level citizen or whatever reeks of
 marketing.

 If Gentoo is about choice, then systemd is one of those choices. And
 systemd will become a first class citizen inside Gentoo, like it or
 not. Support for it has been getting better and better, and more and
 more Gentoo users are running with systemd.

 If  some fundamentalists users don't want even one file in their
 systems with systemd on their paths, they can install eudev/mdev,
 put the necessary directories in INSTALL_MASK, and do the extra work.
 If some other fundamentalists users (like myself) don't want even one
 OpenRC related file on our systems, we can create an overlay to remove
 the dependency of baselayout on OpenRC, put /etc/init.d in
 INSTALL_MASK, and do the extra work.

 Neither case covers the average systemd/OpenRC user, who doesn't care
 about a few scattered files in /etc/init.d nor /usr/lib/systemd, and
 just want to run her machine with the init system of her choice. If
 Gentoo is really about choice.

 If there is desire among users for unit files, they can
 contact upstream or maintain their own set of unit files. It's not like
 they're hard to write.

 So, Gentoo is about choice, but only for the choices you agree with. Great.

 Regards.
 --
 Canek Peláez Valdés
 Posgrado en Ciencia e Ingeniería de la Computación
 Universidad Nacional Autónoma de México


 It seems that I've stepped on a few toes in calling INSTALL_MASK a hack.
 Hacks aren't necessarily bad; if anything it shows that there's interest
 in supporting something but perhaps not enough time or manpower to
 implement a more robust solution. If adding one or two directories to
 that variable will nuke any unit files, consider me happy.

As I was, when I used to put /etc/init.d in INSTALL_MASK.

 systemd is certainly a choice, but it is no more deserving of
 consideration than any other init system. I don't see anyone calling for
 runit to be a 'first level citizen'. I wonder why that is.

Probably because is used by a really small number of users, contrary to systemd

 Again, if
 INSTALL_MASKing openrc dirs will get rid of init scripts for systemd
 users, then perhaps INSTALL_MASK is the best we have for now and should
 make use of it. I never said that it wasn't suitable to use.

Then we agree.

 As for complaining about policy, what is the proper thing to do in a
 situation where someone questions the reasoning behind a decision?

Contribute?

 Are
 there links somewhere on Gentoo's website that outline the process for
 each important decision that the council's made

Re: Re: [gentoo-dev] Re: Making systemd more accessible to normal users

[Canek Peláez Valdés]

On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell dlcampb...@gmx.com wrote:
 On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote:
 On Sun, May 19, 2013 at 9:34 AM, Peter Stuge pe...@stuge.se wrote:
 J. Roeleveld wrote:
 I don't see how this will avoid the issue of a limited amount of
 inodes.
 That is what I usually run out of before the disk is full when
 storing lots of smaller files.

 I guess the number of unit files is on the order of hundreds

 (Sorry, sent email before it was ready).

 Laptop running full GNOME:

 # find /usr/lib/systemd/system -type f | wc
 154 1547012

 Server running Apache+MySQL+Mailman+Squid+Other services:

 # find /usr/lib/systemd/system -type f | wc
 121 1215560

 And as you said, you can always use INSTALL_MASK. If 154 files are
 going to deplete your inodes, I think your problem lies somewhere
 else.

 Regards.
 --
 Canek Peláez Valdés
 Posgrado en Ciencia e Ingeniería de la Computación
 Universidad Nacional Autónoma de México


 That's missing the point. If you don't run systemd, having unit files is
 pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems
 like a hack instead of something more robust. Why include systemd unit
 files (by default, with no systemd USE flag, thanks to the council...)
 on a system that's not using it? 154 files isn't negligible unless
 you're flippant with your system and don't care about bloat. Unused
 software sitting around *is* a waste of disk-space.

Unit files are not software; they are data.

And I believe you are the one missing the point. I don't run OpenRC; I
don't need no files in /etc/init.d. But you don't see me (nor any
other systemd user) complaining about pointless scripts in
/etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with my
life.

Non-systemd users should do the same for files under /usr/lib/systemd,
if they really are that worried about systemd infecting their
systems. Complaining about a council-decided policy (and, I believe,
backed up by the developers that matter, including the OpenRC
maintainers) is just beating on a dead horse.

Get over it.

 Some people (like myself) came to Gentoo to avoid putting systemd on
 their systems and to make use of the great choice that Gentoo allows.
 This push to make systemd a first level citizen or whatever reeks of
 marketing.

If Gentoo is about choice, then systemd is one of those choices. And
systemd will become a first class citizen inside Gentoo, like it or
not. Support for it has been getting better and better, and more and
more Gentoo users are running with systemd.

If  some fundamentalists users don't want even one file in their
systems with systemd on their paths, they can install eudev/mdev,
put the necessary directories in INSTALL_MASK, and do the extra work.
If some other fundamentalists users (like myself) don't want even one
OpenRC related file on our systems, we can create an overlay to remove
the dependency of baselayout on OpenRC, put /etc/init.d in
INSTALL_MASK, and do the extra work.

Neither case covers the average systemd/OpenRC user, who doesn't care
about a few scattered files in /etc/init.d nor /usr/lib/systemd, and
just want to run her machine with the init system of her choice. If
Gentoo is really about choice.

 If there is desire among users for unit files, they can
 contact upstream or maintain their own set of unit files. It's not like
 they're hard to write.

So, Gentoo is about choice, but only for the choices you agree with. Great.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: Making systemd more accessible to normal users

[Canek Peláez Valdés]

On Sun, May 19, 2013 at 9:34 AM, Peter Stuge pe...@stuge.se wrote:
 J. Roeleveld wrote:
 I don't see how this will avoid the issue of a limited amount of
 inodes.
 That is what I usually run out of before the disk is full when
 storing lots of smaller files.

 I guess the number of unit files is on the order of hundreds,

Full GNOME


 as long
 as you haven't configured an INSTALL_MASK to avoid installing them.
 (Why haven't you?)

 Are you saying that a few hundred inodes more will break many systems?

 It doesn't seem very likely to me.


 //Peter




--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: Making systemd more accessible to normal users

[Canek Peláez Valdés]

On Sun, May 19, 2013 at 9:34 AM, Peter Stuge pe...@stuge.se wrote:
 J. Roeleveld wrote:
 I don't see how this will avoid the issue of a limited amount of
 inodes.
 That is what I usually run out of before the disk is full when
 storing lots of smaller files.

 I guess the number of unit files is on the order of hundreds

(Sorry, sent email before it was ready).

Laptop running full GNOME:

# find /usr/lib/systemd/system -type f | wc
154 1547012

Server running Apache+MySQL+Mailman+Squid+Other services:

# find /usr/lib/systemd/system -type f | wc
121 1215560

And as you said, you can always use INSTALL_MASK. If 154 files are
going to deplete your inodes, I think your problem lies somewhere
else.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Making systemd more accessible to normal users

[Canek Peláez Valdés]

On Wed, May 8, 2013 at 9:18 PM, Walter Dnes waltd...@waltdnes.org wrote:
 On Wed, May 08, 2013 at 10:31:21PM +0530, Arun Raghavan wrote

 The overhead of the files' presence is trivial, and most users won't
 care. Those who do care have a trivial line to add in make.conf, and
 that is for the small number of people who share your vitriol for the
 systemd project.

   Then howsabout a units ebuild that installs all available units
 files for systemd users?  The overhead of the files' presence is
 trivial, and most systemd users won't care.

   The thread title says it all... normal Gentoo users don't use systemd.

For now.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Canek Peláez Valdés]

On Sun, Nov 18, 2012 at 1:25 AM, Matt Turner matts...@gentoo.org wrote:
 On Sat, Nov 17, 2012 at 11:05 PM, Walter Dnes waltd...@waltdnes.org wrote:
 As I posted elsewhere, working on a project based on hate only lasts
 so long.  I should know, that's the reason I started udev in the first
 place over 9 years ago.

   The Xfree86 people generated a lot of hate, just like Sievers and
 Poettering.  Xorg hasn't burned out yet.

 Let's be fair. The Xorg fork was done by a lot of really competent
 professional developers who had been developing XFree86 for a long
 time.

And it was made because it had become almost impossible to work with
the main developer of XFree86; not because of hate, but by very clear
and valid technical reasons The systemd+udev project instead has code
contributed by every major Linux distribution, and many small ones.
Even Ubuntu hasn't talked about forking udev, and they keep sending
patches, even with their staunch commitment to Upstart. This is what a
developer from Arch Linux (which has just made the decision to move to
systemd) has to say about it:

... systemd is a cross-distro project: every major and many, many
minor distros have had people contributing to systemd. last i heard
even two debian devs have commit access to the repo, among many
others. systemd upstream is very accommodating of different needs and
different use-cases (as long as they are presented on technical
grounds) and have been a pleasure to work with so far. We are getting
the joint experience of a lot of people/projects who have worked on
different init systems for a long time, I think this is one of the
most important features one could have.

https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530

Seeing some people comparing udev to XFree86 is one of the more
bizarre things coming out from this fork, and that's saying. However,
I agree with Doug that anyone should code whatever they want to code.
Who knows, maybe something interesting would come off from this fork,
and it certainly doesn't affect us happy Gentoo+systemd+udev users.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Tue, Aug 14, 2012 at 5:31 AM, Rich Freeman ri...@gentoo.org wrote:
 On Mon, Aug 13, 2012 at 11:24 PM, Greg KH gre...@gentoo.org wrote:
 On Thu, Aug 09, 2012 at 03:47:19PM -0400, Rich Freeman wrote:
 On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés can...@gmail.com 
 wrote:
 
  I agree with Greg Kroah-Hartman: I actually like (and want) a
  vertically integrated, tightly coupled way of doing things.

 Well, if you completely agreed with him you wouldn't be running Gentoo
 (or Debian, or other general-purpose distros).  He advocates that
 ordinary users should use more purpose-driven distros, where all of
 this stuff is less of an issue.

 That is not what I said, or mean at all.

 Given that I'm a Gentoo developer, and have been for a very long time, I
 find it very strange that you would think otherwise.

 I did clarify my post in a reply, linking to your post and of course
 stating that you could clarify.  Your words were:   I just don't
 think it can be done well, sorry, which is why I strongly recommend
 tightly-coupled distros for desktops for anyone (like Fedora or
 openSUSE or Ubuntu), and Debian or Gentoo only for servers or embedded
 systems where you know exactly what you are putting together, and why
 you are doing it that way.

 I'm not a big fan of putting words in mouths, so if I misread that
 than I apologize.  In any case, I can't really argue much with that
 statement as-is, although I'd probably carve out an additional
 exception for enthusiasts or those who otherwise like to tinker under
 the hood.

 If you want strong vertical integration, you probably will never get
 as much of it with Gentoo as you might get with a tightly-coupled
 distro.

You can get as much vertical integration with Gentoo as with any other
distro. The problem (and I think this is the point Greg is trying to
make) is that it will be harder (not impossible, just harder) if most
of Gentoo developers really believe that every single possible
combination of hardware, software, init systems, and even OS kernels
should be supported.

I myself believe that any Gentoo dev should support whatever the hell
s/he wants to; I'm just interested in that if some of us want vertical
integration, it should be easier to get. Right now every single Gentoo
install from the official tree has OpenRC installed, because is pulled
in by baselayout, and OpenRC also pulls sysvinit. And I'm not talking
about some text files (even if they are executables) in /etc/init.d;
I'm talking about executable binaries and libraries in every Gentoo
install, even if the user has systemd, and they don't use
OpenRC/sysvinit at all. Not to mention that they need to compile both
packages if they ever upgrade (which doesn't happen that much, I
agree).

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Thu, Aug 9, 2012 at 3:42 AM, Luca Barbato lu_z...@gentoo.org wrote:
[snip]
 Repeat after me: having your first process require anything more than
 libc is stupid and dangerous.

No, it's not. You can (and should) depend on whatever libraries helps
to achieve the desired goals. If one of the libraries has a bug, guess
what? It should be fixed. And then you repeat until all the used
libraries are as stable as libc (or more, if possible), and then the
statement that having your first process require anything more than
libc is stupid and dangerous makes no sense at all.

(As a side note, I would like to see the bugrate of libpthread,
libudev, libpam, libaudit, libcap, libdbus, etc. I'm pretty sure the
latest versions are pretty much rock solid).

That's in part what I like the approach taken by systemd (and
PulseAudio, by the way); it wants to be a proper solution, and if in
using something else they detect a bug, they push to get the bug fixed
in the external library (or the kernel sometimes). They don't
workaround real problems. It's the only way to guarantee that the
*whole* stack (not only libc, or the kernel) actually works as it
should.

So yes, PID 1 should use whatever libraries it makes sense to use, and
if there are bugs in them *they should get fixed*. Otherwise lets
program everything in assembler, because maybe gcc has a bug
somewhere.

 Once that concept gets accepted then we could discuss about why
 reinventing shellscript may not be that sound and other less glaring,
 horrid and appalling design choices.

The didn't reinvent shellscript; they replaced it with unit files.
That's the best design choice about systemd, IMHO: the unit files say
*what* a service should do, not *how*. And besides, you can still use
shellscript if your daemon is so fucked up that a regular unit file
doesn't cover your case. You should fix your daemon, really; but the
option to use shellscript is still there.

 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.

Really? I'm subscribed to the systemd ML, and the author accept all
kind of contributions. If they don't agree with one in particular they
explain why and the discuss a compromise if necessary. Doing the
following in my git clone of the project:

git log --format='%aN' | sort -u | wc

shows a total of 337 contributors to systemd. So I really believe that
you are talking nonsense in this particular point.

 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. I maintain a really small overlay to use systemd exclusively in
Gentoo, so I don't need to install OpenRC and sysvinit:

https://github.com/canek-pelaez/gentoo-systemd-only/
http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Thu, Aug 9, 2012 at 1:31 PM, William Hubbs willi...@gentoo.org 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.

By the same reasoning, Linus is even a bigger asshole. In the kernel
they flatly refuse to merge code from a LOT of people; that's their
job in the end.

I read the thread where you proposed the changes to systemd's build
system. I wish it was accepted, but I also understand why they didn't.
As I said in other threads, they really don't care for source based
distros; and that sucks for Gentoo (and every other source based
distro), but it's their call. And it certainly helps them to keep the
build system simple, assuming that it would be used only by packagers
for binary distros.

That doesn't say anything about the design of systemd, which is why I
use it; not because of the build system.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Thu, Aug 9, 2012 at 1:57 PM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
 On Thu, 9 Aug 2012 13:53:34 -0500
 Canek Peláez Valdés can...@gmail.com wrote:
 That doesn't say anything about the design of systemd, which is why I
 use it; not because of the build system.

 Actually, it's fairly representative of the design of systemd too: it
 forces you into a particular monolithic, vertically integrated, tightly
 coupled way of doing things, and if you try to deviate from that way,
 then you're stuffed.

I agree with Greg Kroah-Hartman: I actually like (and want) a
vertically integrated, tightly coupled way of doing things. And of
course people who *don't* want that don't have to use it; just don't
expect support from the people writing the code for a vertically
integrated, tightly coupled OS, and don't complain when they reject
your contributions when they go against their goals.

Or in other words, if you don't want a vertically integrated, tightly
coupled system, then use mdev, or Luca's fork of udev; if enough
people really want that, they will thrive.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Questions about SystemD and OpenRC

[Canek Peláez Valdés]

On Thu, Aug 9, 2012 at 6:00 PM, Walter Dnes waltd...@waltdnes.org 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.

I agree. Systemd is not mandatory; dbus is not mandatory, and thanks
to your efforts udev is not mandatory, right? I don't know about PAM,
but I'm not opposed for it to not being mandatory. So lets stop making
OpenRC mandatory, and besides in a completely artificial way: nothing
really depends on functionalitty provided by OpenRC.

So let people make their OpenRC+mdev systems without systemd, and let
people make their systemd+udev systems without OpenRC. Everybody wins.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] RFC: virtual/libudev

[Canek Peláez Valdés]

On Thu, Jul 26, 2012 at 4:44 PM, Peter Alfredsen
peter.alfred...@gmail.com wrote:
 On Wed, Jul 11, 2012 at 11:04 PM, Michał Górny mgo...@gentoo.org wrote:
 On Wed, 11 Jul 2012 15:27:41 -0400
 Mike Gilbert flop...@gentoo.org wrote:

 Personally, I think a consolidated systemd/udev package is the best
 way to go here.

 A consolidated package means that:

 - every change made by udev developers would have to be reviewed by
   systemd team to make sure it doesn't break systemd. udev developers
   don't use systemd;
 - every change made by systemd developers would have to be reviewed by
   udev team to make sure it doesn't break openrc. systemd developers
   usually don't run openrc;
 - udev developers will force me to use eclasses they like and force
   their coding style on me;
 - i will force eclasses I like and my coding style on udev developers;
 - new udev wouldn't be able to be stabilized without systemd being
   stabilized at the same time (and I don't really think systemd is in
   any condition to go stable),
 - there will be a few random flags which will either work or not,
   depending on a state of magical switch flag,
 - and after all, the ebuild will be basically one big use-conditional.

 So, since this is blocking up development and people actually solving
 things, could we just have virtual/udev and be done with it? Upstream
 obviously reneged on their promise to make the component parts
 buildable separately, so the virtual seems like the only sane choice
 right now.

Just to clarify, udev/systemd never promised to make the component
parts buildable separately. They promised:

we will be supporting this for a long time since it is a necessity to
make initrds (which lack systemd) work properly. Distributions not
wishing to adopt systemd can build udev pretty much the same way as
before, however should then use the systemd tarball instead of the
udev tarball and package only what is necessary of the resulting
build.

Where package only what is necessary being the important part for Gentoo.

http://lwn.net/Articles/490413/

Certainly they don't care about source-based distributions like
Gentoo, but they never promised to make the component parts buildable
separately.

Anyway, I also support the virtual/udev, since it's the only way for
us systemd users to not build udev twice.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: RFC: virtual/libudev

[Canek Peláez Valdés]

On Thu, Jul 26, 2012 at 9:37 PM, Duncan 1i5t5.dun...@cox.net wrote:
[ snip ]
 9) Otherwise, at very minimum, they're failing the build udev pretty
 much the same as before

./configure
make
make install

You fail to see the matter from their POV. They don't care (that much)
about building, because the distributions they care about use binary
prebuilt packages. In that sense, build udev pretty much the same as
before is the holly trinity of ./configure; make; make install.
Otherwise the part about package only what is necessary has not that
much sense.

Which again leads to the please, add a virtual/udev so the people
using systemd don't need to built udev twice.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Opinion against /usr merge

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 8:18 AM, Richard Yao r...@gentoo.org wrote:
 On 07/18/2012 04:10 AM, Michał Górny wrote:
 On Tue, 17 Jul 2012 23:54:16 -0400
 Richard Yao r...@gentoo.org wrote:

[snip]

 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.

 Now put that definition into my cold logic brain.

 That was meant as a joke, although the irony is that it is true.

So, you are rationalizing a posteriori an original irrational decision.

Understanding the bin, sbin, usr/bin , usr/sbin split:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html

The /bin vs /usr/bin split (and all the others) is an artifact of
this, a 1970's implementation detail that got carried forward for
decades by bureaucrats who never question _why_ they're doing things.
It stopped making any sense before Linux was ever invented, for
multiple reasons

I don't mind the merge of /bin, /usr/bin, /sbin and /usr/sbin;
moreover, I want an even more radical change:

/usr - /System
/home - /Users
/etc - /Config

Why should we care about ancient filesystems that didn't supported
long paths, and therefore we got stuck with /usr since we didn't
wanted to waste another *single* character to make it /user?

Let that silly legacy stuff die. Keep symbolic links to the old
directories for compatibility reasons, if you want to (modern software
should not need it anyhow), and move on. Remember /usr/X11R6? We kept
a /usr/X11R6 - /usr link for years. Do you miss it?

I surely not. Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Opinion against /usr merge

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 11:13 AM, Hobbit little_hob...@lavabit.com wrote:
 Why should we care about ancient filesystems that didn't supported
 long paths, and therefore we got stuck with /usr since we didn't
 wanted to waste another *single* character to make it /user?

 Because of it's original name: UNIX System Resources (usr).

As William pointed out, this is just another silly rationalization
done after the fact. But, just for argument's sake, lets suppose that
usr was named like that because it was the acronym for UNIX System
Resources.

*Who cares about that now?* It was 43 years ago. My cellphone is
thousands of times faster than the PDP-7 Unix was originally developed
for, and it has millions of times more storage. The length
restrictions imposed on system directories are completely superfluous
now.

All the arguments for keeping /bin, /sbin, /usr/bin, and /usr/sbin
separated are really instances of the Chewbacca defense [1]. They just
don't make any sense.

If upstream projects want to move everything to one location, Gentoo
should follow suit. If enough Gentoo devs (as others had argued) want
to waste their efforts in maintaining this artificial and silly
division between /bin, /sbin, /usr/bin, and /usr/sbin, it is of course
their prerogative. But it must be clear that all the rationale behind
said division was invented after the fact, and (as Rob Landley said in
his email [2]) maintained for decades by bureaucrats who never
question _why_ they're doing things.

Regards.

[1] http://en.wikipedia.org/wiki/Chewbacca_defense
[2] http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Opinion against /usr merge

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol mike...@gmail.com wrote:
 On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner anta...@gentoo.org wrote:
[snip]
 Debian uses initramfs-tools...

 AFAIK, neither genkernel nor dracut were expected to get tied to the
 Gentoo update process. Has that changed?

The kernel you are running (if you update your machine) is not tied to
the Gentoo update process. The *source code* gets installed, but the
kernel source remains unchanged in /usr/src/whatever. It's the user
responsibility to configure, compile, and install the kernel (and then
update LILO, grub-legacy or GRUB2). It can be automated with (ta-da)
genkernel, but it's not tied to the Gentoo update process.

I really don't see that much difference with needing to also update
the initramfs, if needed.

Because, besides, if your /usr is not in a different partition, you
don't even *need* an initramfs. In that case not using an initramfs is
supported by all upstreams.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Opinion against /usr merge

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 2:12 PM, Michael Mol mike...@gmail.com wrote:
 On Wed, Jul 18, 2012 at 3:03 PM, Canek Peláez Valdés can...@gmail.com wrote:
 On Wed, Jul 18, 2012 at 1:53 PM, Michael Mol mike...@gmail.com wrote:
 On Wed, Jul 18, 2012 at 2:47 PM, Alec Warner anta...@gentoo.org wrote:
 [snip]
 Debian uses initramfs-tools...

 AFAIK, neither genkernel nor dracut were expected to get tied to the
 Gentoo update process. Has that changed?

 The kernel you are running (if you update your machine) is not tied to
 the Gentoo update process. The *source code* gets installed, but the
 kernel source remains unchanged in /usr/src/whatever. It's the user
 responsibility to configure, compile, and install the kernel (and then
 update LILO, grub-legacy or GRUB2). It can be automated with (ta-da)
 genkernel, but it's not tied to the Gentoo update process.

 I really don't see that much difference with needing to also update
 the initramfs, if needed.

 What if your DNS resolver in your rescue shell has a vulnerability?
 What if wget, links or whatever network tools you use during recovery
 have a vulnerability?

 These are tools which are commonly placed in initramfs.

First of all, none of this has nothing to do with the discussion at
hand. Second, I don't know what kind of initramfs you are familiar
with, but mine has nothing network related, and I don't see *any*
reason to include *anything* network related to an initramfs.

 Because, besides, if your /usr is not in a different partition, you
 don't even *need* an initramfs. In that case not using an initramfs is
 supported by all upstreams.

 And what of /var? /opt?

What about them? Again, what it has this anything to do with our
current discussion?

 The problem with the /usr merge upstream is
 that someone didn't think things through when they pushed it, and the
 same reasoning used to justify it easily justifies changing the way
 /var and /opt are treated.

That's pure speculation. Nobody has ever suggested merging /opt nor
/var; if I'm mistaken I would love to see even a single link (mail,
blog post, IRC discussion) were it was at least mentioned as a good
idea to do the same with /opt or /var. I'm pretty sure you don't have
any.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Opinion against /usr merge

[Canek Peláez Valdés]

On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol mike...@gmail.com wrote:
 On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman ri...@gentoo.org wrote:
 On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol mike...@gmail.com wrote:
 AFAIK, neither genkernel nor dracut were expected to get tied to the
 Gentoo update process. Has that changed?

 We don't even update kernels as part of the regular update process,
 let alone initramfs systems.

 In general you update them together.

 The only issue I could see is if problems arise if you have a
 different version of udev in your initramfs than on your system.  I
 don't know if that actually causes problems.  For the most part after
 the system is booted the initramfs is done its job.

 The most widely touted benefit I've heard for initramfs is its
 capability to ease system recovery in case, e.g. a critical filesystem
 refuses to mount. With recovery roles come recovery tools, which
 quickly extends network-aware tools and a security attack surface.

The real benefit is that it allows you to mount any partition, if the
tools to mount it live in the same partition. Recovering tools can be
put in the initramfs, but I don't think nobody actually thinks that
this is the most widely touted benefit. Again, citation please.

 Hence why I tend to feel that if an initramfs is going to become the
 go-to solution for bootstrapping userland, it's important to consider
 the difficulties of keeping the packed tools up-to-date; it's not just
 a bootstrap tool, it's also the first recovery option a sysadmin
 faces.

If you keep your initramfs synchronized (which is easily done with
dracut, for example), that problem goes away.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: udev - mdev

[Canek Peláez Valdés]

On Sat, Jul 14, 2012 at 12:35 AM, Sylvain Alain d2racing...@gmail.com wrote:
 Hi all, about the Mdev stuff, Slashbeast from Funtoo.org started that
 project a while ago.

 https://github.com/slashbeast/mdev-like-a-boss

 I think that it's actually working pretty good on his box.

 Some Coredevs from Funtoo are actually running with that stuff.

I don't think anybody has ever suggested that it's not possible to run
mdev instead of udev: as Walter has proved, it is indeed possible.

The question Olivier and William are making is (if I understand
correctly) if you don't need the features of udev, then why not use
only devtmpfs. I think everyone agrees that mdev doesn't have (and
probably never will nor want) all the features that udev has.

Seeing all the trouble some people have taken to make their systems
work with mdev just to avoid having to use an initramfs, I really
wonder how much effort it would have taken the simple task of learning
one step more when updating kernels and switch to use an initramfs.

Then again, everyone is entitled to work in the features (or
anti-features) they want. It is FLOSS after all.

Just the 0.02 ${CURRENCY} of a happy udev/systemd user (I'm really
happy the merged the two project trees).

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: udev - mdev

[Canek Peláez Valdés]

On Sat, Jul 14, 2012 at 4:02 PM, Peter Stuge pe...@stuge.se wrote:
[snip]
 Anyone who tries to argue that initramfs would be good for me to
 have on my systems should brace themselves for a mouthful of foul
 swedish language coming their way! ;)

I don't think anyone has argued it's good for anyone. An initramfs
it's just now the only supported way (by udev and systemd) to have a
separated /usr partition.

If your /usr is in the same partition as /, then udev and systemd
supports your configuration *without* an initramfs. I have it like
that in a couple of servers, and actually I only use an initramfs in
my laptop and desktop because I like plymouth.

If your /usr is in a separate partition as /, and you don't want to
use an initramfs, you're free to do so. Only then udev (and systemd,
if you use it) will not support your configuration, and any problem
you encounter will be ignored in their mailing lists/bugzillas.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: udev - mdev

[Canek Peláez Valdés]

On Fri, Jul 13, 2012 at 7:13 PM, Walter Dnes waltd...@waltdnes.org wrote:
 On Sat, Jul 14, 2012 at 01:49:32AM +0300, Maxim Kammerer wrote
 On Fri, Jul 13, 2012 at 11:12 PM, Richard Yao r...@gentoo.org wrote:
  mdev would need to switch to the netlink hotplug interface.

 I think that's quite unlikely, since mdev is not a daemon. Perhaps by
 the time /proc/sys/kernel/hotplug is gone, mdev advocates will have
 settled on some early udev fork. [1]

   Do you realize this would effectively kill linux in the embedded
 device area?  Udev, even without the systemd code, is simply to large
 for embedded devices.

The guys from ProFUSION would disagree with you:

http://profusion.mobi/

It is a a software development company focused on embedded systems,
and several of its employees contribute code and ideas for systemd, so
they also use udev. For embedded systems.

The idea that udev is simply to large is simply incorrect, I believe.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: udev - mdev

[Canek Peláez Valdés]

On Fri, Jul 13, 2012 at 8:28 PM, Michael Mol mike...@gmail.com wrote:
 On Fri, Jul 13, 2012 at 9:22 PM, Walter Dnes waltd...@waltdnes.org wrote:
 On Sat, Jul 14, 2012 at 03:41:36AM +0300, Maxim Kammerer wrote
 On Sat, Jul 14, 2012 at 3:13 AM, Walter Dnes waltd...@waltdnes.org wrote:
  Do you realize this would effectively kill linux in the embedded
  device area?  Udev, even without the systemd code, is simply to large
  for embedded devices.

 What's ?too large?? Udev already looks pretty small to me (116k udevd,
 50k libudev, 500k resident memory), and I didn't even try compiling it
 with all extra features switched off. If that's too large for an
 embedded device, does that device really need (or can handle) anything
 more than devtmpfs?

   What does equery depgraph show for udev?  Since I don't have udev
 installed, I can't check it here.

[snip]

 sys-fs/udev-186:
  [  0]  sys-fs/udev-186
  [  1]  dev-libs/glib-2.30.3
  [  1]  dev-libs/gobject-introspection-1.30.0-r2
  [  1]  sys-libs/libselinux-2.1.9-r1
  [  1]  sys-apps/kmod-
  [  1]  sys-apps/util-linux-2.20.1-r2
  [  1]  dev-util/gperf-3.0.4
  [  1]  dev-util/intltool-0.50.2
  [  1]  virtual/pkgconfig-0
  [  1]  virtual/os-headers-0
  [  1]  dev-util/gtk-doc-1.18-r1
  [  1]  sys-devel/automake-1.11.1
  [  1]  sys-devel/automake-1.12.1
  [  1]  sys-devel/autoconf-2.68
  [  1]  sys-devel/libtool-2.4-r1
  [  1]  sys-apps/hwids-
  [  1]  sys-fs/udev-init-scripts-

A lot of that is optional. The only hard dependencies are:

=sys-apps/kmod-5
=sys-apps/util-linux-2.20
dev-util/gperf
=dev-util/intltool-0.40.0
virtual/pkgconfig
virtual/os-headers

Everything else is optional. I repeat: the idea that udev is somewhat
bloated or fat is really incorrect.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: udev - mdev

[Canek Peláez Valdés]

On Fri, Jul 13, 2012 at 9:32 PM, Canek Peláez Valdés can...@gmail.com wrote:
[snip]
 A lot of that is optional. The only hard dependencies are:

=sys-apps/kmod-5
=sys-apps/util-linux-2.20
 dev-util/gperf
=dev-util/intltool-0.40.0
 virtual/pkgconfig
 virtual/os-headers

 Everything else is optional. I repeat: the idea that udev is somewhat
 bloated or fat is really incorrect.

Little correction: inherit autotools brings things like automake and
libtool, but then again, almost *every* Gentoo installation has those.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Stability of /sys api

[Canek Peláez Valdés]

On Tue, May 15, 2012 at 1:32 AM, Olivier Crête tes...@gentoo.org wrote:
 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.

I agree. And I don't believe people who don't want to easily use USB
sticks or digital cameras or gsm dongles or really any modern
hardware qualify as the vast majority of people.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Canek Peláez Valdés]

On Wed, Mar 14, 2012 at 7:07 PM, Rich Freeman ri...@gentoo.org wrote:
 On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao r...@cs.stonybrook.edu wrote:

 I proposed a way that this could work with no effort on the part of the
 Gentoo developers in one of my earlier emails:


 Then go ahead and make it happen.  If as you say no dev participation
 is needed there is nothing Gentoo needs to do to support this.

 On Wed, Mar 14, 2012 at 6:49 PM, Greg KH gre...@gentoo.org wrote:

 We aren't Debian here people, we don't support everything :)

 If you want to support both, great, feel free to step up and do the
 work.


 Gentoo is about choice, but it is largely about the choices that
 people are willing to step up and maintain.

 A few months ago there was a big thread and lots of devs said that
 systemd isn't supported on Gentoo.  Some devs stepped up and decided
 to maintain it and now I'd say systemd is about as supported on Gentoo
 as Prefix, FreeBSD, Sparc, or MIPS.  That didn't happen because of
 mailing list persuasion - it happened because a few people interested
 in making it happen wrote a bunch of ebuilds.  How do systemd units
 end up in various packages?  The people interested in seeing them
 write good-quality patches and submit bugs, or otherwise work with the
 maintainers to commit them.

 For those who don't like the current direction, by all means create an
 overlay called udev-root, mdev-boot, noinitramfs, or whatever.  You
 don't need anybody's permission to do it - just go on github and make
 it happen.  Write some good code.  There are several devs here who
 might even help you out with it, and nobody here is going to object to
 packages going into the main tree as long as they're maintained in
 accordance with Gentoo QA.  Create some USE flags where you need
 tie-ins to other system packages and as long as everything behaves
 nicely and patches are good and maintained, I'm sure the package
 maintainers will accept them.

In that vein... just to let you guys know that I have set up an
overlay that has allowed me to run my Gentoo machines with only
systemd: no OpenRC, no baselayout, no sysvinit:

http://xochitl.matem.unam.mx/~canek/gentoo-systemd-only/

The changes are rather minimal (less than ten lines (usually a cople)
per ebuild changed from the original ebuilds in the tree), and almost
all will go away when the following bugs get fixed:

https://bugs.gentoo.org/show_bug.cgi?id=366173
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=373219
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=399615
https://bugs.gentoo.org/show_bug.cgi?id=405703
https://bugs.gentoo.org/show_bug.cgi?id=408379

Bug 373219 is specially problematic, since several scripts in packages
on the tree source /etc/init.d/functions.sh, (which lives in OpenRC),
and don't depend on OpenRC explicitly. I wrote a little script that
replaces the einfo, ewarn, etc. functions of OpenRC, and it seems to
be working. I also wrote alternative versions of the packages on the
tree that implicitly depend on OpenRC, so they now explicitly depend
on a little package that only installs my script.

It seems to be working.

If you guys want to try it, I would love to hear some comments about
it. (Usual disclaimer; if it breaks, you get to keep all the pieces).

Oh, and obviously the only supported setups are those with /usr in the
same partition as /; or, if /usr is in a separated partition, systems
that use an initramfs to mount it.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: Let's redesign the entire filesystem!

[Canek Peláez Valdés]

On Thu, Mar 15, 2012 at 7:17 PM, Canek Peláez Valdés can...@gmail.com wrote:

[...]

 https://bugs.gentoo.org/show_bug.cgi?id=366173
 https://bugs.gentoo.org/show_bug.cgi?id=373219
 https://bugs.gentoo.org/show_bug.cgi?id=399615
 https://bugs.gentoo.org/show_bug.cgi?id=405703
 https://bugs.gentoo.org/show_bug.cgi?id=408379

Oops, sorry, fogot to use uniq.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: newsitem: unmasking udev-181

[Canek Peláez Valdés]

On Tue, Mar 13, 2012 at 2:43 AM, Walter Dnes waltd...@waltdnes.org wrote:
 On Sat, Mar 10, 2012 at 09:53:25PM -0500, Rich Freeman wrote

 Perhaps a suggestion for the news item.  I'd recommend that anybody
 who needs an initramfs to mount /usr get that working BEFORE they
 upgrade udev.  This situation is a heck of a lot easier to figure out
 if the system still can be booted when the initramfs doesn't work.

  Question... does it have to be an initramfs, or can the vast majority
 of simple cases be handled by a simple initscript in /bin or /sbin that
 mounts /usr, and does whatever else is required, before handing off
 control to /sbin/init.

  I've migrated to mdev, so I won't be seeing this problem, but a simple
 solution that works for 95% of users might be the way to go.  For the
 more complex situations, an initramfs will be necessary.

The devs are already discussing moving /bin/* to /usr/bin/* (if I
understood correctly), so this will not last.

And besides, genkernel and dracut are automatized; they *are* the
simple (and proper, IMHO) solution.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[gentoo-dev] Remove package from system set in custom profile

[Canek Peláez Valdés]

Hi; I'm trying to make a custom profile, and I need to remove a
package from the system set. Is there a way I can do this without
editing /usr/portage/profiles/base/packages?

Sorry if this is the wrong place for asking such a question.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

[gentoo-dev] Re: Remove package from system set in custom profile

[Canek Peláez Valdés]

On Thu, Feb 16, 2012 at 7:26 PM, Canek Peláez Valdés can...@gmail.com wrote:
 Hi; I'm trying to make a custom profile, and I need to remove a
 package from the system set. Is there a way I can do this without
 editing /usr/portage/profiles/base/packages?

I see now that I can copy the whole /usr/portage/profiles dir to my
overlay, edit base/packages there, and link /etc/make.profile to the
profile in my overlay. This has several drawbacks:

1. I need to keep in syncro the profiles dir in my overlay to the one
in the portage tree.
2. I probably don't need a whole copy of /usr/portage/profiles.
3. It sure is ugly as hell.

Is there a better way to do it?

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: Remove package from system set in custom profile

[Canek Peláez Valdés]

On Thu, Feb 16, 2012 at 10:43 PM, Duncan 1i5t5.dun...@cox.net wrote:
 Canek Peláez Valdés posted on Thu, 16 Feb 2012 19:26:22 -0600 as
 excerpted:

 Hi; I'm trying to make a custom profile, and I need to remove a package
 from the system set. Is there a way I can do this without editing
 /usr/portage/profiles/base/packages?

 Sorry if this is the wrong place for asking such a question.

 FWIW, gentoo-dev is for development related questions.  The right place
 would be the gentoo-user list.  Not really right but better than the
 general gentoo-dev list would be the portage-devel list.

I would have that in mind next time.

 Never-the-less and not to send you away empty-handed, yes of course
 there's a way to override it locally.  Gentoo wouldn't be gentoo
 otherwise. =:^)

 See the portage (5) manpage, in particular, a search on
 /etc/portage/profile in that manpage, plus the note under the packages
 file description (in the /etc/make.profile/ section) about removing
 packages from the system set.

 More specifically, here's my /etc/portage/profile/packages:

 # I don't need these
 -*sys-apps/busybox
 -*sys-apps/module-init-tools

 If the package is listed as a dependency somewhere as well, you may need
 to add an entry to packages.provided in the same dir, as well.  For
 example, from mine (I build everything I need into the kernel,
 no kernel modules so no module-init-tools needed to load them, either):

 sys-apps/module-init-tools-

That's exactly what I needed. Thanks.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger w...@mailstation.de wrote:
 On 15.10.2011 10:42, Michael Schreckenbauer wrote:
 in what way will exherbo deal wih this mess? Are there any plans?

 We don't support /usr on a separate partition. People can, of course, do
 that and I'll point them to dracut for creating an initramfs.

 Or they can do whatever works for them. People using Exherbo are
 expected to be able to deal with such stuff.

And I believe exherbo recommends systemd as init system.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Sat, Oct 15, 2011 at 2:13 AM, Canek Peláez Valdés can...@gmail.com wrote:
 On Sat, Oct 15, 2011 at 1:57 AM, Wulf C. Krueger w...@mailstation.de wrote:
 On 15.10.2011 10:42, Michael Schreckenbauer wrote:
 in what way will exherbo deal wih this mess? Are there any plans?

 We don't support /usr on a separate partition. People can, of course, do
 that and I'll point them to dracut for creating an initramfs.

 Or they can do whatever works for them. People using Exherbo are
 expected to be able to deal with such stuff.

 And I believe exherbo recommends systemd as init system.

Yes, they do:

http://exherbo.org/docs/install-guide.html

o Install an init system

 There’s no init system in our stages. This allows you to choose
whatever init system (or none) you’d like to use:

   - sys-apps/systemd (recommended) - modern, fast init system.
Needs kernel =2.6.36-rc1.
   - sys-apps/baselayout - Gentoo’s old, crufty Baselayout-1.
   - sys-apps/upstart - Ubuntu’s init system. We don’t generally
supply init scripts for this.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Fri, Oct 14, 2011 at 8:37 PM, Walter Dnes waltd...@waltdnes.org wrote:
 On Thu, Oct 13, 2011 at 10:12:52AM -0400, Thomas Kahle wrote

 https://www.xkcd.com/963/

  Xorg --configure

Funny, I haven't used a /etc/X11/Xorg.conf in years:

negra ~ # ll /etc/X11/
total 20
drwxr-xr-x 2 root root 4096 Sep 12 17:49 app-defaults
-rwxr-xr-x 1 root root 1301 Aug 31 15:54 chooser.sh
drwxr-xr-x 2 root root 4096 Sep 30 09:36 Sessions
-rwxr-xr-x 1 root root  923 Aug 31 15:54 startDM.sh
drwxr-xr-x 3 root root 4096 Aug 31 15:54 xinit
negra ~ #

It's great; it just works. And it is thanks (in great part) to udev.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger vap...@gentoo.org wrote:
 On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
 While I've seen a lot of whining about this whole issue, I certainly
 haven't been seen any effort to actually solve the problem within the
 existing framework. For example, if someone cares enough, why not
 write a wrapper script to track down the programs and libraries at
 runtime that actually do use /usr so it's easier to say these
 packages install rules that need / and /usr on the same partition.

 (1) udev has provided a workaround of sorts for this already: udevadm trigger
 --type=failed.  this is the udev-postmount init.d script.  (2) it's fairly
 trivial to locate most (all?) the failing rules with a single grep: grep /usr
 -R /lib/udev/rules.d/.

If this comment is true (haven't looked at the code):

https://bugs.gentoo.org/show_bug.cgi?id=375263#c23

that trigger has been removed from udev.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Thu, Oct 13, 2011 at 11:55 AM, Canek Peláez Valdés can...@gmail.com wrote:
 On Thu, Oct 13, 2011 at 10:02 AM, Mike Frysinger vap...@gentoo.org wrote:
 On Thursday 13 October 2011 12:30:06 Arun Raghavan wrote:
 While I've seen a lot of whining about this whole issue, I certainly
 haven't been seen any effort to actually solve the problem within the
 existing framework. For example, if someone cares enough, why not
 write a wrapper script to track down the programs and libraries at
 runtime that actually do use /usr so it's easier to say these
 packages install rules that need / and /usr on the same partition.

 (1) udev has provided a workaround of sorts for this already: udevadm trigger
 --type=failed.  this is the udev-postmount init.d script.  (2) it's fairly
 trivial to locate most (all?) the failing rules with a single grep: grep /usr
 -R /lib/udev/rules.d/.

 If this comment is true (haven't looked at the code):

 https://bugs.gentoo.org/show_bug.cgi?id=375263#c23

 that trigger has been removed from udev.

Answering myselef; it is gone:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=289a1821a4a7636ce42a6c7adc3a9bb49421a5ea

commit 289a1821a4a7636ce42a6c7adc3a9bb49421a5ea
Author: Kay Sievers kay.siev...@vrfy.org
Date:   Thu Oct 6 00:45:06 2011 +0200

remove 'udevadm trigger --type=failed' and SYSFS, ID, BUS keys

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Suggestion for getting rid of udev

[Canek Peláez Valdés]

On Wed, Oct 12, 2011 at 6:09 AM, Walter Dnes waltd...@waltdnes.org wrote:
 Goodbye desktop users then.

 We recently dropped HAL. Now all the magic that was done by HAL (and
 required udev anyway) is done through udev directly.

  My system worked just fine before HAL was introduced, thank you.  I
 always had sys-apps/hal and sys-apps/dbus in /etc/portage/package.mask
 and my system continued to work just fine, thank you.

This is not about *your* system, it's about the general Gentoo
community systems. And in most cases, the functionality that mdev
provides is not even a fraction of what udev can do, like it or not.

I have a pair of bluetooth headphones; I turn them up and set them to
pair with something, and gnome-shell in GNOME 3 right away asks me if
it's OK to pair with them. I say yes, and the headphones are
immediately available in the desktop; thanks to PulseAudio, I can
transfer all my apps (or only some of them) to the headphones, without
even needing to pause the streams.

All of this without a single modification to a config file. It just
works. And that is thanks to udev (among several other pieces of the
stack).

mdev is designed for embedded systems (like busybox). By design it
cannot handle of the cases that udev handles, and so it is not suited
for a general purpose distribution like Gentoo. If you wan to try to
use it, that's your right of course. But don't ask the Gentoo devs to
do the work for you; do it yourself. And be aware that anyway the devs
will choose to stick with udev (like many have already said), because
they have to think about the general case, not an arbitrary particular
case.

Just the .02 ${CURRENCY} from an old Gentoo user happy with systemd,
dracut, udev, dbus, GNOME 3, and other really cool new technologies.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?

[Canek Peláez Valdés]

On Mon, May 16, 2011 at 8:13 PM, Duncan 1i5t5.dun...@cox.net wrote:

[...]

 User perspective...

For the sake of having a user with a different point of view, let me
say that I firmly believe the new *kit daemons (along things like
pulseaudio, systemd, GNOME 3, KDE 4) are the future, and Gentoo should
drop support for older technologies as soon as possible. Emphasis in
as soon as possible, not today.

The groups model was good, 40 years ago. But it's restrictive (a group
gets all or nothing), inflexible, and it difficults the implementation
of nice GUIs that take care of them. And it's not only my point of
view: the people in the kernel, in freedesktop, and in GNOME and KDE
think similarly, and that's why this pletora of new *kit programs (and
related new technologies) are becoming mandatory to run not only
desktop workstations, but also servers and embeded systems.

And actually that's the most powerful reason for Gentoo to drop
support for the older technologies: The people who actually *writes*
the code are starting to drop support for them.

We should embrace the new technologies. Sure, sometimes a new
technology would turn out to be a mistake (HAL), or it would take a
while to get really good (pulseaudio, ALSA replacing OSS). But when
they finally get there, it's worth every step of the way.

Of course they can take a while to get there, and that's why I'm
saying that the support must be dropped as soon as possible, not
today. But eventualy said support must be dropped: The maintainers
of the code would not support it, so I don't see a reason to waste the
Gentoo developers time doing it.

I know a lot of people would be 100% against what I'm saying, and they
will be very vocal about it. But I just want to leave note that there
are people like me who actually want to embrace this new technologies,
and that we are willing to do the testing and suffer the pains of
trying the new technologies.

And I say this as a user of Unix since 1996, and writing this email in
my laptop running Gentoo with the systemd and GNOME 3 overlays
installed at the same time, and loving how the shape of the future
looks like.

Just my ${CURRENCY/100}.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-dev] Installing systemd units with gx86 packages

[Canek Peláez Valdés]

On Sun, Apr 24, 2011 at 4:35 PM, William Hubbs willi...@gentoo.org wrote:
 On Sun, Apr 24, 2011 at 09:36:30AM +0200, Michał Górny wrote:
 Fellow devs,

 I've started working on bringing systemd to Gentoo [1] lately,
 and I think it is important to raise the aspect of systemd unit
 inclusion in various packages in gx86 ASAP.

 The number of packages coming with systemd units is growing rapidly
 recently, and that especially applies to freedesktop packages.
 One side effect of that is that these packages treat systemd
 as an automagic dependency, installing systemd units whenever its
 pkgconfig file is installed. I already opened two bugs on that [2,3]
 but there would be much more...

 I think the better way to handle this will be to patch the build systems
 to not make this an automagic dependency and send those patches
 upstream.

 http://www.gentoo.org/proj/en/qa/automagic.xml

 I'm not a member of qa, but I agree with this position on automagic
 dependencies.

I'm speaking as a simple user, but I don't think the systemd unit
files qualify as automagic dependencies as described by the QA
document. In the first place, as Michael pointed out, we can disable
them with --without-systemdsystemunitdir, so there is no magic at all.
In the second place, the usual Gentoo way of enabling OpenRC services
is to *add* init.d scripts in the ebuild, and this is completely
orthogonal to a package installing a systemd unit file (the presence
of the later does not matter to OpenRC at all). And finally, the idea
of systemd is to be a completely distro-agnostic init system, without
the  multiple failures of SysV, and without the one-company-rule of
Upstart; this seems to be actually working, hence a lot of downstream
packages are willing (and eager) to ship systemd unit files. The init
scripts belong to the packages, they know best how the
service/whatever needs to be run.

I'm using Gentoo+systemd since a couple of months, and it works
incredible well. And I really like the idea of freeing the rather
precious Gentoo-developers time off of writing init scripts.

Just my 0.02 ${CURRENCY/100}.


 William

-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México