Re: [gentoo-dev] rfc: using /libexec

[Nathan Phillip Brink]

On Wed, Sep 07, 2011 at 05:31:23PM -0400, Joshua Kinard wrote:
> Are there possibilities about breaking off just a small piece of openrc and
> putting that into /run (or /boot)?  Enough of the core scripts so that it
> can find /usr and mount it before continuing?

Isn't /run something that's supposed to be mounted with tmpfs
eventually? Currently /var/run's job is to hold volatile
data... Unless if I've missed something, I'm confused about why it
makes sense to install scripts or binaries there.

-- 
binki

Look out for missing or extraneous apostrophes!


pgpXx3dw6xtwx.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: using /libexec

[Robin H. Johnson]

On Wed, Sep 07, 2011 at 08:35:46PM -0400, Rich Freeman wrote:
> On Wed, Sep 7, 2011 at 5:31 PM, Joshua Kinard  wrote:
> > Never once have I had any issues
> > with separate / and /usr, and none of them use an initramfs.
> Ditto here, but that doesn't mean that problems don't exist.  Right now the
> problems are likely to be subtle, perhaps arising only with certain
> combinations of hardware/etc.  Maybe if you had a bluetooth keyboard or
> something it might not work, or maybe if /usr were mounted on a bluetooth
> hard drive or something (do they even make those?).
Bluetooth keyboard wanted during early boot (to put in the root password
for a fsck repair after a hard shutdown) is one that bit me already.

> > As far as initramfs, is this something that would need to go into the
> > kernel?
> Well, the kernel comes with code for making an initramfs, but most likely it
> would be implemented in a separate package.  The initramfs isn't part of the
> kernel - it is loaded by grub at boot time and its address is passed to the
> kernel.  So, the file needs to be on /boot.
That's not always true, see further down.

> I also netboot some of my systems, and they have limits on the total
> > size of the kernel image (7.2MB on one, ~40MB on another, etc), hence the
> > need to keep this small or find another way to do things.
> I think that pxelinux supports initramfs - I know it supports initrd at
> least and I don't think it makes any difference at the bootloader level.  In
> fact, things like network booting are one of the drivers behind the Fedora
> project to have dracut mount /usr.  Their plan is to just move everything
> into /usr, allow it to be NFS-mounted, and then with one mountpoint
> everything the system needs is available.  Eventually in Fedora /lib and
> /bin will just be symlinks into /usr.  That will work fine as long as dracut
> mounts /usr.
That's not quite as easy for Kumba... Some of the MIPS bootloaders are
very limited. At least one of them requires that the initramfs be built
INTO the kernel.

> 
> Are there possibilities about breaking off just a small piece of openrc and
> > putting that into /run (or /boot)?  Enough of the core scripts so that it
> > can find /usr and mount it before continuing?
> Well, it certainly could be done, but it doesn't seem to be the direction
> anybody else is going.  Instead the plan is to just create a very minimal
> initramfs that gets the job done. 
That's pretty much the only stuff in WilliamH's prototype. Just enough
to get /usr mounted (/run comes for almost free at that point basically,
it's just mounting tmpfs on /newroot/run/).

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] rfc: using /libexec

[Rich Freeman]

On Wed, Sep 7, 2011 at 5:31 PM, Joshua Kinard  wrote:

> Never once have I had any issues
> with separate / and /usr, and none of them use an initramfs.


Ditto here, but that doesn't mean that problems don't exist.  Right now the
problems are likely to be subtle, perhaps arising only with certain
combinations of hardware/etc.  Maybe if you had a bluetooth keyboard or
something it might not work, or maybe if /usr were mounted on a bluetooth
hard drive or something (do they even make those?).

However, long-term it seems likely that the problems will continue to grow,
as more and more upstream packages move away from supporting a /usr that
isn't available at boot.

My general suggestion has been to hold the line where it is until we have
better support for mount /usr in initramfs, and it sounds like this is well
underway.


> As far as initramfs, is this something that would need to go into the
> kernel?


Well, the kernel comes with code for making an initramfs, but most likely it
would be implemented in a separate package.  The initramfs isn't part of the
kernel - it is loaded by grub at boot time and its address is passed to the
kernel.  So, the file needs to be on /boot.

I also netboot some of my systems, and they have limits on the total
> size of the kernel image (7.2MB on one, ~40MB on another, etc), hence the
> need to keep this small or find another way to do things.
>

