Re: [gentoo-dev] Help wanted with www-client/chromium

[J. Roeleveld]

On December 14, 2016 2:40:45 PM GMT+01:00, Andrey Utkin 
 wrote:
>On Tue, Dec 13, 2016 at 06:00:25PM -0500, Mike Gilbert wrote:
>> Keeping up with the frequent Chromium releases is quite a chore.
>> Recently, phajdan.jr has been slacking on the masked dev channel
>> updates due a hardware problem, so I have been spending additional
>> time on them.
>> 
>> If there are any developers with relatively fast hardware that could
>> take on the stable and/or beta channel updates, that would be most
>> appreciated. This is also something that could be done by a trusted
>> user.
>> 
>> Help with the masked dev channel is also welcome -- especially
>testing
>> the various USE flags and unbundling libraries.
>
>Have reasonably powerful amd64 hardware, can try nightly runs.
>
>Not an affiliated gentoo developer.
>
>I guess it would be best to make up collectively a tiny git repo with
>scripts which do exactly what is needed?
>
>First of all it could be a set of chromium builds with different use
>flags (a set of such configurations needs to be defined), saved as
>binary packages, so that all the builds could be tested at once by
>unpacking every build, in turn. All build logs must be saved for
>review,
>and failures should be reported. Makes sense? Ideas? Comments?

I could run this automatically evey night.
Inside a set of different chroots which sync against the tree then try to 
install and package the latest ~amd64 version with a USE combination set per 
chroot.

The resulting build logs can be emailed automatically and binary packages 
uploaded to a specified location. I also have reasonably fast hardware 
available.

If similar activities would be useful for other packages. That should be 
possible as well.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Help wanted with www-client/chromium

[J. Roeleveld]

On Tuesday, December 13, 2016 06:00:25 PM Mike Gilbert wrote:
> Keeping up with the frequent Chromium releases is quite a chore.
> Recently, phajdan.jr has been slacking on the masked dev channel
> updates due a hardware problem, so I have been spending additional
> time on them.
> 
> If there are any developers with relatively fast hardware that could
> take on the stable and/or beta channel updates, that would be most
> appreciated. This is also something that could be done by a trusted
> user.
> 
> Help with the masked dev channel is also welcome -- especially testing
> the various USE flags and unbundling libraries.

I don't use chromium often, but if it's simply bumping the ebuild and testing 
if it builds and runs, then that is something I can help with.
If there also is a quick method to check if the browser actually renders pages 
correctly (a few test-sites) then that can be added to the test-cycle.

Please contact me off-list if this is sufficient.

--
Joost

Re: [gentoo-dev] why is the security team running around p.masking packages

[J. Roeleveld]

On Wednesday, July 06, 2016 11:13:55 PM Andrew Savchenko wrote:
> On Wed, 06 Jul 2016 20:23:46 +0900 Aaron Bauman wrote:
.

> Please understand me correctly: I'm not blaming you or security
> team for this or that issue. But it looks like security team indeed
> needs to review some policies and approaches to suit needs of
> Gentoo users better in both of terms of security and usability, to
> find some reasonable compromise between them, which will satisfy
> most users. For these very issues it looks like canceling "removal
> in 30 days" clause from p.mask action will do the job.

+1 on this. Please don't simply tree-clean packages because of security 
issues. Masking them with a reference to the security issues should be 
sufficient.

Some applications can easily be used safely even with gaping security holes. 
(A heavily firewalled box or air-gap comes to mind).

--
Joost


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: Last rites: www-apps/egroupware

[J. Roeleveld]

On Thursday, July 07, 2016 06:37:09 AM Duncan wrote:
> J. Roeleveld posted on Wed, 06 Jul 2016 20:22:57 +0200 as excerpted:
> > On Thursday, June 30, 2016 10:30:07 PM Aaron Bauman wrote:
> >> # Aaron Bauman <b...@gentoo.org> (30 Jun 2016)
> >> # Unpatched security vulnerability per bug #509920.
> >> # Removal in 30 days www-apps/egroupware
> > 
> > Why is this bug being used to treeclean egroupware?
> > 
> > Why is bug  461212 not being used to actually resolve the issue?
> > If I would actually be confident that it would actually be used, I would
> > have no issue on trying to get my latest ebuild ( version 14.3.20160525
> > ) converted to the latest standards.
> 
> According to equery meta, egroupware has no individual developer
> maintainer and no proxied maintainer, only the webapps project as
> maintainer.  And apparently there, nobody has been specifically
> interested in egroupware, so it has fallen thru the cracks to some
> degree, tho newer versions /may/ be in the webapps-experimental overlay.

I tried contacting the web-apps project directly, but never received a reply.

> Here's the webapps project wiki page:
> 
> https://wiki.gentoo.org/wiki/Project:Webapps
> 
> That has this to say when discussing the overlay, quote:
> 

> 
> The overlay can be found here:
> https://cgit.gentoo.org/proj/webapps-experimental.git/

Last commit in 2011.

> Warning
> Please remember that the applications available through the overlay might
> compromise the security of your server!
> 
> The overlay is an ideal playground for new developers wishing to join our
> team. Once we see that you are capable of writing ebuilds of reasonable
> quality, we can provide you with commit rights to the overlay.
> 
> End quote.
> 
> 
> So it's possible newer versions are in the overlay, and they simply
> decided it was too much of a load to keep a version in the tree as well.
> 
> If there /aren't/ newer versions in the overlay, presumably it's because
> nobody that has access has been interested in maintaining it in the
> overlay either.
> 
> Either way, given your obvious interest, I'd suggest contacting them
> about overlay commit rights, and/or volunteering to be the proxied
> maintainer for this particular package.

Is there a way of finding out who are actually in the web-app project and which 
of them would be able and willing to work with me on this and other web 
applications that I actively use?

>From the lack of response to the email and lack of updates on the overlay, the 
project seems dead to me.

--
Joost

Re: [gentoo-dev] Last rites: www-apps/egroupware

[J. Roeleveld]

On Thursday, June 30, 2016 10:30:07 PM Aaron Bauman wrote:
> # Aaron Bauman  (30 Jun 2016)
> # Unpatched security vulnerability per bug #509920.
> # Removal in 30 days
> www-apps/egroupware

Why is this bug being used to treeclean egroupware?

Why is bug  461212 not being used to actually resolve the issue?
If I would actually be confident that it would actually be used, I would have 
no issue on trying to get my latest ebuild ( version 14.3.20160525 ) converted 
to the latest standards.

--
Joost

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Monday, April 11, 2016 01:10:15 AM Raymond Jennings wrote:
> Please don't do this.  I want my system left alone.

Please don't top-post, I want to have a logical flow of the text.


> On Sun, Apr 10, 2016 at 11:41 PM, J. Roeleveld <jo...@antarean.org> wrote:
> > On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> > > On Sun, 10 Apr 2016 02:09:35 +0200
> > > 
> > > "J. Roeleveld" <jo...@antarean.org> wrote:
> > > > I actually write my own initramfs because neither dracut not
> > > > genkernel end up with a convenient boot system.
> > > > 
> > > > I have 2 disks, both encrypted.
> > > > I prefer only to enter the decryption password once. Both Dracut and
> > > > Genkernel insist on asking for the password/key for every single disk.
> > > 
> > > Dracut on RHEL actually handles this out of the box. Might be worth
> > > finding out how.
> > 
> > Might have even been fixed in a more recent version of Dracut.
> > I just have passed the point where I am interested in it enough to try it.
> > The
> > initramfs I use gets embedded into the kernel and doesn't need any kernel
> > parameters to work.
> > 
> > It does what it needs to do with minimal work. The simplicity should also
> > make
> > it faster than the scripts generated by either Dracut or genkernel. (As
> > they
> > need to parse the kernel cmdline and try to figure out static details on
> > the
> > fly)
> > 
> > --
> > Joost

Please d

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Sunday, April 10, 2016 10:04:42 AM James Le Cuirot wrote:
> On Sun, 10 Apr 2016 02:09:35 +0200
> 
> "J. Roeleveld" <jo...@antarean.org> wrote:
> > I actually write my own initramfs because neither dracut not
> > genkernel end up with a convenient boot system.
> > 
> > I have 2 disks, both encrypted.
> > I prefer only to enter the decryption password once. Both Dracut and
> > Genkernel insist on asking for the password/key for every single disk.
> 
> Dracut on RHEL actually handles this out of the box. Might be worth
> finding out how.

Might have even been fixed in a more recent version of Dracut.
I just have passed the point where I am interested in it enough to try it. The 
initramfs I use gets embedded into the kernel and doesn't need any kernel 
parameters to work.

It does what it needs to do with minimal work. The simplicity should also make 
it faster than the scripts generated by either Dracut or genkernel. (As they 
need to parse the kernel cmdline and try to figure out static details on the 
fly)

--
Joost

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Saturday, April 09, 2016 09:07:46 PM Rich Freeman wrote:
> On Sat, Apr 9, 2016 at 8:09 PM, J. Roeleveld <jo...@antarean.org> wrote:
> > I actually write my own initramfs because neither dracut not genkernel end
> > up with a convenient boot system.
> > 
> > I have 2 disks, both encrypted.
> > I prefer only to enter the decryption password once. Both Dracut and
> > Genkernel insist on asking for the password/key for every single disk.
> 
> You can of course roll your own, but I imagine that it would be more
> straightforward to just write your own dracut plugin.  They're
> basically just scripts that run at whatever boot stage you define.
> You might also just be able to modify the existing plugin.

Possibly, but that will take longer than it took to create my own.
The config-file is 181 lines. Mostly copied from an example.
The init-file is 45 lines.

And it can be easily maintained.

--
Joost

Re: [gentoo-dev] usr merge

[J. Roeleveld]

On Saturday, April 09, 2016 05:15:08 PM James Le Cuirot wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400
> 
> waltd...@waltdnes.org wrote:
> > > I never really got the mentality that using an initramfs is a
> > > burden.
> > > 
> >   One more piece of software that can go wrong.  You have to
> > 
> > maintain+configure it; e.g. sync software and library versions with
> > what's on the rest of the system.
> 
> Errm, have you ever actually used dracut?
> 
> dracut --kver 4.5
> 
> Wow, that was hard! It requires zero configuration and that's true even
> if you've got LVM on top of LUKS on top of RAID or something equally
> complex. If you're already running that kernel version, you don't even
> need to specify it.