I think that pxelinux supports initramfs - I know it supports initrd at
least and I don't think it makes any difference at the bootloader level.  In
fact, things like network booting are one of the drivers behind the Fedora
project to have dracut mount /usr.  Their plan is to just move everything
into /usr, allow it to be NFS-mounted, and then with one mountpoint
everything the system needs is available.  Eventually in Fedora /lib and
/bin will just be symlinks into /usr.  That will work fine as long as dracut
mounts /usr.

Are there possibilities about breaking off just a small piece of openrc and
> putting that into /run (or /boot)?  Enough of the core scripts so that it
> can find /usr and mount it before continuing?
>
>
Well, it certainly could be done, but it doesn't seem to be the direction
anybody else is going.  Instead the plan is to just create a very minimal
initramfs that gets the job done.  Using it would just be a matter of
installing the file and editing the boot line to load it.  Or, you can use
something like dracut or genkernel and get a more robust one.

Disclaimer - I'm not speaking for anybody but myself here...

Rich

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Brian Harring]

On Wed, Sep 07, 2011 at 11:53:50PM +0100, Ciaran McCreesh wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Wed, 07 Sep 2011 18:47:17 -0400
> "Aaron W. Swenson"  wrote:
> > I second the allowing dots in USE flag names. Definitely would be
> > helpful for declaring version related USE flags.
> 
> You know you won't be able to mention such flags in the base profile,
> right? At least not for a year or more, until the base profile's eapi
> can be set to something other than 0.

use.desc and use.local.desc don't have EAPI versioning either; as such 
they're eapi=0 till versioning is introduced (and then wait till the 
support is deployed far enough to avoid breaking people).

Meaning, just the same as I said on this bug... this isn't viable, and 
frankly it's not really a deal breaker lacking it.  It can be worked 
around.

If folks want it, they're going to need to sort out all of the 
backward compatibility issues *prior* to trying to shove it into eapi.

~harring

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ciaran McCreesh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 07 Sep 2011 18:47:17 -0400
"Aaron W. Swenson"  wrote:
> I second the allowing dots in USE flag names. Definitely would be
> helpful for declaring version related USE flags.

You know you won't be able to mention such flags in the base profile,
right? At least not for a year or more, until the base profile's eapi
can be set to something other than 0.

- -- 
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk5n9f4ACgkQ96zL6DUtXhFtdQCfY5bc8r9E0HAGYFxcI/5ozEjb
5c0AoJjY9BhzCNiWty3i1jHZm13CbNGz
=cymm
-END PGP SIGNATURE-

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Aaron W. Swenson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/07/2011 11:48 AM, Michał Górny wrote:
> On Wed, 7 Sep 2011 11:07:21 +0200 Tomáš Chvátal
>  wrote:
> 
>> Start collecting ideas for EAPI5.
> 
> I'd highlight the following bugs:
> 
> 311795 - [Future EAPI] Allow dots in USE flag names 373377 -
> [Future EAPI] Remove IMAGE (deprecated already)
> 
I second the allowing dots in USE flag names. Definitely would be
helpful for declaring version related USE flags.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk5n9HUACgkQCOhwUhu5AEk+RQEAomdG51DXzVT3CSRjGGVtoRNI
GFfmapur0VavmIj8jHIA/2sDQBbaTKKDYx4TVfQ5p2eRnw4PaSMsLnHKUgSC0HJl
=kAaj
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: using /libexec

[Joshua Kinard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/07/2011 05:27, Michał Górny wrote:

> On Wed, 07 Sep 2011 12:17:21 +0300 Alexey Shvetsov 

> wrote:

> 

>> Moving things as openrc to /usr/libexec will effectevely barake old 

>> systems with separtae / and /usr. So it isnt good idea

> 

> Old systems should migrate to initramfs, like it was already pointed out

> before. Breakage is already there, you just don't notice it.

> 








I've used a separate /usr on every system I've ever built on Gentoo, and
some have filesystems going back years.  Never once have I had any issues
with separate / and /usr, and none of them use an initramfs.  Our own
security guide has made this recommendation for as long as I can remember
(so one can mark /usr as read-only on production setups, for example).

As far as initramfs, is this something that would need to go into the
kernel?  I hand-build all of my kernels, so any such initramfs package might
be better off as a standalone package available on the FS at kernel build
time.  I also netboot some of my systems, and they have limits on the total
size of the kernel image (7.2MB on one, ~40MB on another, etc), hence the
need to keep this small or find another way to do things.

Are there possibilities about breaking off just a small piece of openrc and
putting that into /run (or /boot)?  Enough of the core scripts so that it
can find /usr and mount it before continuing?


- -- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

- --Emperor Turhan, Centauri Republic
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQIcBAEBAgAGBQJOZ+KrAAoJENsjoH7SXZXjagYP/A9eGlVOw8e0+uZFz7RMo3wD
VYP4/oeQ3WMg7MdFX6YH9fbItyifG4szML1k1gIzh3woZrt9l6GWV7Jd0MM9jd9D
s26pSe3OhoKTdDImFwSQfQmwX9K6kiDa8K9x/Tj9bD9Z+/513VhpQgN/VH70UarX
LW/aoeLFwXx6ppU6WXj2u15e7H/3vkYRMYI+jDKrRxWXybT/IMM55B8mBgpum6dc
6cMNtBy751hYzk4ibszBUuezkbOh+yx/GUFksuBP/1J3u1Vvre7ejH184zvWveMS
ZBQtxsaAFz6/fhhhV9QqKy0bQq7V6oTK4QE6DC+BpkhBPkuR2kJ01PyDzZcqr9Lg
luSBJMSxpntbfm68P/HH7aQU3VeomSfucBjWcFRAJExd+EFQSLk7Z2s7ijkv2YHk
RvMypR8ARxumSj3vQE2XhG9c9GxZWMXF+3X9J7BGqdfBFCJjgOa4sYLnwsAMTtcq
jtJHW/dJ+SsJw7wAUeNRZsg+moMCLWknvbgPhd6dcSY36P6TytMMBw4NPbPTs96l
wC0zAX6Dk0/rCcm6H0U8FUJw/9MjAgnGG1Jo54ed11e+ePWzTuvLIs4b3OICN0TL
Uxr67jsIz5r14JlyaBL0rNCQVMFvjrxO4lhKI62xvLFX334a7uimKReJZIHXOjdt
CfygZB6C4kK8hPPbgks1
=Y0sh
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: using /libexec

[Rich Freeman]

On Wed, Sep 7, 2011 at 2:02 PM, Robin H. Johnson  wrote:

> On Wed, Sep 07, 2011 at 07:22:46AM -0400, Rich Freeman wrote:
> > Right now migrating to initramfs won't do any good, as Gentoo doesn't
> have
> > an initramfs available which mounts /usr.  No doubt once Fedora gets
> theirs
> > working we'll be able to copy it (assuming it is FOSS), or we can write
> our
> > own.
> The options for this are looking like:
> - static initramfs that I proposed (WilliamH has an early prototype)
> - genkernel
> - dracut
>
> WilliamH's prototype seems to mostly work, I just want to polish it some
> and then release it. I think we can offer it as an easy default to
> users, since it doesn't need to be rebuilt when the kernel is rebuilt at
> all.
>
>
Agreed on all the comments along these lines.  I just wanted to suggest that
we not let the effort of breaking separate /usr get out too far ahead of the
effort to un-break it.  :)  As we can see from the openrc/handbook situation
it is easy to let the docs get out of sync (not pointing fingers here -
coordination is just an issue anytime you have many hands).

Rich

Re: [gentoo-dev] rfc: using /libexec

[Amadeusz Żołnowski]

Excerpts from Robin H. Johnson's message of 2011-09-07 20:02:57 +0200:
> On Wed, Sep 07, 2011 at 07:22:46AM -0400, Rich Freeman wrote:
> > Right now migrating to initramfs won't do any good, as Gentoo
> > doesn't have an initramfs available which mounts /usr.  No doubt
> > once Fedora gets theirs working we'll be able to copy it (assuming
> > it is FOSS), or we can write our own.
> The options for this are looking like:
> - static initramfs that I proposed (WilliamH has an early prototype)
> - genkernel
> - dracut
> 
> WilliamH's prototype seems to mostly work, I just want to polish it
> some and then release it. I think we can offer it as an easy default
> to users, since it doesn't need to be rebuilt when the kernel is
> rebuilt at all.

Dracut doesn't need either if we skip to include kernel modules.


-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: using /libexec

[William Hubbs]