I actually write my own initramfs because neither dracut not genkernel end up 
with a convenient boot system.

I have 2 disks, both encrypted.
I prefer only to enter the decryption password once. Both Dracut and Genkernel 
insist on asking for the password/key for every single disk.

The ONLY reason why I feel an initramfs is warranted is because of the 
encryption. Without that, it should not be necessary.

--
Joost

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] news item: OpenRC 0.18 changes to localmount and netmount

[J. Roeleveld]

On 1 October 2015 17:49:15 CEST, Mike Gilbert  wrote:
>On Thu, Oct 1, 2015 at 10:15 AM, Ian Stakenvicius 
>wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 01/10/15 09:41 AM, William Hubbs wrote:
>>> On Tue, Sep 29, 2015 at 11:13:09AM -0400, Ian Stakenvicius
>>> wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256

 On 29/09/15 11:10 AM, Ian Stakenvicius wrote:
> On 29/09/15 10:52 AM, Alan McKinnon wrote:
>> On 29/09/2015 16:29, Ian Stakenvicius wrote:
>>> On 28/09/15 06:58 PM, William Hubbs wrote:
 Also, we are dropping the use of the -O switch for
 mount/umount -a. This is being dropped because it is
 util-linux specific and not compatible with busybox.
>>>
>>> Does this have any actual end-user impact?  AFAIK, using
>>> the -O switch was 'just added' by us originally (i think
>>> to reduce the explicit listing of the different fs types
>>> or otherwise simplify the init script code) right?  I'm
>>> just wondering if this paragraph is actually necessary or
>>> not..
>
>> As a user, that para in the news makes me ask "how does
>> this affect me?". I have to go read man pages and init
>> scripts to find out.
>
>> Perhaps this:
>
>> Also, we are dropping the use of the -O switch for
>> mount/umount -a, because it is util-linux specific and not
>> compatible with busybox. This only affects mounts with
>> "_netdev" listed under options in /etc/fstab. Such systems
>> should use "noauto" and/or "nofail" as described above.
>
>
> Exactly my thoughts.  We used -O _netdev within the
> 'netmount' script to identify which fstab entries are network
> mounts.  But we did it a different way prior to using -O
> _netdev.  And since this isn't actually related in any way to
> something end-users can set in fstab (it has to do with the
> filesystem type itself) I don't see the point in worrying
> end-users about it.
>
> I suppose it's worthwhile to note to busybox users that they
> no longer have to use alternate means of netmounting, as
> 'netmount' will now work on busybox...?
>
> Perhaps: " Also, we are dropping the use of the -O switch
> for mount/umount -a, to ensure the localmount and netmount
> scripts are compatible with busybox mount.  If your system
> uses busybox mount please migrate any custom workarounds you
> may have to the openrc localmount/netmount services. "
>

 PS - i still think we should just cut it.
>>>
>>> What is it that you think we should cut?
>>>
>>> Thanks,
>>>
>>> William
>>>
>>
>> The whole -O _netdev paragraph.  Although i'm willing to cede on
>> that as I didn't know end users set _netdev in fstab themselves; i
>> thought it was a property of filesystem types and was entirely
>> transparent to end-users.
>
>The _netdev option is really there to support things like iSCSI, where
>you are mounting a filesystem like ext4 from a block device which
>requires network connectivity.
>
>I think some changes are needed here, because this change to
>localmount is quite like to break this usage.

I don't have that in production yet, but it is scheduled in the next few months.

If there is a different way to do this, which does not include writing a custom 
boot script, I am willing and able to test this.
The test environment needs upgrading to latest versions. In my todo list for 
this weekend.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] news item: OpenRC 0.18 changes to localmount and netmount

[J. Roeleveld]

On 1 October 2015 17:49:15 CEST, Mike Gilbert  wrote:
>On Thu, Oct 1, 2015 at 10:15 AM, Ian Stakenvicius 
>wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 01/10/15 09:41 AM, William Hubbs wrote:
>>> On Tue, Sep 29, 2015 at 11:13:09AM -0400, Ian Stakenvicius
>>> wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256

 On 29/09/15 11:10 AM, Ian Stakenvicius wrote:
> On 29/09/15 10:52 AM, Alan McKinnon wrote:
>> On 29/09/2015 16:29, Ian Stakenvicius wrote:
>>> On 28/09/15 06:58 PM, William Hubbs wrote:
 Also, we are dropping the use of the -O switch for
 mount/umount -a. This is being dropped because it is
 util-linux specific and not compatible with busybox.
>>>
>>> Does this have any actual end-user impact?  AFAIK, using
>>> the -O switch was 'just added' by us originally (i think
>>> to reduce the explicit listing of the different fs types
>>> or otherwise simplify the init script code) right?  I'm
>>> just wondering if this paragraph is actually necessary or
>>> not..
>
>> As a user, that para in the news makes me ask "how does
>> this affect me?". I have to go read man pages and init
>> scripts to find out.
>
>> Perhaps this:
>
>> Also, we are dropping the use of the -O switch for
>> mount/umount -a, because it is util-linux specific and not
>> compatible with busybox. This only affects mounts with
>> "_netdev" listed under options in /etc/fstab. Such systems
>> should use "noauto" and/or "nofail" as described above.
>
>
> Exactly my thoughts.  We used -O _netdev within the
> 'netmount' script to identify which fstab entries are network
> mounts.  But we did it a different way prior to using -O
> _netdev.  And since this isn't actually related in any way to
> something end-users can set in fstab (it has to do with the
> filesystem type itself) I don't see the point in worrying
> end-users about it.
>
> I suppose it's worthwhile to note to busybox users that they
> no longer have to use alternate means of netmounting, as
> 'netmount' will now work on busybox...?
>
> Perhaps: " Also, we are dropping the use of the -O switch
> for mount/umount -a, to ensure the localmount and netmount
> scripts are compatible with busybox mount.  If your system
> uses busybox mount please migrate any custom workarounds you
> may have to the openrc localmount/netmount services. "
>

 PS - i still think we should just cut it.
>>>
>>> What is it that you think we should cut?
>>>
>>> Thanks,
>>>
>>> William
>>>
>>
>> The whole -O _netdev paragraph.  Although i'm willing to cede on
>> that as I didn't know end users set _netdev in fstab themselves; i
>> thought it was a property of filesystem types and was entirely
>> transparent to end-users.
>
>The _netdev option is really there to support things like iSCSI, where
>you are mounting a filesystem like ext4 from a block device which
>requires network connectivity.
>
>I think some changes are needed here, because this change to
>localmount is quite like to break this usage.

All,

I had a thought. Not sure if this is possible and if it is, it would mean a 
change to the fstab for people using iSCSI.

1) Add an udev rule to name iSCSI devices differently. (Currently sd×, maybe to 
something like scs×)
2) Have 'localmount' ignore those entries in fstab.
3) Have 'netmount' (or similar) mount those entries.

I haven't looked into the current scripts yet, so if this doesn't make any 
sense at all, let me know.
I will investigate this more over the weekend.

--
Joost 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] news item: OpenRC 0.18 changes to localmount and netmount

[J. Roeleveld]

On Tuesday, September 29, 2015 04:52:51 PM Alan McKinnon wrote:
> On 29/09/2015 16:29, Ian Stakenvicius wrote:
> > On 28/09/15 06:58 PM, William Hubbs wrote:
> >> Also, we are dropping the use of the -O switch for mount/umount
> >> -a. This is being dropped because it is util-linux specific and
> >> not compatible with busybox.
> > 
> > Does this have any actual end-user impact?  AFAIK, using the -O
> > switch was 'just added' by us originally (i think to reduce the
> > explicit listing of the different fs types or otherwise simplify the
> > init script code) right?  I'm just wondering if this paragraph is
> > actually necessary or not..
> 
> As a user, that para in the news makes me ask "how does this affect
> me?". I have to go read man pages and init scripts to find out.
> 
> Perhaps this:
> 
> Also, we are dropping the use of the -O switch for mount/umount -a,
> because it is util-linux specific and not compatible with busybox. This
> only affects mounts with "_netdev" listed under options in /etc/fstab.
> Such systems should use "noauto" and/or "nofail" as described above.

Does anyone know how to solve the issue when depending on iSCSI devices?
I had to add "_netdev" to ensure those would not fail during boot.

--
Joost

Re: [gentoo-dev] Anti-spam changes: proposal to drop spammy mail

[J. Roeleveld]

On 11 May 2015 15:59:40 CEST, Rich Freeman ri...@gentoo.org wrote:
On Mon, May 11, 2015 at 9:37 AM, C Bergström cbergst...@pathscale.com
wrote:
 Sorry to shoot and run, but I think you're trying to tackle this
 problem in the wrong way. The problem isn't to drop the mail. The
 solution is to change email hosting providers. As a non-profit I
 believe Google hosted apps would be an option (free).

In general we try to stick to our social contract, and that means
trying to avoid depending on proprietary technologies such as gmail.

Now, I could see just using a FOSS-based IMAP/SMTP/POP provider,
perhaps which allows things like forwarding and such, which allows us
to have a copy of all our configuration and such in case we want to
migrate.  I'm not super-familiar with the wordpress.com model but
something like that also seems reasonable - we leverage donations of
hosting services but we aren't bound to anything proprietary and have
the ability to migrate off.

I'd REALLY like to see a FOSS alternative to Gmail (a good one, that
is), and ditto for Google docs (or whatever the latest branding for
that is). There is nothing magical about cloud-based services any more
than there is anything magical about letting somebody else host your
website.  The key is to ensure that the technologies are open so that
you aren't bound to a single provider.

Rich,

If you are thinking of a FOSS email provider. Maybe investigate Fastmail?

They use postfix and cyrus. And they also handle a lot of the development of 
the latter.

Not sure if they would fit in with the rest, but I would trust them sooner then 
Google.

--
Joost 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] rfc: trimming the @system set [was: adding sys-apps/iproute2 to the @system set]

[J. Roeleveld]