On Wed, Sep 07, 2011 at 07:22:46AM -0400, Rich Freeman wrote:
> On Wed, Sep 7, 2011 at 5:27 AM, Michał Górny  wrote:
> 
> > On Wed, 07 Sep 2011 12:17:21 +0300
> > Alexey Shvetsov  wrote:
> >
> > > Moving things as openrc to /usr/libexec will effectevely barake old
> > > systems with separtae / and /usr. So it isnt good idea
> >
> > Old systems should migrate to initramfs, like it was already pointed
> > out before. Breakage is already there, you just don't notice it.
> >
> >
> Agreed, and once the official docs are updated and a working initramfs is
> available we can consider moving forward with things that break separate
> /usr.  That seemed to be the general consensus on the other thread.
> 
> Right now migrating to initramfs won't do any good, as Gentoo doesn't have
> an initramfs available which mounts /usr.  No doubt once Fedora gets theirs
> working we'll be able to copy it (assuming it is FOSS), or we can write our
> own.

I actually have a skeleton for an initramfs that does this here, I just
haven't figured out the last step, making an ebuild for it.

I think we can do a very simple initramfs that just mounts /usr/and /var
without dracut, but if you are using lvm, etc, you will have to use
dracut.

William


pgpWDbzbsz0Bd.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: using /libexec

[Robin H. Johnson]

On Wed, Sep 07, 2011 at 07:22:46AM -0400, Rich Freeman wrote:
> Right now migrating to initramfs won't do any good, as Gentoo doesn't have
> an initramfs available which mounts /usr.  No doubt once Fedora gets theirs
> working we'll be able to copy it (assuming it is FOSS), or we can write our
> own.
The options for this are looking like:
- static initramfs that I proposed (WilliamH has an early prototype)
- genkernel
- dracut

WilliamH's prototype seems to mostly work, I just want to polish it some
and then release it. I think we can offer it as an easy default to
users, since it doesn't need to be rebuilt when the kernel is rebuilt at
all.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ciaran McCreesh]

On Wed, 7 Sep 2011 11:07:21 +0200
Tomáš Chvátal  wrote:
> Start collecting ideas for EAPI5.

http://archives.gentoo.org/gentoo-pms/msg_dfef93f8d6bc6684d4dc9793563b4fdf.xml

was my list. There are also various bits of lousy wording in PMS that
I'd like to get cleared up over an EAPI (such as what exactly a self
block does).

The problem is, we can't get a reliable answer to "can this be
implemented in Portage quickly?"...

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature

Re: [gentoo-dev] Autodep project

[Alexander Bersenev]

I already have depcheck and depcheckstrict FEATURES. Emerge_strict script 
launch modified version of emerge enabling depcheckstrict feature.

I have a 0.2 version of this utility with some bugs fixed, I testing it now.

I plan to move this package into main tree and I am going to talk about 
integration of this patch into portage but I think some things must be changed 
in it before.

Best,

Alexander Bersenev

On 07.09.2011, at 15:08, Tomáš Chvátal  wrote:

> Hi,
> really cool thing you create :)
> 
> Would it be possible to move that package to main tree, and merge
> or possibly add new FEATURES option to portage like "autobuildchecks" that
> would be set by -dev profile?
> 
> Cheers
> Tom
> 

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Michał Górny]

On Wed, 7 Sep 2011 11:07:21 +0200
Tomáš Chvátal  wrote:

> Start collecting ideas for EAPI5.

I'd highlight the following bugs:

311795 - [Future EAPI] Allow dots in USE flag names
373377 - [Future EAPI] Remove IMAGE (deprecated already)

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Michał Górny]

On Wed, 7 Sep 2011 16:27:01 +0200
Tomáš Chvátal  wrote:

> Well the patches code is in base eclass.

Then you should first consider moving epatch to PMS. I'd honestly
prefer going the other way.

> For Recommended it works like this:
> blabla.spec
> Recommended: xf86-video-ati
> 
> zypper in blabla
> ...
> You might consider installing these additional packages:
>  xf86-video-ati
> 
> 
> It for sure needs more thinking as this is just basic idea. It might
> even take into account that if you install the recommended patckage
> with oneshot it should not be depcleaned unless all recommending
> packages are gone too, and so on.

It had some thinking, and ended up in no agreement. There's really no
reason to hack up the spec to replace one hack with another.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Tomáš Chvátal]