On Sunday, September 07, 2014 05:57:57 PM Joshua Kinard wrote:
 On 09/07/2014 17:04, Rich Freeman wrote:
  On Sun, Sep 7, 2014 at 4:33 PM, Joshua Kinard ku...@gentoo.org 
wrote:

snipped

  As for Parallel builds, do you make make -jX?  Or running concurrent
  emerges in different shells?  I wasn't commenting at all on parallel
  builds. 
  I was referring to --jobs.  The issue with @system is that you can't
  build packages in @system in parallel, or their dependencies.  Now,
  I'm not sure if that extends to dependencies of virtual packages - if
  not then an editor isn't as much of a problem.  However, you're still
  stuck with lots of whining by portage if you unmerge your last editor.
  I think we really need to reserve that for situations where you're
  actually likely to break something.  You can unmerge and re-merge an
  editor without any issues at all, and there are probably lots of
  useful substitutes for editors that aren't in the editor virtual.
 
 Well, I believe a stage2 in catalyst is just a remerge of @system, and
 that's only ~12 hours on my Octane, which is perfectly fine for me.  So 
the
 parallelization isn't a real concern.  Stage3 takes ~30hrs, though, so I'd
 be curious to see if that parallelizes well once I get SMP working on that
 machine.
 
 Then again, those of us who work with slower hardware probably have a 
much
 higher level of patience than others.  So while the inability to parallelize
 the @system merge isn't a concern for me, it is for others.

With faster hardware, I don't need as much patience.
But on slower machines, as I am used to fast ones, I tend to notice the 
lack of parallellism during the emerge-phase.

  I'm not suggesting that we rip out editor just now either.  It makes
  more sense to just try to hold the line on @system until we have
  something better actually implemented (like mix-ins), and then it
  won't be a big deal if we trim it down further.
 
 The editor is a total non-issue to me.  I simply raised it as part of my
 reply to branch the thread off.  I am perfectly fine keeping virtual/editor
 in @system and letting nano be the primary satisfier.

Personally, I would not have an issue with the stage3 not having an editor, 
but it would make installing Gentoo more difficult considering there are 
some files that need to be edited. And the handbook actually references 
nano.

  To cut down on replies - the reason nano is preferred is that it is
  the first package in the virtual, which is the usual rule.  Of course,
  it was placed there deliberately since it is a simple editor with few
  dependencies and both the vi and emacs camps can agree that it is
  lousy.
 
 The vi and emacs camps agreeing on something?  Impossible!

I think both camps do the following:
emerge preferred editor
emerge -C nano
as one of the first steps.

The first thing I do on a new install as soon as a portage tree is available is 
run the above.

--
Joost

OT - My last one to this thread - Skype + Tox - Re: [gentoo-dev] Re: maintainer-needed@ packages need you!

[J. Roeleveld]

On Tuesday, September 09, 2014 08:59:41 PM Andrew Savchenko wrote:
My last response to this, as it is getting too OT

 Hello,
 
 On Sun, 07 Sep 2014 17:51:46 +0200 J. Roeleveld wrote:
  It probably works, provided all your contacts also use it.
  As long as the vast majority of my contacts use Skype and Yahoo, I will
  not
  be able to switch. If Kopete (and other generic IM clients) would add
  support for tox, then it would be easier.
 
 There is a tox plugin for pidgin in tox-overlay.

That's nice for pidgin users. When others follow, uptake will be easier.

  Which trojan injection are you talking about?
 
 I'm talking about the following research:
 https://www.google.com/url?sa=trct=jq=esrc=ssource=webcd=1cad=rjauact
 =8ved=0CB4QFjAAurl=https%3A%2F%2Fwww.blackhat.com%2Fpresentations%2Fbh-eur
 ope-06%2Fbh-eu-06-biondi%2Fbh-eu-06-biondi-up.pdfei=9jAPVJH1AafnygOOiIHgDg
 usg=AFQjCNHeILDYY4k-nUUw8vPmUCJ86Eywbgbvm=bv.74649129,d.bGQ
 
 Of course, skype protocol was likely changed since that time, but I
 really doubt that functionality for remote execution of arbitrary
 code was removed.

That research was from 2006. Over 8 years ago.
Do you avoid using Bind because of all the security bugs it had in 2006?
What about OpenSSL, that one had a big one not too long ago.
And I'm sure I can find plenty of exploits for the Linux kernel based on the 
versions in use in 2006.

The Skype protocol has changed a lot over the years and older versions of the 
protocol have been deprecated and removed.

If it is still in there, I'm certain it would be known, considering the amount 
of people using Skype these days.

--
Joost

Re: [gentoo-dev] Re: maintainer-needed@ packages need you!

[J. Roeleveld]

On Sunday, September 07, 2014 01:16:57 AM Andrew Savchenko wrote:
 Hello,
 
 On Mon, 01 Sep 2014 07:15:53 +0800 Patrick Lauer wrote:
  On Sunday 31 August 2014 11:39:22 hasufell wrote:
   Martin Vaeth:
hasufell hasuf...@gentoo.org wrote:
On 08/30/2014 02:35 PM, J. Roeleveld wrote:
For net-im/skype,

Screw skype.

Please don't. Not all communication partners are linux users.
   
   Tox is multiplatform.
   
We have tox [1] on the way.

This is far from being ready, especially for non-specialists.
It is not even foreseeable whether the Android client will ever
be able to do at least audio. (So far, I was not even able to
exchange any messages at all. It may be my mistakes, but
if I am not able to do it, how could I expect this from casual
computer users?)
   
   This has nothing to do with specialists. Tox is configuration-free.
   
   And sure, it's pre-alpha as indicated in my previous mail.
  
  So it doesn't work, but you feel the need to feel superior by telling
  everyone else that they are doing it wrong.
 
 Can't agree with you here. I just tried tox (utox client) from
 tox-overlay. Works like charm from the box, the only unusual
 thing I did is keyword added to package.keywords in order to
 install live ebuild.
 
 I tested text messages, audio and video from double-nat environment
 (where SIP clients can work only using stune and only some of them).

It probably works, provided all your contacts also use it.
As long as the vast majority of my contacts use Skype and Yahoo, I will not 
be able to switch. If Kopete (and other generic IM clients) would add 
support for tox, then it would be easier.

 It should be noted that at least in Linux skype is much harder to
 install and use since it requires pulseaudio and I don't use
 that sh^W stuff. So skype reqires its own LXC container set up
 which is doable, but costed me a day (with all tight isolation
 stuff). And I even had not mentione that installation of skype
 equals to trojan injection into the system (that's why I used all
 that LXC and separate X server precautions).

If you want to isolate a package, then yes, it is more difficult then just 
running  emerge skype  (Which works flawlessly for me).

I also had no issues installing pulseaudio. (Apart from having to undo 
some alsa-settings to default to the normal audio output instead of the 
HDMI one).

Which trojan injection are you talking about?

--
Joost

Re: [gentoo-dev] systemd profiles

[J. Roeleveld]

On Friday, August 29, 2014 10:41:51 PM Rich Freeman wrote:
 On Fri, Aug 29, 2014 at 7:09 PM, Jauhien Piatlicki jauh...@gentoo.org 
wrote:
  Hi all,
  
  I have a simple question: why do we have systemd subprofiles only in gnome
  and kde profiles?
  
  Could we add systemd subprofiles also to default/linux/$arch/13.0/ and
  desktop (and any other profiles where it makes sense)?
 I'm not sure systemd profiles actually make that much sense these
 days.  To install systemd from a stage3 you basically just need to set
 USE=systemd and do an emerge -uDN world.  We're actually getting close
 to the point where you would pick an init system the way you pick a
 kernel or cron implementation during install.

Not sure if this idea has been discussed before, but:
Wouldn't it be an idea to have a virtual/init which depends on 1 of:
- OpenRC
- Systemd
- . (whichever other one)

Put virtual/init in the @system-set.
Don't put either OpenRC or Systemd in the stage3-file. (Or have 2 stage3 
files, one with OpenRC and one with Systemd)
Then, during the install, the user has to choose one of these and install it.

The virtual could even use the systemd USE-flag to decide which one to use.

--
Joost

Re: [gentoo-dev] systemd profiles

[J. Roeleveld]

On Saturday, August 30, 2014 01:41:26 PM Michał Górny wrote:
 Dnia 2014-08-30, o godz. 13:27:08
 
 J. Roeleveld jo...@antarean.org napisał(a):
  On Friday, August 29, 2014 10:41:51 PM Rich Freeman wrote:
   On Fri, Aug 29, 2014 at 7:09 PM, Jauhien Piatlicki jauh...@gentoo.org
  
  wrote:
Hi all,

I have a simple question: why do we have systemd subprofiles only in
gnome
and kde profiles?

Could we add systemd subprofiles also to default/linux/$arch/13.0/ and
desktop (and any other profiles where it makes sense)?
   
   I'm not sure systemd profiles actually make that much sense these
   days.  To install systemd from a stage3 you basically just need to set
   USE=systemd and do an emerge -uDN world.  We're actually getting close
   to the point where you would pick an init system the way you pick a
   kernel or cron implementation during install.
  
  Not sure if this idea has been discussed before, but:
 
  Wouldn't it be an idea to have a virtual/init which depends on 1 of:
 You mean our virtual/service-manager?

Yes, couldn't quickly find it.

--
Joost

Re: [gentoo-dev] maintainer-needed@ packages need you!

[J. Roeleveld]

On Saturday, August 30, 2014 01:46:20 PM Michał Górny wrote:
 Hello,
 
 Right now, we have 1262 packages assigned to maintainer-needed@. Only
 a few of them have a large number of bugs, many have just version bump
 requests. 953 packages have no bug open.
 
 Please consider adopting some of the packages, or at least fixing some
 of the relevant bugs. For package - bug count list, take a look at [1].
 Please note that this list is not autogenerated, so it will soon be
 outdated, I hope :).
 
 We should also consider removing some of the packages listed there.
 
 [1]:http://dev.gentoo.org/~mgorny/maintainer-needed.txt

I'm not a developer, which means I can't actively pick up any packages. If 
helpful, I would be willing to go through older open bugs and see if there is 
anything I can pick up.