2011/9/7 Ulrich Mueller :
>> On Wed, 7 Sep 2011, Tomáš Chvátal wrote:
>
>> Start collecting ideas for EAPI5.
>
> I suggest that EAPI 5 should include the two features that have been
> omitted from EAPI 4 [1,2].
>
> Apart from this, I think we should be more careful for the next EAPI,
> in order to avoid such long delays as we had with EAPI 4. One possible
> solution would be to only accept features where a preliminary
> implementation in Portage is available.
Agreed the wait last time was really bad.
>
>> I myself would like PATCHES array to be default in src_prepare phase
>> and some solution for runtime optional deps, Instead of elog in
>> postinst something like Recommended from rpm.
>
> Looks reasonable (if an implementation is ready). Although I don't
> understand how it is related to rpm.

Well the patches code is in base eclass.

For Recommended it works like this:
blabla.spec
Recommended: xf86-video-ati

zypper in blabla
...
You might consider installing these additional packages:
 xf86-video-ati


It for sure needs more thinking as this is just basic idea. It might
even take into account that if you install the recommended patckage
with oneshot it should not be depcleaned unless all recommending
packages are gone too, and so on.

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Ulrich Mueller]

> On Wed, 7 Sep 2011, Tomáš Chvátal wrote:

> Start collecting ideas for EAPI5.

I suggest that EAPI 5 should include the two features that have been
omitted from EAPI 4 [1,2].

Apart from this, I think we should be more careful for the next EAPI,
in order to avoid such long delays as we had with EAPI 4. One possible
solution would be to only accept features where a preliminary
implementation in Portage is available.

> I myself would like PATCHES array to be default in src_prepare phase
> and some solution for runtime optional deps, Instead of elog in
> postinst something like Recommended from rpm.

Looks reasonable (if an implementation is ready). Although I don't
understand how it is related to rpm.

Ulrich

[1] 

[2] 

[gentoo-dev] Last rites: dev-php/roadsend-php

[Ole Markus With]

# Ole Markus With  (07 Sep 2011)
# Masked for removal 7 Oct 2011.
# Multiple bugs (315721,341685) and dead upstream
dev-php/roadsend-php

Cheers,
Ole Markus

Re: [gentoo-dev] rfc: using /libexec

[Amadeusz Żołnowski]

Excerpts from Rich Freeman's message of 2011-09-07 13:22:46 +0200:
> On Wed, Sep 7, 2011 at 5:27 AM, Michał Górny 
> wrote:
> > Old systems should migrate to initramfs, like it was already pointed
> > out before. Breakage is already there, you just don't notice it.
>
> Agreed, and once the official docs are updated and a working initramfs
> is available we can consider moving forward with things that break
> separate /usr.  That seemed to be the general consensus on the other
> thread.
> 
> Right now migrating to initramfs won't do any good, as Gentoo doesn't
> have an initramfs available which mounts /usr.  No doubt once Fedora
> gets theirs working we'll be able to copy it (assuming it is FOSS), or
> we can write our own.

Dracut supports mounting /usr since 013 if it's defined in /etc/fstab on
destination rootfs.  I'm still busy with my diploma to write Gentoo docs
about it and push Dracut into stabilization process, but as soon as I
finish I can move it forward.

-- 
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: using /libexec

[Rich Freeman]

On Wed, Sep 7, 2011 at 5:27 AM, Michał Górny  wrote:

> On Wed, 07 Sep 2011 12:17:21 +0300
> Alexey Shvetsov  wrote:
>
> > Moving things as openrc to /usr/libexec will effectevely barake old
> > systems with separtae / and /usr. So it isnt good idea
>
> Old systems should migrate to initramfs, like it was already pointed
> out before. Breakage is already there, you just don't notice it.
>
>
Agreed, and once the official docs are updated and a working initramfs is
available we can consider moving forward with things that break separate
/usr.  That seemed to be the general consensus on the other thread.

Right now migrating to initramfs won't do any good, as Gentoo doesn't have
an initramfs available which mounts /usr.  No doubt once Fedora gets theirs
working we'll be able to copy it (assuming it is FOSS), or we can write our
own.

Rich

Re: [gentoo-dev] rfc: using /libexec

[Michał Górny]

On Wed, 07 Sep 2011 12:32:05 +0300
Alexey Shvetsov  wrote:

> On Wed, 7 Sep 2011 11:27:05 +0200, Michał Górny wrote:
> > On Wed, 07 Sep 2011 12:17:21 +0300
> > Alexey Shvetsov  wrote:
> >
> >> Moving things as openrc to /usr/libexec will effectevely barake old
> >> systems with separtae / and /usr. So it isnt good idea
> >
> > Old systems should migrate to initramfs, like it was already pointed
> > out before. Breakage is already there, you just don't notice it.
> 
> Almoust all of my systems have lvm and separated /usr. And all of
> them still boot fine

There's a difference between 'booting fine' and 'booting without any
silent failures and retries which fix stuff, not to mention ugly hacks
necessary to get things working'. And it will be even worse, at some
point.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: using /libexec

[Alexey Shvetsov]

On Wed, 7 Sep 2011 11:27:05 +0200, Michał Górny wrote:

On Wed, 07 Sep 2011 12:17:21 +0300
Alexey Shvetsov  wrote:


Moving things as openrc to /usr/libexec will effectevely barake old
systems with separtae / and /usr. So it isnt good idea


Old systems should migrate to initramfs, like it was already pointed
out before. Breakage is already there, you just don't notice it.


Almoust all of my systems have lvm and separated /usr. And all of them 
still boot fine

--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] rfc: using /libexec

[Michał Górny]

On Wed, 07 Sep 2011 12:17:21 +0300
Alexey Shvetsov  wrote:

> Moving things as openrc to /usr/libexec will effectevely barake old 
> systems with separtae / and /usr. So it isnt good idea

Old systems should migrate to initramfs, like it was already pointed
out before. Breakage is already there, you just don't notice it.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: using /libexec

[Alexey Shvetsov]

Moving things as openrc to /usr/libexec will effectevely barake old 
systems with separtae / and /usr. So it isnt good idea


On Tue, 6 Sep 2011 16:45:43 -0500, William Hubbs wrote:

On Tue, Sep 06, 2011 at 05:21:40PM -0400, Mike Frysinger wrote:

On Tuesday, September 06, 2011 14:46:06 William Hubbs wrote:
> we just got the following bug report for openrc today [1].
>
> On a gentoo 64 bit system, /lib is a symbolic link to /lib64, and 
this

> causes breakage in openrc.

that specific report sounds like using /run would fix things ?


I haven't really looked at using /run for anything in openrc on 
linux,

but that might be possible once we have it installed in baselayout.

I don't think it would fix this issue though.

as for the paths, openrc should be using the paths it installs into. 
so if
we're installing into /lib64/rc..., then that's what we should be 
using.


We are installing into /lib/rc, but /lib is a symlink on 64 bit 
systems,

so we are having an issue resolving the path.

> The simplest fix for this would be for us to add /libexec to 
baselayout
> and start using it for platform-agnostic code. We have 
/usr/libexec, so

> I don't know why we don't have /libexec. Should we?

same answer as last time people have asked about /libexec: no.  we 
dont need
it, and it's ugly cruft that no other distro ive seen uses, and this 
isnt

something we need to differentiate Gentoo.


The same thing should be applied to /usr/libexec then shouldn't it?
(just asking for more info here)

William


--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, Russia
Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexx...@gmail.com
mailto:ale...@gentoo.org
mailto:ale...@omrb.pnpi.spb.ru

Re: [gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Andreas K. Hüttel]

Ack.. both makes definitely sense.



> -- Přeposlaná zpráva --
> Od: Tomáš Chvátal 
> Datum: 5. září 2011 18:08
> Předmět: Re: [gentoo-dev-announce] Call for items for September 13
> council meeting
> Komu: gentoo-dev@lists.gentoo.org
> 
> 
> Start collecting ideas for EAPI5.
> 
> I myself would like PATCHES array to be default in src_prepare phase
> and some solution for runtime optional deps, Instead of elog in
> postinst something like Recommended from rpm.
> 
> Cheers
> 
> Tom

Re: [gentoo-dev] Autodep project

[Tomáš Chvátal]

Hi,
really cool thing you create :)

Would it be possible to move that package to main tree, and merge
or possibly add new FEATURES option to portage like "autobuildchecks" that
would be set by -dev profile?

Cheers
Tom

[gentoo-dev] Fwd: [gentoo-dev-announce] Call for items for September 13 council meeting

[Tomáš Chvátal]

Resending as i sent it from gmail instead of google acc so it didn't
hit the list.


-- Přeposlaná zpráva --
Od: Tomáš Chvátal 
Datum: 5. září 2011 18:08
Předmět: Re: [gentoo-dev-announce] Call for items for September 13
council meeting
Komu: gentoo-dev@lists.gentoo.org