For net-im/skype, I did check a few things last week as I had issues 
connecting:
bugs: 461668, 462504, 440512, 467252, 493068, 512576 are for version 4.3 
which can no longer connect (Versions are being blocked by Skype upstream)
I think these can be closed.
Other bugs:
485792 - xscreensaver not showing skype notifications (I don't actually want 
this myself, so not able to test)
519096 - issue with 32bit compilation (I use amd64 exclusively, unable to 
test)
518922 - hard dependency need to be added for pulseaudio (I see some ebuild-
code already listed, already got pulseaudio installed seperately)
514888 - Seems to be related to an issue with old chat-logs, there are links 
to skype-upstream in the report. This did not occur on my systems.

Re: [gentoo-dev] maintainer-needed@ packages need you!

[J. Roeleveld]

On Saturday, August 30, 2014 04:51:35 PM Michał Górny wrote:
 Dnia 2014-08-30, o godz. 14:35:20
 
 J. Roeleveld jo...@antarean.org napisał(a):
  On Saturday, August 30, 2014 01:46:20 PM Michał Górny wrote:
   Hello,
   
   Right now, we have 1262 packages assigned to maintainer-needed@. Only
   a few of them have a large number of bugs, many have just version bump
   requests. 953 packages have no bug open.
   
   Please consider adopting some of the packages, or at least fixing some
   of the relevant bugs. For package - bug count list, take a look at [1].
   Please note that this list is not autogenerated, so it will soon be
   outdated, I hope :).
   
   We should also consider removing some of the packages listed there.
   
   [1]:http://dev.gentoo.org/~mgorny/maintainer-needed.txt
  
  I'm not a developer, which means I can't actively pick up any packages. If
  helpful, I would be willing to go through older open bugs and see if there
  is anything I can pick up.
  
  For net-im/skype, I did check a few things last week as I had issues
  connecting:
  bugs: 461668, 462504, 440512, 467252, 493068, 512576 are for version 4.3
  which can no longer connect (Versions are being blocked by Skype upstream)
  I think these can be closed.
 
 Is it fine to remove all versions 4.3 from the tree then?

Should be as they will never work.
I got an email from Skype about it which I can forward, but it's in Dutch. 
(Couldn't quickly find a version in English)

 By the way, you can proxy-maintain some of those packages if you like.
 See [1].
 
 [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers

I'll have a look which of the maintainer-needed packages I use and know 
sufficiently to assist with.

--
Joost

[gentoo-dev] Help needed with ebuilds for pear.horde.org

[J. Roeleveld]

Hi All,

I am trying to create an ebuild for Egroupware 14.1. (released this month)

To find out the dependencies, I am going through the setup check and am stuck 
with the following:
**
Checking PEAR pear.horde.org/Horde_Imap_Client (2.16.0) is installed: False
PEAR::Horde_Imap_Client is needed by: EMailAdmin. You can install it by 
running: pear channel-discover pear.horde.org ; pear install 
pear.horde.org/Horde_Imap_Client
**

If I run those commands, it works, however, I prefer to use ebuilds for the 
dependencies.
I tried to create some based on existing ebuilds from the kolab overlay (they 
also use the pear.horde.org channel), but even though the install seems to 
work, it still isn't found.

I also tried to adjust an existing PEAR ebuild to:
**
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

inherit php-pear-r1

LICENSE=LGPL-3
SLOT=0
KEYWORDS=amd64
PHP_PEAR_CHANNEL=pear.horde.org
SRC_URI=http://pear.horde.org/get/${PEAR_PN}.tgz;
DEPEND=dev-php/PEAR-Horde_Channel
**

But I am unable to properly change the PEAR-channel.

I am certain I am missing something simple, but my google-fu is coming short.

If anyone is able to point me in the right direction, I would be very 
grateful.

--
Joost Roeleveld

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore

[J. Roeleveld]

On Saturday, May 31, 2014 02:17:32 PM Samuli Suominen wrote:
 On 31/05/14 05:47, Steven J. Long wrote:
  On Tue, May 27, 2014 at 09:57:01AM +0300, Samuli Suominen wrote:
  On 27/05/14 08:34, Michał Górny wrote:
  Dnia 2014-05-26, o godz. 23:15:34
  
  Samuli Suominen ssuomi...@gentoo.org napisał(a):
  UPower upstream removed sys-power/pm-utils support from 0.99 release
  (currently unkeyworded in tree), as in, from current git master.
  
  Don't worry. Looking at the past, I can guess this is only a temporary
  inconvenience. I'm pretty sure upower will be discontinued soon
  and replaced with systemd-powerd or something :D.
  
  That's more or less what they already did, they forced eg.
  xfce4-power-manager upstream
  to move the deleted pm-utils code from upower directly to the power
  manager (application)
  itself, likewise for xfce4-session
  Which means applications will now need to duplicate the pm-utils related
  code per application
  basis
  So I expect upower to be more or less dead for everything but systemd
  users, except for
  those upstreams that will actually follow the Xfce path and do the
  duplication
  Yet, still, small portition of the code is still 'generic', so
  xfce4-power-manager will still need
  both, upower, even 0.99, and then pm-utils, depending on the version,
  codepath is selected
  
  This was sort of expected, since pm-utils has been abandoned for ~5
  years now at upstream,
  so nobody is maintaining non-systemd related power management tools
  anymore, and
  falling back to eg. manual laptop-mode-tools, acpid, etc. usage will be
  necessary again,
  it's like going back to 90s for non-systemd users :P
  
  I can't believe I'm reading that from a distro-developer. Basically this
  entire thread is systemd is deprecating the existing tools, so let's dump
  them and half our userbase back to the 90s, isn't that a great thing?
 
 Then you misunderstood. Notice the :P as an indicator of sarcasm.
 I've already created sys-power/upower-pm-utils where the sys-power/pm-utils
 0.9 git branch will continue to live.

Would have been nice to fix all the dependencies BEFORE marking the systemd-
depending sys-power/upower-pm-utils stable.

--
Joost

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore

[J. Roeleveld]

On Tuesday, June 03, 2014 04:46:18 PM Samuli Suominen wrote:
 On 03/06/14 16:40, Tom Wijsman wrote:
  On Tue, 03 Jun 2014 16:28:47 +0300
  
  Samuli Suominen ssuomi...@gentoo.org wrote:
  On 03/06/14 16:20, Tom Wijsman wrote:
  Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag;
  
  No, it doesn't.
  
  Nevermind, `cvs up`-ed; heh, I don't understand how you've got to
  that change, I thought there only was a problem with 0.99.0?
  
   in comparison, 0.99.0 mainly wants you to run it with systemd:
  mainly, as in, since 0.99.0 removed support for hibenate/suspend
  in favour of systemd, the power/session managers need to integrate
  their own hibernate/suspend support diffently.
  
  Ah, right; thinking of MATE, I understand the 0.99.0 bit now.
  
26 May 2014; Samuli Suominen ssuomi...@gentoo.org
upower-0.99.0.ebuild: This release is mainly for use with
sys-apps/systemd because upstream removed support for
sys-power/pm-utils completely from git master. The 0.9 branch is
  
  for sys-power/pm-utils use. Adjust ebuild accordingly.
  
  Though I'm a bit confused why 0.99.0 doesn't list a systemd
  dependency; I thought it had one, but maybe it is in another
  package I'm unaware of.
  
  Outdated ChangeLog entry from March, those were the facts we dealt
  back then,
  only partly true anymore, consumers have evolved
  
  Which means that the situation I am assuming right now is outdated; so,
  if you don't mind feel free to highlight why 0.9.23-r3 needs systemd.
 
 To prevent OpenRC users from installing this version because it's
 an old UPower with no pm-utils support, with no hibernate/suspend support,
 to ensure desktops don't end up with greyed out Hibernate/Suspend
 buttons
 To direct users to upower-pm-utils, or upower-0.99.0, or plain pm-utils, or
 other
 To indicate OpenRC users can't stay with sys-power/upower older than 0.99.0
 because they are going away, to indicate this is the best time to make
 informed decision and take manual action regarding choosing which
 features set he/she wants, to read up upstream announcements regarding
 UPower, to follow-up and do what admins do

All this should have been in a news item, BEFORE it got stabilized.

--
Joost

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore

[J. Roeleveld]

On Tuesday, June 03, 2014 04:45:36 PM Chí-Thanh Christopher Nguyễn wrote:
 Samuli Suominen schrieb:
  On 03/06/14 16:53, Rich Freeman wrote:
  So, I get why you did it, but my concern is that when you tell
  portage that non-systemd users shouldn't use this package, portage
  helpfully solves that problem by turning all the non-systemd users
  into systemd users, instead of switching them to the alternative that
  works without systemd.
  
  Portage doesn't do anything on it's own, surely it needs an admin to
  accept
  or reject the changes
 
 I disagree. It would have been straightforward to create a transitional
 package sys-power/upower-1 which makes openrc users transition to
 sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd
 or something similar.
 
 And please keep such changes out of stable until proper documentation is
 in place (and the 30 day period has elapsed, etc.)

+1

Re: [gentoo-dev] eselect init

[J. Roeleveld]

On Sat, May 25, 2013 21:55, Tom Wijsman wrote:
 On Sat, 25 May 2013 21:09:47 +0200
 J. Roeleveld jo...@antarean.org wrote:

 How will the stop/start part of services/init-scripts/... be done?

 Not sure what you mean here; if you keep init function the same as the
 init you boot with, this should continue to work.

As an example. Lets say I want to test a new init-system. To do this, I
follow the (still to be written) guide on eselect init and boot into
new-and-shiny-init-system.

I am still used to stopping/starting services using /etc/init.d/service
start/stop
And using the rc command to add/remove services from the runlevel(s).

If I then, accidentally, type /etc/init.d/xyz start when xyz hasn't
been started by any means yet. What will happen?
I would assume that openrc will try to start xyz?
This is, I believe, something that could cause issues as dependencies
might also try to start and I then have a service running not managed by
the new-and-shiny-init-system that I was testing.

 I am assuming that should be for the user to keep in mind, but will
 it be possible to add something that will make init.d-scripts not
 work when systemd is running and unit-files not work when systemd is
 not running?

 They currently just bail out with bogus errors as far as I am aware.

  # /etc/init.d/ntpd start
 ntpd | * WARNING: ntpd is already starting
  # /etc/init.d/ntpd stop
 ntpd | * ERROR: ntpd stopped by something else

See above, what about if ntpd wasn't running yet?

  hooks on reboot are still needed for more complex ones.
 
  Which complex cases would these hooks be needed on?

 I think one of these would be the stopping/starting of services (see
 above)

 No, if you keep the init system the same as the one you boot with there
 should be no problems.

See above, what about trying to start services using the method of the
not-running init?

 [[ Below is my ONLY remark on that, please feel free to mentally
 paste it as a response any email trying to explain why it's important
 to reduce the boottime ]]

 My intention was not to advocate optimizing boot times;

I know, that bit was meant generic, not just as a reply to you.

 as a kernel
 maintainer / developer I need to test new releases, run git bisects, do
 Nouveau reclocking work. I really need this, the average person that
 keeps his PC running, not so much; I care for it because I can't wait 2
 minutes, not because I think it's shiny to have such a short boot...

 PS: I'm also a mobile laptop user that no longer has a battery. :/

I believe you can still use hibernate there? :)

--
Joost

Re: [gentoo-dev] eselect init

[J. Roeleveld]

On Sat, May 25, 2013 15:38, Tom Wijsman wrote:
 On Sat, 25 May 2013 11:54:48 +0200
 Luca Barbato lu_z...@gentoo.org wrote:

 SNIPPED
 there's one option we forget about
 here though, EFI users can build a second smaller minimally adjusted
 defconfig kernel that ends up loading the default init system if they
 wish to repair their system without chrooting.

Good suggestion, especially as I am trying out EFI-boot on one of my
machines with intention to keep it on EFI if it works.

 So, please see the /sbin/einit suggestion in Bug 465236 at Comment 34
 at https://bugs.gentoo.org/show_bug.cgi?id=465236#c34 which documents a
 sane alternative that allows users to load the default init system of
 Gentoo through their boot loader if they wish to do. This suggestion
 doesn't kill the eselect approach, but goes side-by-side with it; it
 effectively just names it /sbin/einit instead of /sbin/init to keep the
 default /sbin/init around. Another advantage is that users that don't
 want extra complexity as they don't want to compare or switch init
 systems will not get extra complexity added to their system.

I was thinking of a default option in the eselect init part that would
remove init=/sbin/einit from the kernel boot parameters.
Not sure how that would be best achieved as a lot (most?) users will have
more then one boot-option in their grub(2)/lilo config.

 - /sbin/init (or whatever linux currently calls by default with top
 priority)

 Correct as far as I recall from patching that part of boot in the past.

I don't have init= set on my machines and it seems to start /sbin/init.
So that should be correct.

 should be either a symlink to the actual implementation or a
 wrapper such as our gcc one.

 Wrapper sounds more safe to me since you allow more logic to be
 incorporated and aren't to restricted in what you can do with it early
 on, on the other hand a symlink would be a much more clean approach if
 you don't need more logic than just the symlink; although I'm not sure
 if the kernel loves a symlink for /sbin/init, haven't looked at that...

+1 for wrapper, from my understanding, symlinks for init-systems can't be
altered on a running system without risking strange behaviour.

 eselect init
 must keep track of the current active init and make sure the current
 init configuration is used till the system reboots

 When we kick off the right init system at boot, we probably don't need
 to keep track of it separately; or at least not call eselect for that.

 Sounds like we would have two files like 'current_init' and 'boot_init'
 and `eselect init ...` would update 'boot_init'. Then, the first `init`
 invocation on boot would update 'current_init' with the value of
 boot_init; latter `init` invocations can then read out 'current_init',
 which is not to be touched by `eselect init ...`.

With a case-statement in the wrapper script to handle the different
init-systems?
How will the stop/start part of services/init-scripts/... be done?
I am assuming that should be for the user to keep in mind, but will it be
possible to add something that will make init.d-scripts not work when
systemd is running and unit-files not work when systemd is not running?

From what I understand, the tools for the different init-systems will end
up being installed simultaneously.

 hooks on reboot are still needed for more complex ones.

 Which complex cases would these hooks be needed on?

I think one of these would be the stopping/starting of services (see above)

 - we could try to not have the changes to the current init systems
 ebuild or reduce them to the bare minimum (e.g. not
   overwrite /sbin/init)

 The /sbin/einit approach that I linked near the start would help here.

 # FOCUS

 My interest is mostly if not all on bb-init-openrc and slightly on
 runit-openrc.

 There are enough people involved in systemd and since I still consider
 it a dangerously frail implementation of a bad idea is better if I do
 not touch it at all.

 My system with stock openrc gets from linux start to graphical login
 in less than 6s and I'm not using Gnome so I do not have any reason
 to use it beside comparing.

 Can we please keep information that may provoke a comparison off the ML?

 I'll give a neutral objective response why the init system doesn't
 matter for this, as I'm tired of seeing people sneak in data points
 like this. In your case it's intended to be good, but it can catch
 other people off guard that don't care to stay on topic.

 [[ Please avoid responding to this part of my mail, don't go OT. ]]

SNIPPED part about boot times
I agree with the general statement here.

[[ Below is my ONLY remark on that, please feel free to mentally paste it
as a response any email trying to explain why it's important to reduce the
boottime ]]

Boot times can be optimized for most init-systems.
On most of my machines, I really don't care if the boot time is 2 seconds
or 2 minutes. They get started once and then they stay on till they are
not needed 

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

[J. Roeleveld]

(Late reply due to busy week, just want to clarify a small detail)

On Sun, May 19, 2013 16:34, Peter Stuge 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, 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,

I agree, it is not likely, but this was in relation to embedded devices
where diskspace is often at a premium.
I will probably start a new thread on gentoo-user about inodes and
filesystems configuration later this year.

--
Joost

ps. no need to reply to this :)

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

[J. Roeleveld]

On Tue, May 21, 2013 09:03, Alan McKinnon wrote:
 I don't like gnu info files. Neither me nor anyone I know can figure out
 how to drive info.

This reminded me of my experience with info-files. Don't know how long ago
it was that I used them as I find google to be a much more useful
resource.

But you might be interested in the following:

* app-text/info2html
 Available versions:  (2.0) *2.0
{{vhosts}}
 Homepage:http://info2html.sourceforge.net/
 Description: Converts GNU .info files to HTML

I haven't tried it myself yet. (Ignore the hardmask part in the output,
that's because the portage-filesystem is not automatically mounted)

--
Joost

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

[J. Roeleveld]

Andreas K. Huettel dilfri...@gentoo.org wrote:

Am Sonntag, 19. Mai 2013, 14:59:21 schrieb Michael Mol:
 On 05/18/2013 03:23 PM, Carlos Silva wrote:
  Is the real problem just the god damn unit/init files?! Damn, who
cares
  about 2KiB files in the age of GiBs?! You can install 1000 of them
that
  it will only take 2MiB of storage, so please, quit complaining
about
  this.
 
 Practically speaking, I think the problem is likely more about the
inode
 usage than the physical size of the files. With today's huge disks,
the
 problem does seem to be becoming the cost of metadata over the cost
of
 the data itself. (Why else would we need sectors larger than 512
bytes?)

Then use a decent file system.
http://kernelnewbies.org/Linux_3.8#head-372b38979138cf2006bd0114ae97f889f67ef46a
EOT

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfri...@gentoo.org
http://www.akhuettel.de/

Andreas.

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.

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: Graveyard overlay (was: Re: [gentoo-dev] last rites: games-strategy/x2, games-strategy/x2-demo)

[J. Roeleveld]

On Thursday 14 February 2013 08:53:45 Florian Philipp wrote:
 Am 14.02.2013 08:26, schrieb Michael Weber:
  On 02/14/2013 06:09 AM, Ben de Groot wrote:
  I need two things:
  
  1. Users volunteering some time to keep this running
  2. Agreement on a place to host tarballs no longer hosted upstream
  
  i'm all in.
 
 Me too. Having a central, semi-official place is probably the best solution.

Same here.

I'm also expecting  games-strategy/x3  to go the same way.

--
Joost Roeleveld

Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory

[J. Roeleveld]

Ulrich Mueller u...@gentoo.org wrote:

 On Fri, 8 Feb 2013, Tomáš Chvátal wrote:

 2013/2/8 Diego Elio Pettenò flamee...@flameeyes.eu:
 I would say that we might want to review linux-firmware, and if the
 newest firmware _is_ there, just get rid of the split one.
 
 That should be probably the best approach, to actually kill of the
 lone ones and keep the linux-firmware only.

I disagree. Why should we force users to install lots of crap (some of
it being non-free) that they will never need because they don't have
the hardware?

Ulrich

Why not specify which firmwares are to be installed using a 'FIRMWARE' 
variable. Similar to VIDEOCARDS?

--
Joost Roeleveld
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Half of the firmware packages in tree install to wrong directory

[J. Roeleveld]

Samuli Suominen ssuomi...@gentoo.org wrote:

On 09/02/13 11:11, J. Roeleveld wrote:
 Ulrich Mueller u...@gentoo.org wrote:

 On Fri, 8 Feb 2013, Tomáš Chvátal wrote:

 2013/2/8 Diego Elio Pettenò flamee...@flameeyes.eu:
 I would say that we might want to review linux-firmware, and if
the
 newest firmware _is_ there, just get rid of the split one.

 That should be probably the best approach, to actually kill of the
 lone ones and keep the linux-firmware only.

 I disagree. Why should we force users to install lots of crap (some
of
 it being non-free) that they will never need because they don't have
 the hardware?

 Ulrich

 Why not specify which firmwares are to be installed using a
'FIRMWARE' variable. Similar to VIDEOCARDS?

Read my last reply. It's already supported through savedconfig.eclass. 
You only get what you want.

I read it. Came after I sent my reply.

Not familiar with that class myself. Will take your word it allows limiting the 
firmware.

I, as a user, prefer not to have to hunt for firmware for devices supported vy 
the kernel. I would either install all of them or filter out the firmwares for 
devices I am unlikely to get.

--
Joost Roeleveld
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Thursday, December 20, 2012 09:31:36 AM Michał Górny wrote:
 On Thu, 20 Dec 2012 00:27:26 +0100
 
 J. Roeleveld jo...@antarean.org wrote:
  On Wednesday, December 19, 2012 09:13:28 AM Greg KH wrote:
   On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote:
On Mon, December 17, 2012 22:31, Greg KH wrote:
 On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
 Olav Vitters o...@vitters.nl wrote:
 On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
  As I said in an earlier email, Lennart Poettering claims that it
  does
  not work. We are discussing some of the things necessary to make
  it
 
 work.
 
 Just to repeat:
 In this thread it was claimed that a separate /usr is not
 supported by
 systemd/udev.
 
 A case which works with latest systemd on various distributions. I
 checked with upstream (not Lennart), and they confirmed it works.
 I
 can
 wait for Lennart to say the same, but really not needed.
 
 I assume this will again turn into a but I meant something else.
 
 Olav.
 
 Lennart has stated that he considers a seperate /usr without init*
 broken.
 
 Yes, as do I, and so do a lot of other developers.

It is only broken, because upstream decided to move everything into
/usr
that was previously in /.
   
   No, not at all, please see the web page that describes, in detail, the
   problems that has been going on for quite some time now, with the /usr
   and / partitions and packages.
   
 http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
   
   One good solution to this issue is to move everything into /usr, and
   that's something that has wonderful benifits in the long run, and is
   something that I expect all Linux distros to eventually implement.
   Those that don't, will suffer because of it.
   
   Again, see the web page for why moving stuff into /usr is a good idea
   for the reasons behind this.
   
 
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
  
  Example: /usr Network Share
  When /usr is on a network share, why not add a / on network as well?
  I have multiple systems and as they all have different uses, they all have
  different software installed.
  
  Example: Multiple Guest Operating Systems on the Same Host
  See answer to previous example.
  
  How many environments actually currently exist where a shared /usr is
  being
  used?
 
 Are you aware that these environments are actually one of the most
 important reasons for moving everything to /usr? I don't know what
 hackery you're using to keep the systems in sync and working but it is
 braindead enough.

An init* needs to be kept in sync with the rest of the system as well. As that 
is a compressed filesystem, it takes a lot more effort to keep that in sync in 
comparison to a normal filesystem.
I consider having to write scripts to unpack, modify and repack an init* to be 
more hackery then to keep a bootable root-filesystem working that can mount 
all the filesystems needed for the whole environment.
Anything needed to mount /usr, /var, /run (and any other part needed for the 
boot-process) should not be allowed to depend on anything in any of those 
directories prior to those being mountable.

 The difference between keeping part of the system in rootfs
 and initramfs is that you can discard initramfs after using it. It can
 be anything which is enough to get the /usr mounted and system
 starting. Files on rootfs *have* to be in sync with those on /usr
 or you're getting random failures.

The same is true for an init*.
If an update of part of the OS leads to subtle changes in the filesystem where 
older versions can no longer properly access them, the init* is broken.

--
Joost

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Thursday, December 20, 2012 07:02:06 AM Rich Freeman wrote:
 On Thu, Dec 20, 2012 at 6:21 AM, Richard Yao r...@gentoo.org wrote:
  No one has proposed moving everything to /usr. At the minimum, we would
  still have /etc and /var in /, as well as various mountpoints. If we do
  move those to /usr, then we effectively renamed / to /usr, which is
  pointless. The absurdity of mounting /usr over NFS instead of / is
  precisely why people are saying to just mount / (with /usr as being part
  of it).
 
 We're drifting here, but the concept is that machine-local stuff like
 configuration stays out of /usr, and generic distro stuff stays in
 /usr.
 
 A webserver for site1 vs site2 would be identical in /usr, but
 different elsewhere.

It would be identical everywhere but on:
/etc/apache
/var/www
(using default locations)

I would actually put /var/www on the share as well and use symlinks from 
/etc/apache to point to the specific vhost-config files. That way I could 
quickly move websites to a different node when I'd need to take one down for 
maintenance.

Having only /usr shared betweehn those wouldn't be sufficient and would make 
patching and updates more risky as I would then be updating the whole 
environment at once.

 However, that whole approach makes less sense for a distro that prides
 itself on you being able to make every installation unique.  That
 said, if you do want to make a whole bunch of Gentoo installs the same
 then sticking everything important in /usr and network mounting it is
 a good way to accomplish it.

How does portage handle a situation like this?
Would I be able to use emerge on any node to add additional software along 
with all the config-file changes?

If we take the webserver examples:
The software is under /usr
The configuration is under /etc/apache

If I update apache and there are additional options and/or changes to the 
config files, how do I migrate those to all the different nodes?
If the config is the same on all nodes, why not simply share the  /  ?
If it differs, I then need to write down all the new options and go through 
every single node and update the config there.

The same is true with any other environment where multiple nodes are used for 
the same purpose.

For the usecases that I generally deal with, the only time where a shared /usr 
would make sense is when I select  Install everything  during the install.
I used to do that to avoid having to deal with RPM-dependencies when I was 
using Redhat.

--
Joost

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
 On Fri, 21 Dec 2012 09:10:22 +0100
 
 J. Roeleveld jo...@antarean.org wrote:
  On Thursday, December 20, 2012 09:31:36 AM Michał Górny wrote:
   On Thu, 20 Dec 2012 00:27:26 +0100
   
   J. Roeleveld jo...@antarean.org wrote:
On Wednesday, December 19, 2012 09:13:28 AM Greg KH wrote:
 On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote:
  On Mon, December 17, 2012 22:31, Greg KH wrote:
   On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
   Olav Vitters o...@vitters.nl wrote:
   On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
As I said in an earlier email, Lennart Poettering claims
that it
does
not work. We are discussing some of the things necessary to
make
it
   
   work.
   
   Just to repeat:
   In this thread it was claimed that a separate /usr is not
   supported by
   systemd/udev.
   
   A case which works with latest systemd on various
   distributions. I
   checked with upstream (not Lennart), and they confirmed it
   works.
   I
   can
   wait for Lennart to say the same, but really not needed.
   
   I assume this will again turn into a but I meant something
   else.
   
   Olav.
   
   Lennart has stated that he considers a seperate /usr without
   init*
   broken.
   
   Yes, as do I, and so do a lot of other developers.
  
  It is only broken, because upstream decided to move everything
  into
  /usr
  that was previously in /.
 
 No, not at all, please see the web page that describes, in detail,
 the
 problems that has been going on for quite some time now, with the
 /usr
 and / partitions and packages.
 
   
 http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
 
 One good solution to this issue is to move everything into /usr, and
 that's something that has wonderful benifits in the long run, and is
 something that I expect all Linux distros to eventually implement.
 Those that don't, will suffer because of it.
 
 Again, see the web page for why moving stuff into /usr is a good
 idea
 for the reasons behind this.
  
  http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
  
Example: /usr Network Share
When /usr is on a network share, why not add a / on network as well?
I have multiple systems and as they all have different uses, they all
have
different software installed.

Example: Multiple Guest Operating Systems on the Same Host
See answer to previous example.

How many environments actually currently exist where a shared /usr is
being
used?
   
   Are you aware that these environments are actually one of the most
   important reasons for moving everything to /usr? I don't know what
   hackery you're using to keep the systems in sync and working but it is
   braindead enough.
  
  An init* needs to be kept in sync with the rest of the system as well. As
  that is a compressed filesystem, it takes a lot more effort to keep that
  in sync in comparison to a normal filesystem.
  I consider having to write scripts to unpack, modify and repack an init*
  to be more hackery then to keep a bootable root-filesystem working that
  can mount all the filesystems needed for the whole environment.
  Anything needed to mount /usr, /var, /run (and any other part needed for
  the boot-process) should not be allowed to depend on anything in any of
  those directories prior to those being mountable.
  
   The difference between keeping part of the system in rootfs
   and initramfs is that you can discard initramfs after using it. It can
   be anything which is enough to get the /usr mounted and system
   starting. Files on rootfs *have* to be in sync with those on /usr
   or you're getting random failures.
  
  The same is true for an init*.
  If an update of part of the OS leads to subtle changes in the filesystem
  where older versions can no longer properly access them, the init* is
  broken.
 Just let me know when you have to maintain a lot of such systemd
 and upgrade, say, glibc. Then maybe you'll understand.

A shared /usr means I need to update ALL the systems at once.
When /usr is not shared, I can update groups at a time.

To save time, a shared filesystem containing binary packages can easily be 
used and this is what I use myself.
I have one VM that is used to rebuild the packages when I want to do an update 
and the real host then simply uses the binary packages.
The configuration items needed for emerge are synchronized between the build 
system and the actual server.

The main reason why I would never share an OS filesystem between multiple 
systems is to avoid the situation where a failed upgrade takes down the entire 
environment.
And a shared OS

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Friday, December 21, 2012 12:02:34 PM Michał Górny wrote:
 On Fri, 21 Dec 2012 11:24:45 +0100
 
 J. Roeleveld jo...@antarean.org wrote:
  On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
   Just let me know when you have to maintain a lot of such systemd
   and upgrade, say, glibc. Then maybe you'll understand.
  
  A shared /usr means I need to update ALL the systems at once.
  When /usr is not shared, I can update groups at a time.
 
 Yes, and this is what disqualifies it for the general case. If you
 can't update one at some point, you can't update the others or it is
 going to likely get broken in a random manner.

Yes, but do you want to find out when the entire production environment is 
down? Or would you rather do the upgrades in steps and only risk having to 
rebuild a few nodes and have a lower performance during that time?
There is a big difference between 50% performance and 0%.

  To save time, a shared filesystem containing binary packages can easily be
  used and this is what I use myself.
  I have one VM that is used to rebuild the packages when I want to do an
  update and the real host then simply uses the binary packages.
  The configuration items needed for emerge are synchronized between the
  build system and the actual server.
 
 Wait, wait. So you have introduced even more hackery to get it working?
 Good to hear. That's really a good reason to support your arguments.
 'I got it working with a lot of hackery, so it is a good solution!'

Please explain, what is hackery about having a single host doing all the 
compiling for multiple servers?
The only thing I need to synchronize between the real host and the compile 
host is /etc/portage and /var/lib/portage/world

I don't need any of those to keep the environment running. It's only needed 
during the install/update steps.

  The main reason why I would never share an OS filesystem between multiple
  systems is to avoid the situation where a failed upgrade takes down the
  entire environment.
 
 And this doesn't happen in your case because...? Because as far as I
 can see:
 
 1) failed upgrade in /usr takes down the entire environment,
 
 2) failed upgrade in / may take down the machine,
 
 3) failed hackery you're doing to get it all working may have even more
 unpredictable results.
 
 And yes, I prefer to take down the entire environment and fix it in one
 step. That sounds much better than trying to get it back up and re-sync
 all the machines which got into some mid-broken state.