Start collecting ideas for EAPI5.

I myself would like PATCHES array to be default in src_prepare phase
and some solution for runtime optional deps, Instead of elog in
postinst something like Recommended from rpm.

Cheers

Tom

[gentoo-dev] Re: Committing packages with unfetchable sources [sys-devel/gdb-7.3.1]

[Tomáš Chvátal]

Resending as i sent it from gmail instead of google acc so it didn't
hit the list.

Dne 7. září 2011 9:20 Tomáš Chvátal  napsal(a):
> Hi,
> please stop committing packages that is not possible to fetch right away.
> You can pick from three options:
> a) stop using mirrors://gentoo/ and put it on dev.gentoo.org to your
> public_html like most of us do
> b) mask the package until the file is propagated to the mirrors and
> then unmask it
> c) commit it after few hours you pushed the tarball to mirrors so you
> can be sure it is fetchable
>
> This is more than annoying to have failing build on your update just
> because of your lazyness.
>
> Tom
>

Re: [gentoo-dev] [RFC] virtual/polkit-agent virtual pkg

[Samuli Suominen]

On 09/06/2011 07:44 PM, Maxim Koltsov wrote:
> If user is emerging some polkit-requiring package on DE-less system,
> it will pull big bunch of KDE, GNOME, etc. pacakges, which is not
> desired. Also, nm-applet and others can be set up with localauthority
> files, without help of polkit agents. I don't think virtual will solve
> this case.
> 

+1

Even if ebuild deps on agent, we can't ensure the user runs the agent
and which agent he wants.
So this is a depend that can't be put on ebuilds, needs extra steps from
user in any case.
The USE flags "gtk" and "kde" are there already as convinience in
polkit's ebuild pulling some agents...

So the solution is not to create a virtual, but rather remove the
specific agent depend on the offending ebuild

Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

[Michał Górny]

On Wed, 7 Sep 2011 09:32:30 +0200
Corentin Chary  wrote:

> On Tue, Sep 6, 2011 at 8:20 PM, Matt Turner 
> wrote:
> > On Sun, Apr 3, 2011 at 1:20 PM, Corentin Chary
> >  wrote:
> >> Hi again,
> >
> > Found a little problem: it's not finding a newer version of
> > wireless-regdb, which uses a date-based versioning system. If euscan
> > tried to view/parse the directory index where the distfiles are
> > located, it would find this new file.
> >
> > http://euscan.iksaif.net/package/net-wireless/wireless-regdb/
> 
> Hi,
> If you try to run euscan on that, you'll get:
> 
> >  * Url doesn't seems to depend on version: 20101124 not found in
> > http://wireless.kernel.org/download/wireless-regdb/wireless-regdb-2010.11.24.tar.bz2
> 
> What's happenning here is that the version can be found in the url, so
> even a directory scan won't find anything because it won't be able to
> match files.
> It would work correctly if the version was 2010.11.24 or the file was
> named wireless-regdb-20101124.tar.bz2.
> 
> Unfortunatly, making that work would probably introduce a lot of false
> positive in other cases.

To be honest, you should be possible to preset PN, PV and other ebuild
variables and run the ebuild afterwards to see what SRC_URI it gives.
But that's a significant amount of work.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: euscan proof of concept (like debian's uscan)

[Corentin Chary]

On Tue, Sep 6, 2011 at 8:20 PM, Matt Turner  wrote:
> On Sun, Apr 3, 2011 at 1:20 PM, Corentin Chary  
> wrote:
>> Hi again,
>
> Found a little problem: it's not finding a newer version of
> wireless-regdb, which uses a date-based versioning system. If euscan
> tried to view/parse the directory index where the distfiles are
> located, it would find this new file.
>
> http://euscan.iksaif.net/package/net-wireless/wireless-regdb/

Hi,
If you try to run euscan on that, you'll get:

>  * Url doesn't seems to depend on version: 20101124 not found in 
> http://wireless.kernel.org/download/wireless-regdb/wireless-regdb-2010.11.24.tar.bz2

What's happenning here is that the version can be found in the url, so
even a directory scan won't find anything because it won't be able to
match files.
It would work correctly if the version was 2010.11.24 or the file was
named wireless-regdb-20101124.tar.bz2.

Unfortunatly, making that work would probably introduce a lot of false
positive in other cases.

Thanks,

-- 
Corentin Chary
http://xf.iksaif.net