With shared OS filesystems, that is what you will get.
With non-shared OS filesystems, the other nodes will keep working.

  And a shared OS filesystem also introduces a very nice Single Point of
  Failure. What will happen when the NFS-server (or whatever is used) goes
  down for whatever reason?
 
 And what is the difference now? Is it another argument like 'hey, i can
 still see the command-line, so it's better. not that i can do anything
 useful with it.'

Actually, with a shared OS-filesystem:
When it goes down: Oops, we lost the entire environment

With non-shared:
One node goes down: Oops, we need to fix this node, performance will be down 
while we fix this
Or this and that app won't work, but the rest still does

That's the difference between a major outage impacting the entire company or 
one that only affects a few departments.

  In other words, to make an environment that has a very nice single point
  of
  failure possible, existing working environments are classed as broken.
 
 NFS-shared system does classify as 'a single point of failure'.

If a single shared filesystem is necessary to be able to use the entire 
environment, then yes.

--
Joost

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Friday, December 21, 2012 12:42:23 PM Michał Górny wrote:
 On Fri, 21 Dec 2012 12:31:28 +0100
 
 J. Roeleveld jo...@antarean.org wrote:
  On Friday, December 21, 2012 12:02:34 PM Michał Górny wrote:
   On Fri, 21 Dec 2012 11:24:45 +0100
   
   J. Roeleveld jo...@antarean.org wrote:
On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
 Just let me know when you have to maintain a lot of such systemd
 and upgrade, say, glibc. Then maybe you'll understand.

A shared /usr means I need to update ALL the systems at once.
When /usr is not shared, I can update groups at a time.
   
   Yes, and this is what disqualifies it for the general case. If you
   can't update one at some point, you can't update the others or it is
   going to likely get broken in a random manner.
  
  Yes, but do you want to find out when the entire production environment is
  down? Or would you rather do the upgrades in steps and only risk having to
  rebuild a few nodes and have a lower performance during that time?
  There is a big difference between 50% performance and 0%.
 
 Didn't you just state that you *have* to update all at the same time?

Please re-read what I wrote.
I said, with a *shared* /usr, then yes, I do need to update the entire 
environment at the same time.
With a *non-shared*, this is not necessary.

I also stated that that is one of the reasons why I do not *want* to share 
/usr between multiple hosts.

To save time, a shared filesystem containing binary packages can
easily be
used and this is what I use myself.
I have one VM that is used to rebuild the packages when I want to do
an
update and the real host then simply uses the binary packages.
The configuration items needed for emerge are synchronized between the
build system and the actual server.
   
   Wait, wait. So you have introduced even more hackery to get it working?
   Good to hear. That's really a good reason to support your arguments.
   'I got it working with a lot of hackery, so it is a good solution!'
  
  Please explain, what is hackery about having a single host doing all the
  compiling for multiple servers?
  The only thing I need to synchronize between the real host and the
  compile host is /etc/portage and /var/lib/portage/world
 
 The hackery is about installing packages partially to local
 and partially to shared location. I feel like I'm not following anymore
 what actually happens there, not that it is worth my time.

That type of hackery is what I do *not* do. Please see above.

The main reason why I would never share an OS filesystem between
multiple
systems is to avoid the situation where a failed upgrade takes down
the
entire environment.
   
   And this doesn't happen in your case because...? Because as far as I
   can see:
   
   1) failed upgrade in /usr takes down the entire environment,
   
   2) failed upgrade in / may take down the machine,
   
   3) failed hackery you're doing to get it all working may have even more
   unpredictable results.
   
   And yes, I prefer to take down the entire environment and fix it in one
   step. That sounds much better than trying to get it back up and re-sync
   all the machines which got into some mid-broken state.
  
  With shared OS filesystems, that is what you will get.
  With non-shared OS filesystems, the other nodes will keep working.
 
 Aren't we talking about shared OS filesystems *right now*?

Yes, as a reason why *not* to do it.

I don't ever intend to use a shared OS filesystem. That includes not sharing 
/usr because of the reasons I mentioned.

The main reason mentioned for moving everything and the kitchen sink into /usr 
is to make it easier to share /usr between multiple servers.
Doing that has the side-effect that a seperate /usr will not work without an 
init*.

This makes me conclude that a decision has been made to:
Break existing working environments to support an environment that has a 
built-in single point of failure.

--
Joost

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Friday, December 21, 2012 08:51:09 AM Ian Stakenvicius wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 21/12/12 03:10 AM, J. Roeleveld wrote:
  An init* needs to be kept in sync with the rest of the system as
  well.
 
 Just to be clear, by init* you mean {initrd,initramfs} , correct?

Yes

On the Gentoo-user mailing list, that's one of the two common ways of 
referring to it. The other one is  init-thingy . ;)

--
Joost

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Friday, December 21, 2012 08:52:00 AM Dale wrote:
 J. Roeleveld wrote:
  On Friday, December 21, 2012 08:51:09 AM Ian Stakenvicius wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
  
  On 21/12/12 03:10 AM, J. Roeleveld wrote:
  An init* needs to be kept in sync with the rest of the system as
  well.
  
  Just to be clear, by init* you mean {initrd,initramfs} , correct?
  
  Yes
  
  On the Gentoo-user mailing list, that's one of the two common ways of
  referring to it. The other one is  init-thingy . ;)
  
  --
  Joost
 
 I plead guilty on starting this one.  It was I.  Joost, point your
 fingers at me.  It's OK.

Dale, you may have invented the word  init-thingy , but others have started 
to copy it :)

--
Joost

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Friday, December 21, 2012 09:38:36 AM Rich Freeman wrote:
 On Fri, Dec 21, 2012 at 8:51 AM, Ian Stakenvicius a...@gentoo.org wrote:
  On 21/12/12 03:10 AM, J. Roeleveld wrote:
  An init* needs to be kept in sync with the rest of the system as
  well.
  
  Just to be clear, by init* you mean {initrd,initramfs} , correct?
 
 Seems likely.
 
 However, for the most part it really only needs to be kept in sync
 with the kernel.  Smarter ones like dracut that might do things like
 keep a copy of mdadm.conf internally might need to be updated when
 your disks change, and so on.  In general, however, they only need
 changes when either your kernel changes, or the path to the root
 filesystem changes (by path I mean mdadm/lvm/nfs/etc).

And with the move to /usr, also when that changes.
Granted, on most systems it won't actually move often once it's installed.

 Everything inside the initramfs is self-contained and does not have
 dependencies on anything outside.  Sure, it might not have the latest
 version of udev inside or whatever, but unless you need the latest
 version of udev to mount root it isn't a problem.  The contents of the
 initramfs are generally discarded once root and /usr are mounted.

True, but what if a system has been updated and the structure of the system 
has been changed. This makes the init* (what is the preferred way of naming 
this?) no longer able to boot properly.

 However, I can vouch that an initramfs can make things interesting if
 you do move your root filesystem.  I just moved mine to lvm and forgot
 to update fstab.sys.  Dracut does pay attention to your root
 filesystem in fstab and fstab.sys - it uses the kernel line to find
 root, but once it is mounted fstab gets read and used to remount it.
 Oh, and if fstab and fstab.sys have differing root lines both get
 sort-of-mounted (it mounts what is in fstab, and then mounts fstab.sys
 over it as far as I can tell - running mount and finding that you have
 /sysroot mounted on a mountpoint that you can't even get to is fun).

Why are there 2 fstab-files? That, to me, looks like a likely cause for 
problems.
I haven't tried dracut yet, but have tried  genkernel  to generate the init* 
and it does work. However it does increase the complexity and adds a layer 
that is not easily debugged.
I am looking forward to when eudev is released and supports my environment so 
I can get rid of it.

The creation of init*-files is not clearly documented and the tools available 
want to put user-space tools inside it.

 But, I wouldn't be running root on lvm but for the initramfs, so it
 was worth the trouble.  Anybody who moves around root without a boot
 CD handy is asking for trouble anyway.

Agreed, I would do that move from inside a rescue-environment myself, not on a 
live system :)

--
Joost

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

Stelian Ionescu sione...@cddr.org wrote:

On Fri, 2012-12-21 at 12:48 +0100, J. Roeleveld wrote:
 On Friday, December 21, 2012 12:42:23 PM Michał Górny wrote:
  On Fri, 21 Dec 2012 12:31:28 +0100
  
  J. Roeleveld jo...@antarean.org wrote:
   On Friday, December 21, 2012 12:02:34 PM Michał Górny wrote:
On Fri, 21 Dec 2012 11:24:45 +0100

J. Roeleveld jo...@antarean.org wrote:
 On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote:
  Just let me know when you have to maintain a lot of such
systemd
  and upgrade, say, glibc. Then maybe you'll understand.
 
 A shared /usr means I need to update ALL the systems at once.
 When /usr is not shared, I can update groups at a time.

Yes, and this is what disqualifies it for the general case. If
you
can't update one at some point, you can't update the others or
it is
going to likely get broken in a random manner.
   
   Yes, but do you want to find out when the entire production
environment is
   down? Or would you rather do the upgrades in steps and only risk
having to
   rebuild a few nodes and have a lower performance during that
time?
   There is a big difference between 50% performance and 0%.
  
  Didn't you just state that you *have* to update all at the same
time?
 
 Please re-read what I wrote.
 I said, with a *shared* /usr, then yes, I do need to update the
entire 
 environment at the same time.

That's not true.

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib

How would you update a subset of servers when they all share the same /usr?

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

Dale rdalek1...@gmail.com wrote:

J. Roeleveld wrote:
 However, it is, in my opinion, a workaround for a problem that has
 been forced upon me. As soon as eudev is stable enough, I will dump
udev.
 [1] https://bugs.gentoo.org/441004
 Strange, I use a current-stable version of genkernel, /usr is on LVM
and the 
 system boots correctly without issues.

 --
 Joost



Same here.  I have /usr on LVM and plan to use eudev as SOON as it is
ready.  I'm just waiting on someone to post that it is as easy as
unmerging udev and emerging eudev and maybe a reboot. 

Dale

:-)  :-) 

As soon as the developers post it is ready for testing I will start testing it 
on a few test VMs. If that works I will move it to my desktop.
When that also goes fine. I'll post about it on gentoo-user.

--
Joost
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Friday, December 21, 2012 12:20:45 PM William Hubbs wrote:
 On Fri, Dec 21, 2012 at 06:36:05PM +0100, J. Roeleveld wrote:
  On Friday, December 21, 2012 10:21:02 AM William Hubbs wrote:
   On Fri, Dec 21, 2012 at 04:04:31PM +0100, J. Roeleveld wrote:
On Friday, December 21, 2012 09:38:36 AM Rich Freeman wrote:
 On Fri, Dec 21, 2012 at 8:51 AM, Ian Stakenvicius a...@gentoo.org
  
  wrote:
  On 21/12/12 03:10 AM, J. Roeleveld wrote:
  An init* needs to be kept in sync with the rest of the system as
  well.
  
  Just to be clear, by init* you mean {initrd,initramfs} ,
  correct?
 
 Seems likely.
 
 However, for the most part it really only needs to be kept in sync
 with the kernel.  Smarter ones like dracut that might do things like
 keep a copy of mdadm.conf internally might need to be updated when
 your disks change, and so on.  In general, however, they only need
 changes when either your kernel changes, or the path to the root
 filesystem changes (by path I mean mdadm/lvm/nfs/etc).

And with the move to /usr, also when that changes.
Granted, on most systems it won't actually move often once it's
installed.
   
   Can you be more specific here? I do not understand what you mean.
 
 The /usr merge doesn't break an init*, so I don't know how you are seeing
 them as related.

Who are you replying to here?
I never said that moving everything into /usr will break an init*.

--
Joost

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Wednesday, December 19, 2012 09:13:28 AM Greg KH wrote:
 On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote:
  On Mon, December 17, 2012 22:31, Greg KH wrote:
   On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
   Olav Vitters o...@vitters.nl wrote:
   On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
As I said in an earlier email, Lennart Poettering claims that it
does
not work. We are discussing some of the things necessary to make it
   
   work.
   
   Just to repeat:
   In this thread it was claimed that a separate /usr is not supported by
   systemd/udev.
   
   A case which works with latest systemd on various distributions. I
   checked with upstream (not Lennart), and they confirmed it works. I
   can
   wait for Lennart to say the same, but really not needed.
   
   I assume this will again turn into a but I meant something else.
   
   Olav.
   
   Lennart has stated that he considers a seperate /usr without init*
   broken.
   
   Yes, as do I, and so do a lot of other developers.
  
  It is only broken, because upstream decided to move everything into /usr
  that was previously in /.
 
 No, not at all, please see the web page that describes, in detail, the
 problems that has been going on for quite some time now, with the /usr
 and / partitions and packages.
   http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
 
 One good solution to this issue is to move everything into /usr, and
 that's something that has wonderful benifits in the long run, and is
 something that I expect all Linux distros to eventually implement.
 Those that don't, will suffer because of it.
 
 Again, see the web page for why moving stuff into /usr is a good idea
 for the reasons behind this.
   http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

Example: /usr Network Share
When /usr is on a network share, why not add a / on network as well?
I have multiple systems and as they all have different uses, they all have 
different software installed.

Example: Multiple Guest Operating Systems on the Same Host
See answer to previous example.

How many environments actually currently exist where a shared /usr is being 
used?

   This has worked correctly in the past.
   
   Define past please.
  
  Recent past, like a few months ago no errors during boot and the system
  running stable.
 
 You have gotten lucky, see the above links for why.

ALSA, LVM and HPLIP work perfectly with /usr on LVM without an initramfs.
I have sound, the LVM partitions are detected and mounted correctly and I can 
use the full functionality of any HP printer I get access to.
Those three are listed as being broken.
 
  Please provide a simple way to let me see that it is broken on systems
  that do not use bluetooth keyboards.
 
 Again, see the above link for how to do this.

See above, 3 items that I use daily (apart from hplip, don't need printing and 
scanner daily) are listed as broken, but work without error.
In what way should they be broken and how can I find out?

  The requirement of having userspace working to have input devices working
  seems to be related to bluetooth, not to USB or PS/2 keyboards.
 
 Not at all, see the above link.

Ok, a few other devices are mentioned, the only one I need to mount /usr in 
that list is LVM, which starts correctly already.

  And using a bluetooth connection to access a NFS share is, in my humble
  opinion, a corner case that requires additional work to make it work.
 
 One person's corner case is another person's default operating mode.

Yes, but the corner case I just mentioned is one that won't work without a 
init*. My use-case has been stable for years.

   Note, it's still broken, I have yet to see any upstream fixes to resolve
   all of the issues that are involved here with fixing this up.
  
  Reverting back to an older version makes it work.
 
 Because of how we package udev?

If it's packaging, then why are we having this discussion and do we need a 
fork to fix udev?

  Using mdev also works.
 
 mdev is not recommended for desktop or server systems, but feel free to
 use it if you want.

I might not be recommended, but it does proof that a seperate /usr is not 
broken. The way udev doesn't handle it is.

   Yes, as always, for some subset of users, you can be lucky and it will
   work for them, but those systems are getting rarer and rarer these days,
   as the rest of upstream (not systemd here) are moving on and not doing
   anything to change their behavior for this topic.
  
  Why rarer? Any system I can buy in a random shop will work using a
  seperate /usr, provided the software is installed sanely.
 
 Again, see above for why this is not true.

Only because udev-upstream declares such systems broken.

  By moving everything into /usr, this brokenness is forced upon users.
 
 Not at all, but that's a separate topic than what we are talking about
 here.

True, but that move is done by the same

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

Olav Vitters o...@vitters.nl wrote:

On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
 As I said in an earlier email, Lennart Poettering claims that it does
 not work. We are discussing some of the things necessary to make it
work.

Just to repeat:
In this thread it was claimed that a separate /usr is not supported by
systemd/udev.

A case which works with latest systemd on various distributions. I
checked with upstream (not Lennart), and they confirmed it works. I can
wait for Lennart to say the same, but really not needed.

I assume this will again turn into a but I meant something else.

Olav.

Lennart has stated that he considers a seperate /usr without init* broken.
This has worked correctly in the past.

The direction udev development is going, according to Lennart, is to make that 
impossible and he refuses to fix this regression.

I am really happy with this project and intend on testing it once requests for 
this appear in the eudev mailing list.

--
Joost Roeleveld
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [gentoo-dev] Re: eudev project announcement

[J. Roeleveld]

On Mon, December 17, 2012 22:31, Greg KH wrote:
 On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
 Olav Vitters o...@vitters.nl wrote:

 On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
  As I said in an earlier email, Lennart Poettering claims that it does
  not work. We are discussing some of the things necessary to make it
 work.
 
 Just to repeat:
 In this thread it was claimed that a separate /usr is not supported by
 systemd/udev.
 
 A case which works with latest systemd on various distributions. I
 checked with upstream (not Lennart), and they confirmed it works. I can
 wait for Lennart to say the same, but really not needed.
 
 I assume this will again turn into a but I meant something else.

 Olav.

 Lennart has stated that he considers a seperate /usr without init*
 broken.

 Yes, as do I, and so do a lot of other developers.

It is only broken, because upstream decided to move everything into /usr
that was previously in /.

 But that is a system configuration issue, not a systemd issue, please
 don't confuse the two.

systemd does some interesting things, but I prefer those in a seperate
proces, not in PID-1. But that is a different discussion.

 This has worked correctly in the past.

 Define past please.

Recent past, like a few months ago no errors during boot and the system
running stable.
Please provide a simple way to let me see that it is broken on systems
that do not use bluetooth keyboards.
The requirement of having userspace working to have input devices working
seems to be related to bluetooth, not to USB or PS/2 keyboards.

And using a bluetooth connection to access a NFS share is, in my humble
opinion, a corner case that requires additional work to make it work.

 Note, it's still broken, I have yet to see any upstream fixes to resolve
 all of the issues that are involved here with fixing this up.

Reverting back to an older version makes it work.
Using mdev also works.

 Yes, as always, for some subset of users, you can be lucky and it will
 work for them, but those systems are getting rarer and rarer these days,
 as the rest of upstream (not systemd here) are moving on and not doing
 anything to change their behavior for this topic.

Why rarer? Any system I can buy in a random shop will work using a
seperate /usr, provided the software is installed sanely.
By moving everything into /usr, this brokenness is forced upon users.

 The direction udev development is going, according to Lennart, is to
 make that impossible and he refuses to fix this regression.

 Again, this has NOTHING to do with udev or systemd, as has been pointed
 out numerous times.  I understand your _wish_ that it would have
 something to do with it, but that will not change the facts, sorry.

Then what does it have to do with?
When it was made public that it is considered broken, the news came from
udev-upstream. This was before most systems encountered any breakage.

 I am really happy with this project and intend on testing it once
 requests for this appear in the eudev mailing list.

 Good luck, the root problems still remain, and nothing that eudev ever
 does can resolve that, sorry.

 Can this topic finally be put to rest please?  There is a whole web page
 devoted to this topic, why do people blindly ignore it?

Where is this page?
I've read the page written by Lennart. Is there a decent (as in, going
into detail why it is broken and what it is caused by) analysis about the
problem?

 Again, a separate /usr without an initrd has NOTHING to do with systemd
 or udev, with the minor exception that Gentoo's packaging of those
 programs _might_ have an issue, but that is Gentoo's issue, NOT
 upstream's issue.

 If anyone involved with eudev, or is involved with the Gentoo Council
 thinks that the previous paragraph is incorrect, they are flat out
 wrong.

I have yet to hear about a clear explanation why a seperate /usr is broken
apart from the use of bluetooth keyboards. (Which are still in the
minority when I check local shops/webstores)

--
Joost