Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Alexander Tsoy]

On Thu, 15 Oct 2015 19:47:59 +0800
Jason Zaman  wrote:

> On Thu, Oct 15, 2015 at 07:38:43AM -0400, Anthony G. Basile wrote:
> > On 10/15/15 7:24 AM, Rich Freeman wrote:
> > > On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman
> > >  wrote:
> > >> Can you try this:
> > >>
> > >> # getfattr -d -m- /bin/ping
> > >> security.capability=0sAQAAAgAgAAA=
> > >> # setfattr -n user.test -v "foo" ./ping
> > >> # setfattr -n user.pax.flags -v "me" ./ping
> > >> # getfattr -d -m- /bin/ping
> > >> security.capability=0sAQAAAgAgAAA=
> > >> user.pax.flags="me"
> > >> user.test="foo"
> > >>
> > >> If this works then something else is causing those messages and
> > >> we should look into it further.
> > > This behaves exactly as described above for me on btrfs, but I
> > > still do get all the error messages whenever I install stuff.
> > >
> > > I assume the extra attributes are harmless and will get removed
> > > the next time I update ping?
> > >
> > okay its good to know that that this does work.  something might be 
> > misconfigured on tobias's box.
> > 
> > let me know any problems with XATTR_PAX markings because that's
> > going to become the default soon and in the near future the only
> > option once we drop the PT_PAX patch from binutils.
> 
> I seem to recall something about PaX enabling user.* xattrs on tmpfs
> and mainline kernel supports only security.* on tmpfs. Could that be
> the cause? If that is the case then what do we do about everyone that
> is using gentoo-sources? It probably doesnt matter so just silencing
> the errors is probably enough.
> 

I was wrong. This patch was not merged upstream. It is still needed and
included in latest genpatches for 4.2:

$ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
./1500_XATTR_USER_PREFIX.patch

-- 
Alexander Tsoy

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Rich Freeman]

On Thu, Oct 15, 2015 at 7:58 AM, Alexander Tsoy  wrote:
>
> I was wrong. This patch was not merged upstream. It is still needed and
> included in latest genpatches for 4.2:
>
> $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
> ./1500_XATTR_USER_PREFIX.patch

I suspect what we all have in common then is that we're using tmpfs to
do builds and we're not using genpatches.

If the warning isn't an issue for non-hardened users then I don't see
any need to change anything.  Is the patch (or something similar)
likely to get merged?  It doesn't really seem ideal to be dependent on
something not in mainline.

-- 
Rich

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Jason Zaman]

On Thu, Oct 15, 2015 at 10:57:45AM +0200, Tobias Klausmann wrote:
> Hi! 
> 
> On Wed, 14 Oct 2015, Mike Frysinger wrote:
> > anyone opposed to flipping this flag on by default ?
> > 
> > reference:
> > https://bugs.gentoo.org/506198
> > https://bugs.gentoo.org/556408
> 
> No objection, but a bit of a datapoint. I use btrfs on one of my
> machines, and that filesystem (apparently) does not support
> XATTR_PAX markings. So on every update I get some packages with
> message like these:

I used to run hardened on btrfs and it worked fine. pax xattrs are in
the user namespace (user.pax.flags) which isnt protected (unlike eg.
security.*). I dont remember doing anything special to enable xattrs on
btrfs, most of the newer FSs have them enabled by default.

Can you try this:

# getfattr -d -m- /bin/ping
security.capability=0sAQAAAgAgAAA=
# setfattr -n user.test -v "foo" ./ping
# setfattr -n user.pax.flags -v "me" ./ping
# getfattr -d -m- /bin/ping
security.capability=0sAQAAAgAgAAA=
user.pax.flags="me"
user.test="foo"

If this works then something else is causing those messages and we
should look into it further.

> 
> >>> Messages generated for package app-emulation/qemu-2.4.0.1 by process 2675 
> >>> on 20151013-150646 CEST:
> 
> LOG: install
> Failed to set XATTR_PAX markings -me qemu-system-aarch64.
> Failed to set XATTR_PAX markings -me qemu-system-alpha.
> Failed to set XATTR_PAX markings -me qemu-system-i386.
> Failed to set XATTR_PAX markings -me qemu-system-x86_64.
> Failed to set XATTR_PAX markings -me qemu-aarch64.
> Failed to set XATTR_PAX markings -me qemu-alpha.
> Failed to set XATTR_PAX markings -me qemu-i386.
> Failed to set XATTR_PAX markings -me qemu-x86_64.
> 
> Two things about this: the message is not really useful, unless I
> know what -me does. Also, I never requested anything PaX-ish, I
> just don't want to to have SUID binaries when I can avoid it.

Not that it matters since you dont run hardened, but "m" means "disable
mprotext" and "e" means "disable trampoline emulation".

-- Jason
> 
> By now the messages are just an annoyance/spam to me, but I
> suspect this may be more of a problem for people who have lower
> pain thresholds.
> 
> Regards,
> Tobias
> 
> -- 
> "Sendmail is the sort of tool that gave UNIX its bad reputation."
>-- _System Performance Tuning_
> 

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Anthony G. Basile]

On 10/15/15 7:24 AM, Rich Freeman wrote:

On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman  wrote:

Can you try this:

# getfattr -d -m- /bin/ping
security.capability=0sAQAAAgAgAAA=
# setfattr -n user.test -v "foo" ./ping
# setfattr -n user.pax.flags -v "me" ./ping
# getfattr -d -m- /bin/ping
security.capability=0sAQAAAgAgAAA=
user.pax.flags="me"
user.test="foo"

If this works then something else is causing those messages and we
should look into it further.

This behaves exactly as described above for me on btrfs, but I still
do get all the error messages whenever I install stuff.

I assume the extra attributes are harmless and will get removed the
next time I update ping?

okay its good to know that that this does work.  something might be 
misconfigured on tobias's box.


let me know any problems with XATTR_PAX markings because that's going to 
become the default soon and in the near future the only option once we 
drop the PT_PAX patch from binutils.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Jason Zaman]

On Thu, Oct 15, 2015 at 07:38:43AM -0400, Anthony G. Basile wrote:
> On 10/15/15 7:24 AM, Rich Freeman wrote:
> > On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman  wrote:
> >> Can you try this:
> >>
> >> # getfattr -d -m- /bin/ping
> >> security.capability=0sAQAAAgAgAAA=
> >> # setfattr -n user.test -v "foo" ./ping
> >> # setfattr -n user.pax.flags -v "me" ./ping
> >> # getfattr -d -m- /bin/ping
> >> security.capability=0sAQAAAgAgAAA=
> >> user.pax.flags="me"
> >> user.test="foo"
> >>
> >> If this works then something else is causing those messages and we
> >> should look into it further.
> > This behaves exactly as described above for me on btrfs, but I still
> > do get all the error messages whenever I install stuff.
> >
> > I assume the extra attributes are harmless and will get removed the
> > next time I update ping?
> >
> okay its good to know that that this does work.  something might be 
> misconfigured on tobias's box.
> 
> let me know any problems with XATTR_PAX markings because that's going to 
> become the default soon and in the near future the only option once we 
> drop the PT_PAX patch from binutils.

I seem to recall something about PaX enabling user.* xattrs on tmpfs and
mainline kernel supports only security.* on tmpfs. Could that be the
cause? If that is the case then what do we do about everyone that is
using gentoo-sources? It probably doesnt matter so just silencing the
errors is probably enough.

-- Jason
> 
> -- 
> Anthony G. Basile, Ph.D.
> Gentoo Linux Developer [Hardened]
> E-Mail: bluen...@gentoo.org
> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
> GnuPG ID  : F52D4BBA
> 
> 

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Anthony G. Basile]

On 10/14/15 11:48 PM, Mike Frysinger wrote:

USE=xattr is needed nowadays to support:
- filesystem caps (those things that let you drop set*id and generally
   improves system security w/little to no runtime overhead)
- PaX file markings (replaces binutils ELF markings)
- selinux

we actually have USE=filecaps on by default already, and catalyst
hard requires tar[xattr] in order to work.  the hardened profile
also package.use.force's this flag on for some core packages.

not too many packages actually utilize this flag, and when they do,
it's to pull in the attr package which clocks in at <200 KiB.  the
runtime overhead tends to be low to non-existent as xattrs tend to
be used only when requested.

when support is not available in the FS or kernel, packages should
generally fall back gracefully.

anyone opposed to flipping this flag on by default ?


do it.  the only problem i see coming is kernel configurations which 
don't have xattrs set.  this can happen on embedded boards where its 
difficult/impossible to swap out kernels (like some of the stuff i 
have).  fcaps.eclass has intelligence for this.  i'll look again at 
pax-utils.eclass and make sure there is enough error checking to deal 
with kernel/filesystems that can't handle xattrs.  i remember some issue 
with scanfelf's exit code which caused some problem, but we can talk 
about that later when i've refreshed the issue in my head.




reference:
https://bugs.gentoo.org/506198
https://bugs.gentoo.org/556408
-mike



--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Anthony G. Basile]

On 10/15/15 4:13 AM, Alexis Ballier wrote:

On Thu, 15 Oct 2015 10:08:54 +0200
Tobias Klausmann  wrote:


Hi!

On Wed, 14 Oct 2015, Mike Frysinger wrote:

iputils is currently in @system for everyone.  by default, it only
installs `ping`.  do we feel strongly enough about this to require
all systems include it ?  or should this wait for the long idea of
releasing stage4's instead of stage3's ?

What's the gain? The package is tiny and it is one of the most
basic network diagnostic tools. When setting up a machine, ping
may be the only tool that lets you figure out why all the fetches
are failing. I think we should keep it, unless there is a
compelling reason not to (or when we get s4s).

# busybox ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=37.303 ms



(bb is in @system afaik)



i should read an entire thread before responding :)  i didn't see 
someone had already pointed out busybox.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Anthony G. Basile]

On 10/15/15 4:08 AM, Tobias Klausmann wrote:

Hi!

On Wed, 14 Oct 2015, Mike Frysinger wrote:

iputils is currently in @system for everyone.  by default, it only
installs `ping`.  do we feel strongly enough about this to require
all systems include it ?  or should this wait for the long idea of
releasing stage4's instead of stage3's ?

What's the gain? The package is tiny and it is one of the most
basic network diagnostic tools. When setting up a machine, ping
may be the only tool that lets you figure out why all the fetches
are failing. I think we should keep it, unless there is a
compelling reason not to (or when we get s4s).

Regards,
Tobias

use busybox's ping.  its poorly maintained if its maintained at all.  it 
makes my life easier because i don't have to worry about its brokenness 
on alt libc's.  just look at the patches we have to carry for it.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Rich Freeman]

On Wed, Oct 14, 2015 at 11:39 PM, Mike Frysinger  wrote:
> iputils is currently in @system for everyone.  by default, it only
> installs `ping`.  do we feel strongly enough about this to require
> all systems include it ?  or should this wait for the long idea of
> releasing stage4's instead of stage3's ?

IMO this should certainly be installed by default, but it should also
not be a part of the @system set unless portage depends on it or
something like that.

Thus this should probably wait until we start releasing stage4s.

The fact that everybody wants a package to be installed shouldn't be a
reason to put it in the @system set.  It should instead be a reason to
have some tool other than the @system set to give everybody what they
want.  We need one set for the stuff that everybody agrees is
indispensable (@tbd), and a different set for the minimum set of
software (@system) you need to bootstrap the rest of the packages in
the repo.

-- 
Rich

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Tobias Klausmann]

Hi! 

On Thu, 15 Oct 2015, Jason Zaman wrote:
> Can you try this:
> 
> # getfattr -d -m- /bin/ping
> security.capability=0sAQAAAgAgAAA=
> # setfattr -n user.test -v "foo" ./ping
> # setfattr -n user.pax.flags -v "me" ./ping
> # getfattr -d -m- /bin/ping
> security.capability=0sAQAAAgAgAAA=
> user.pax.flags="me"
> user.test="foo"
> 
> If this works then something else is causing those messages and we
> should look into it further.

# cd /bin/
# getfattr -d -m- ./ping
# file: ping
security.capability=0sAQAAAgAgAAA=

# setfattr -n user.test -v "foo" ./ping
# setfattr -n user.pax.flags -v "me" ./ping
# getfattr -d -m- ./ping
# file: ping
security.capability=0sAQAAAgAgAAA=
user.pax.flags="me"
user.test="foo"

But note that emerging iputils does _not_ result in the PaX
messages I described. Here's an incomplete list of packages that
have triggered them in the past:

app-emulation/qemu-2.4.0.1
dev-lang/ghc-7.10.2-r1
dev-lang/python-3.5.0-r1
media-video/mpv-0.11.0
sys-devel/llvm-3.7.0-r2
www-client/firefox-bin-41.0.1
www-client/google-chrome-beta-46.0.2490.64_p1

I have no clue what they do differently from iputils to result in
those messages.

So I looked at a file mentioned during the llvm merge,
/usr/bin/llvm-rtdyld:

# getfattr ./llvm-rtdyld 
# setfattr -n user.test -v "foo" ./llvm-rtdyld
# setfattr -n user.pax.flags -v "me" ./llvm-rtdyld
# getfattr -d -m- ./llvm-rtdyld

Then I remembered that the setfattr might not happen in the live
system, but on the tmpfs mounted on /var/tmp/portage.

So I tried it there:

# cp ./llvm-rtdyld /var/tmp/portage
# cd /var/tmp/portage
# getfattr -d -m- ./llvm-rtdyld
# setfattr -n user.test -v "foo" ./llvm-rtdyld
setfattr: ./llvm-rtdyld: Operation not supported
# setfattr -n user.pax.flags -v "me" ./llvm-rtdyld
setfattr: ./llvm-rtdyld: Operation not supported

So it's not a BTRFS problem, but one of tmpfs. So I wondered if I
maybe had missed to activate xattr suport for tmpfs, but no:

# zgrep -i tmpfs /proc/config.gz 
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
#

I have no clue what's missing, since I can't find a mount option
or anything that I might have missed:

# mount -l -t tmpfs |grep portage
none on /var/tmp/portage type tmpfs (rw,relatime,size=8388608k)

On a whim, I tried user_xattr, something older ext* FSs support,
but alas:

# mount -o remount,user_xattr /var/tmp/portage
mount: /var/tmp/portage not mounted or bad option

   In some cases useful info is found in syslog - try
   dmesg | tail or so.
# dmesg|tail -n1
[ 8623.541053] tmpfs: No value for mount option 'user_xattr'

Providing =something just results in this:
[ 8701.215926] tmpfs: Bad mount option user_xattr

So I'm fresh out of ideas.

Regards,
Tobias





-- 
"Sendmail is the sort of tool that gave UNIX its bad reputation."
   -- _System Performance Tuning_

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Rich Freeman]

On Thu, Oct 15, 2015 at 7:22 AM, Tobias Klausmann  wrote:
>
> So it's not a BTRFS problem, but one of tmpfs. So I wondered if I
> maybe had missed to activate xattr suport for tmpfs, but no:
>
> # zgrep -i tmpfs /proc/config.gz
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_TMPFS=y
> CONFIG_TMPFS_POSIX_ACL=y
> CONFIG_TMPFS_XATTR=y
> #

Same here (but I don't enable DEVTMPFS_MOUNT).  I had also wondered if
this was btrfs-related but it might indeed be tmpfs related.

-- 
Rich

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Alexander Tsoy]

On Thu, 15 Oct 2015 18:56:28 +0800
Jason Zaman  wrote:

> On Thu, Oct 15, 2015 at 10:57:45AM +0200, Tobias Klausmann wrote:
> > Hi! 
> > 
> > On Wed, 14 Oct 2015, Mike Frysinger wrote:
> > > anyone opposed to flipping this flag on by default ?
> > > 
> > > reference:
> > > https://bugs.gentoo.org/506198
> > > https://bugs.gentoo.org/556408
> > 
> > No objection, but a bit of a datapoint. I use btrfs on one of my
> > machines, and that filesystem (apparently) does not support
> > XATTR_PAX markings. So on every update I get some packages with
> > message like these:
> 
> I used to run hardened on btrfs and it worked fine. pax xattrs are in
> the user namespace (user.pax.flags) which isnt protected (unlike eg.
> security.*). I dont remember doing anything special to enable xattrs
> on btrfs, most of the newer FSs have them enabled by default.
> 
> Can you try this:
> 
> # getfattr -d -m- /bin/ping

I think he should check xattr support in PORTAGE_TMPDIR in the first
place. :) I suspect something like tmpfs mounted on it
(and CONFIG_TMPFS_XATTR=n in the kernel config).

-- 
Alexander Tsoy

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Anthony G. Basile]

On 10/14/15 11:39 PM, Mike Frysinger wrote:

iputils is currently in @system for everyone.  by default, it only
installs `ping`.  do we feel strongly enough about this to require
all systems include it ?  or should this wait for the long idea of
releasing stage4's instead of stage3's ?
-mike


i can live with this.  the busybox ebuild provides ping.  let's just 
document `ln -sf /bin/busybox /bin/ping`


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Re: [rfc] enable USE=xattr by default

[Anthony G. Basile]

On 10/15/15 6:32 AM, Duncan wrote:

Tobias Klausmann posted on Thu, 15 Oct 2015 10:57:45 +0200 as excerpted:


By now the messages are just an annoyance/spam to me, but I suspect this
may be more of a problem for people who have lower pain thresholds.

That could have been my post... all the way down to and including the
annoyance/spam bit.  Tho I hadn't thought of it as a btrfs thing, but
yes, I'm running it too.

Can't those messages be turned off, if, say, the kernel doesn't support
pax, or if btrfs-progs is installed, or something?

yes we can silence those. but that there's still the issue that xattrs 
on btrfs should not be a problem.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Alexander Tsoy]

On Thu, 15 Oct 2015 14:58:01 +0300
Alexander Tsoy  wrote:

> On Thu, 15 Oct 2015 19:47:59 +0800
> Jason Zaman  wrote:
> 
> > On Thu, Oct 15, 2015 at 07:38:43AM -0400, Anthony G. Basile wrote:
> > > On 10/15/15 7:24 AM, Rich Freeman wrote:
> > > > On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman
> > > >  wrote:
> > > >> Can you try this:
> > > >>
> > > >> # getfattr -d -m- /bin/ping
> > > >> security.capability=0sAQAAAgAgAAA=
> > > >> # setfattr -n user.test -v "foo" ./ping
> > > >> # setfattr -n user.pax.flags -v "me" ./ping
> > > >> # getfattr -d -m- /bin/ping
> > > >> security.capability=0sAQAAAgAgAAA=
> > > >> user.pax.flags="me"
> > > >> user.test="foo"
> > > >>
> > > >> If this works then something else is causing those messages and
> > > >> we should look into it further.
> > > > This behaves exactly as described above for me on btrfs, but I
> > > > still do get all the error messages whenever I install stuff.
> > > >
> > > > I assume the extra attributes are harmless and will get removed
> > > > the next time I update ping?
> > > >
> > > okay its good to know that that this does work.  something might
> > > be misconfigured on tobias's box.
> > > 
> > > let me know any problems with XATTR_PAX markings because that's
> > > going to become the default soon and in the near future the only
> > > option once we drop the PT_PAX patch from binutils.
> > 
> > I seem to recall something about PaX enabling user.* xattrs on tmpfs
> > and mainline kernel supports only security.* on tmpfs. Could that be
> > the cause? If that is the case then what do we do about everyone
> > that is using gentoo-sources? It probably doesnt matter so just
> > silencing the errors is probably enough.
> > 
> 
> I was wrong. This patch was not merged upstream. It is still needed
> and included in latest genpatches for 4.2:
> 
> $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
> ./1500_XATTR_USER_PREFIX.patch
> 

Oops.. Sorry, I replied on the wrong message. This was intended for
Tobias.

-- 
Alexander Tsoy

[gentoo-dev] Re: [rfc] enable USE=xattr by default

[Duncan]

Tobias Klausmann posted on Thu, 15 Oct 2015 10:57:45 +0200 as excerpted:

> By now the messages are just an annoyance/spam to me, but I suspect this
> may be more of a problem for people who have lower pain thresholds.

That could have been my post... all the way down to and including the 
annoyance/spam bit.  Tho I hadn't thought of it as a btrfs thing, but 
yes, I'm running it too.

Can't those messages be turned off, if, say, the kernel doesn't support 
pax, or if btrfs-progs is installed, or something?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Rich Freeman]

On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman  wrote:
>
> Can you try this:
>
> # getfattr -d -m- /bin/ping
> security.capability=0sAQAAAgAgAAA=
> # setfattr -n user.test -v "foo" ./ping
> # setfattr -n user.pax.flags -v "me" ./ping
> # getfattr -d -m- /bin/ping
> security.capability=0sAQAAAgAgAAA=
> user.pax.flags="me"
> user.test="foo"
>
> If this works then something else is causing those messages and we
> should look into it further.

This behaves exactly as described above for me on btrfs, but I still
do get all the error messages whenever I install stuff.

I assume the extra attributes are harmless and will get removed the
next time I update ping?

-- 
Rich

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Anthony G. Basile]

On 10/15/15 4:57 AM, Tobias Klausmann wrote:

Hi!

On Wed, 14 Oct 2015, Mike Frysinger wrote:

anyone opposed to flipping this flag on by default ?

reference:
https://bugs.gentoo.org/506198
https://bugs.gentoo.org/556408

No objection, but a bit of a datapoint. I use btrfs on one of my
machines, and that filesystem (apparently) does not support
XATTR_PAX markings. So on every update I get some packages with
message like these:


Messages generated for package app-emulation/qemu-2.4.0.1 by process 2675 on 
20151013-150646 CEST:

LOG: install
Failed to set XATTR_PAX markings -me qemu-system-aarch64.
Failed to set XATTR_PAX markings -me qemu-system-alpha.
Failed to set XATTR_PAX markings -me qemu-system-i386.
Failed to set XATTR_PAX markings -me qemu-system-x86_64.
Failed to set XATTR_PAX markings -me qemu-aarch64.
Failed to set XATTR_PAX markings -me qemu-alpha.
Failed to set XATTR_PAX markings -me qemu-i386.
Failed to set XATTR_PAX markings -me qemu-x86_64.

Two things about this: the message is not really useful, unless I
know what -me does. Also, I never requested anything PaX-ish, I
just don't want to to have SUID binaries when I can avoid it.

By now the messages are just an annoyance/spam to me, but I
suspect this may be more of a problem for people who have lower
pain thresholds.

Regards,
Tobias


open a bug because this should work on btrfs.

--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

[gentoo-dev] Re: [rfc] enable USE=xattr by default

[Duncan]

Alexander Tsoy posted on Thu, 15 Oct 2015 14:09:29 +0300 as excerpted:

> On Thu, 15 Oct 2015 18:56:28 +0800 Jason Zaman 
> wrote:
> 
>> On Thu, Oct 15, 2015 at 10:57:45AM +0200, Tobias Klausmann wrote:
>> > Hi!
>> > 
>> > On Wed, 14 Oct 2015, Mike Frysinger wrote:
>> > > anyone opposed to flipping this flag on by default ?
>> > > 
>> > > reference:
>> > > https://bugs.gentoo.org/506198 https://bugs.gentoo.org/556408
>> > 
>> > No objection, but a bit of a datapoint. I use btrfs on one of my
>> > machines, and that filesystem (apparently) does not support XATTR_PAX
>> > markings. So on every update I get some packages with message like
>> > these:
>> 
>> I used to run hardened on btrfs and it worked fine. pax xattrs are in
>> the user namespace (user.pax.flags) which isnt protected (unlike eg.
>> security.*). I dont remember doing anything special to enable xattrs on
>> btrfs, most of the newer FSs have them enabled by default.
>> 
>> Can you try this:
>> 
>> # getfattr -d -m- /bin/ping
> 
> I think he should check xattr support in PORTAGE_TMPDIR in the first
> place. :) I suspect something like tmpfs mounted on it (and
> CONFIG_TMPFS_XATTR=n in the kernel config).

As I posted, I have the same problem here (tho I didn't blame btrfs), but 
while PORTAGE_TMPDIR is indeed tmpfs, zgrep XATTR /proc/config.gz says 
CONFIG_TMPFS_XATTR=y, so that's not it.

But the closest thing btrfs has to that option is 
CONFIG_BTRFS_FS_POSIX_ACL, which I do NOT have enabled, so if it's 
required...

Meanwhile, the setfattr/getfattr test works (tho getfattr says it's 
removing the leading /).  So it would appear btrfs is fine, and the tmpfs 
PORTAGE_TMPDIR is fine, but I still get those XATTR_PAX failed-to-set 
warnings.

Tho I just remerged iputils and didn't get the warnings, so maybe we're 
not checking the right binaries?

IIRC, firefox gave me the warnings, however, and I'm doing an update 
including 41.0.1 ATM, so I can verify, tho of course FF takes awhile to 
build and it's near the end of a list of 100+ packages to update, so...

Could it be related to one of FEATURES="ipc-sandbox sandbox userpriv 
usersandbox xattr" (choosing a few from my set that look like possible 
candidates)?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: [rfc] drop iputils from @system (i.e. ping)

[Duncan]

Mike Frysinger posted on Wed, 14 Oct 2015 23:39:55 -0400 as excerpted:

> iputils is currently in @system for everyone.  by default, it only
> installs `ping`.  do we feel strongly enough about this to require all
> systems include it ?  or should this wait for the long idea of releasing
> stage4's instead of stage3's ?
> -mike

Talking about iputils...

What recently changed that previously pulled in iputils as a depend (of 
what type I'm not sure)?

As I've occasionally posted, I negate every @system entry in 
/etc/portage/profile/packages, effectively giving me an empty @system set 
(which depclean warns about, the way I know that the cascaded @system 
list hasn't been updated, forcing me to update my negations).

But until a week or so ago, something was apparently still pulling iputils 
in as a dependency, as it wasn't in any of my sets included in 
world_sets, yet was still not depcleaned.  A week or so ago that changed, 
and depclean wanted to remove it, but I decided it was useful enough that 
I wanted to keep it, so added it to the appropriate set that's included 
in my world_sets file, so depclean no longer wants to remove it.

But I still don't know what was previously pulling in iputils as a dep, 
that no longer does so now.

IOW, at least for me, the whole subject of the thread wouldn't have 
mattered until very recently, since something else was evidently pulling 
in iputils as a dep.  Only now that it's no longer doing so, does normal 
iputils listing in @system, that I've actually negated here along with 
the rest of @system listings, actually come into play.

So what was that dep, and what are the circumstances surrounding its 
removal as a dep?  I'm curious as to what triggered the whole change in 
status in the first place.

(Tho obviously I wasn't curious enough to go scrounging thru the git logs 
and updated packages between that update and the previous one, to find 
out what it was that way.  But now that it has come up here, I thought 
I'd ask, as there's obviously some backstory that could prove interesting 
to the discussion, that people with intact @systems probably would have 
never noticed.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Tobias Klausmann]

Hi! 

On Wed, 14 Oct 2015, Mike Frysinger wrote:
> anyone opposed to flipping this flag on by default ?
> 
> reference:
> https://bugs.gentoo.org/506198
> https://bugs.gentoo.org/556408

No objection, but a bit of a datapoint. I use btrfs on one of my
machines, and that filesystem (apparently) does not support
XATTR_PAX markings. So on every update I get some packages with
message like these:

>>> Messages generated for package app-emulation/qemu-2.4.0.1 by process 2675 
>>> on 20151013-150646 CEST:

LOG: install
Failed to set XATTR_PAX markings -me qemu-system-aarch64.
Failed to set XATTR_PAX markings -me qemu-system-alpha.
Failed to set XATTR_PAX markings -me qemu-system-i386.
Failed to set XATTR_PAX markings -me qemu-system-x86_64.
Failed to set XATTR_PAX markings -me qemu-aarch64.
Failed to set XATTR_PAX markings -me qemu-alpha.
Failed to set XATTR_PAX markings -me qemu-i386.
Failed to set XATTR_PAX markings -me qemu-x86_64.

Two things about this: the message is not really useful, unless I
know what -me does. Also, I never requested anything PaX-ish, I
just don't want to to have SUID binaries when I can avoid it.

By now the messages are just an annoyance/spam to me, but I
suspect this may be more of a problem for people who have lower
pain thresholds.

Regards,
Tobias

-- 
"Sendmail is the sort of tool that gave UNIX its bad reputation."
   -- _System Performance Tuning_

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Tobias Klausmann]

Hi! 

On Wed, 14 Oct 2015, Mike Frysinger wrote:
> iputils is currently in @system for everyone.  by default, it only
> installs `ping`.  do we feel strongly enough about this to require
> all systems include it ?  or should this wait for the long idea of
> releasing stage4's instead of stage3's ?

What's the gain? The package is tiny and it is one of the most
basic network diagnostic tools. When setting up a machine, ping
may be the only tool that lets you figure out why all the fetches
are failing. I think we should keep it, unless there is a
compelling reason not to (or when we get s4s).

Regards,
Tobias

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Alexis Ballier]

On Thu, 15 Oct 2015 10:08:54 +0200
Tobias Klausmann  wrote:

> Hi! 
> 
> On Wed, 14 Oct 2015, Mike Frysinger wrote:
> > iputils is currently in @system for everyone.  by default, it only
> > installs `ping`.  do we feel strongly enough about this to require
> > all systems include it ?  or should this wait for the long idea of
> > releasing stage4's instead of stage3's ?  
> 
> What's the gain? The package is tiny and it is one of the most
> basic network diagnostic tools. When setting up a machine, ping
> may be the only tool that lets you figure out why all the fetches
> are failing. I think we should keep it, unless there is a
> compelling reason not to (or when we get s4s).

# busybox ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=56 time=37.303 ms



(bb is in @system afaik)

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Dale]

Andrew Udvare wrote:
>> On 2015-10-14, at 23:39, Mike Frysinger  wrote:
>>
>> iputils is currently in @system for everyone.  by default, it only
>> installs `ping`.  do we feel strongly enough about this to require
>> all systems include it ?  or should this wait for the long idea of
>> releasing stage4's instead of stage3's ?
>> -mike
> If I had got on a machine lacking the ping command, I would immediately 
> install it and otherwise avoid that machine (it's 'broken'). It really should 
> not get removed, plus it is tiny.
>
> A lot of hosts now block ICMP requests but it's just habit for many to type 
> `ping google.com` or similar to test when they suspect their internet is down.
>
> Andrew
>


+1

I do this all the time myself. 

Dale

:-)  :-) 

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Michael Orlitzky]

On 10/14/2015 11:39 PM, Mike Frysinger wrote:
> iputils is currently in @system for everyone.  by default, it only
> installs `ping`.  do we feel strongly enough about this to require
> all systems include it ?  or should this wait for the long idea of
> releasing stage4's instead of stage3's ?
> -mike
> 

Get rid of it. The @system set isn't for "stuff a lot of people want
installed."

[gentoo-dev] call for testers (obscure cgroups bugs in OpenRC)

[William Hubbs]

All,

There are some very obscure cgroups related bugs in OpenRC which I have
never been able to reproduce [1] [2] [3].

There was a cgroup fix applied to OpenRC-0.18.3 which took care of
several other cgroups-related bugs. Since I am unable to reproduce the
bugs I have listed here and there has been no other activity on them in
some time, I am moving them to test-request status. However, if you do
test and find these to still be happening in OpenRC-0.18.3, feel free to 
re-open.

Thanks,

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=489386
[2] https://bugs.gentoo.org/show_bug.cgi?id=530034
[3] https://bugs.gentoo.org/show_bug.cgi?id=553978


signature.asc
Description: Digital signature

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Mike Frysinger]

i will drop iputils from @system:
https://bugs.gentoo.org/563148

but not until our releases are sorted out:
https://bugs.gentoo.org/393445

and i'll see if we can't get that sorted out sooner rather than later
-mike


signature.asc
Description: Digital signature

[gentoo-dev] Re: [rfc] enable USE=xattr by default

[Duncan]

Rich Freeman posted on Thu, 15 Oct 2015 08:36:59 -0400 as excerpted:

> On Thu, Oct 15, 2015 at 7:58 AM, Alexander Tsoy 
> wrote:
>>
>> I was wrong. This patch was not merged upstream. It is still needed and
>> included in latest genpatches for 4.2:
>>
>> $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
>> ./1500_XATTR_USER_PREFIX.patch
> 
> I suspect what we all have in common then is that we're using tmpfs to
> do builds and we're not using genpatches.
> 
> If the warning isn't an issue for non-hardened users then I don't see
> any need to change anything.  Is the patch (or something similar)
> likely to get merged?  It doesn't really seem ideal to be dependent on
> something not in mainline.

Having just completed an update and checked the warnings, which occurred 
on firefox and llvm, I can confirm that the paths mentioned in the 
warnings are in the tmpfs PORTAGE_TMPDIR, *not* on btrfs.

And I run a mainline (direct git, in fact) kernel.

So the problem does indeed appear to be PORTAGE_TMPDIR on tmpfs, on a 
kernel without the gentoo patches.

AFAIK pax markings only matter if pax is enabled, which it won't be on 
mainline kernels since I don't believe they include the pax patches.  So 
the warnings, while annoying, don't signify a real problem.

But it would definitely be nice to have them turned off, or even have the 
entire attempt to do pax markings in the first place turned off, on non-
hardened kernels.

In any case, doesn't seem to be btrfs related at all. False alarm there. 
=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] ironing out release tarballs

[Mike Frysinger]

background:
everyone wants @system to be slim, but most people want the initial stage
tarball that we release and you install Gentoo from to not be completely
sparse.  we've got a bug for this topic:
https://bugs.gentoo.org/393445

items to sort out:
- should the list of packages be in catalyst or profile-stacked content
-> imo it should be entirely in the profile

- should the packages list be in a new packages.default, or should we create a
  new set to hold it, or should we just go with @profile ?
-> @profile has the advantage of already existing.  we have to be careful so as
   to make it difficult to uninstall packages that the user does not actually
   want.

- if the packages aren't in @profile, should they be seeded in @world ?
-> imo yes as  we don't want all the default packages getting depcleaned as
   soon as you start using the new install.  if they're in @profile, then this
   is a moot point (assuming depclean does not clean out @profile).

- should stage3 be @system only, or @system+@profile, or 
  @system+@profile+packages.default ?
-> this depends on the previous discussion a bit.  today, stage3's are 
   @system, but imo @system+@profile is reasonable.  see next question too.

- should we release stage4's instead of stage3's ?
-> if we keep stage3 as @system-only, then we'd build stage4's which would add
   @profile/whatever
-> downside is that we've been training the world to download & install stage3
   for almost 15 years
-> imo as long as the default @profile is kept slim, adjusting the definition of
   a stage3 is OK
-mike


signature.asc
Description: Digital signature

[gentoo-dev] [PATCH] cmake-utils.eclass: die if ninja is enabled but not installed

[Michael Palimaka]

This could happen if ninja is manually enabled (eg. make.conf) but not installed
---
 eclass/cmake-utils.eclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index 480cd09..012b13f 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -228,6 +228,11 @@ _generator_to_use() {
 
case ${CMAKE_MAKEFILE_GENERATOR} in
ninja)
+   # if ninja is enabled but not installed, the build 
could fail
+   # this could happen if ninja is manually enabled (eg. 
make.conf) but not installed
+   if ! has_version dev-util/ninja; then
+   die "CMAKE_MAKEFILE_GENERATOR is set to ninja, 
but ninja is not installed. Please install dev-util/ninja or unset 
CMAKE_MAKEFILE_GENERATOR."
+   fi
generator_name="Ninja"
;;
emake)
-- 
2.4.9

Re: [gentoo-dev] [PATCH] cmake-utils.eclass: die if ninja is enabled but not installed

[Michał Górny]

Dnia 15 października 2015 17:44:47 CEST, Michael Palimaka 
 napisał(a):
>This could happen if ninja is manually enabled (eg. make.conf) but not
>installed
>---
> eclass/cmake-utils.eclass | 5 +
> 1 file changed, 5 insertions(+)
>
>diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>index 480cd09..012b13f 100644
>--- a/eclass/cmake-utils.eclass
>+++ b/eclass/cmake-utils.eclass
>@@ -228,6 +228,11 @@ _generator_to_use() {
> 
>   case ${CMAKE_MAKEFILE_GENERATOR} in
>   ninja)
>+  # if ninja is enabled but not installed, the build 
>could fail
>+  # this could happen if ninja is manually enabled (eg. 
>make.conf)
>but not installed
>+  if ! has_version dev-util/ninja; then

I'd suggest avoiding has_version and just checking for the binary. type -P, I 
think. Ciaran can give you the rationale, I believe.

>+  die "CMAKE_MAKEFILE_GENERATOR is set to ninja, 
>but ninja is not
>installed. Please install dev-util/ninja or unset
>CMAKE_MAKEFILE_GENERATOR."
>+  fi
>   generator_name="Ninja"
>   ;;
>   emake)

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[hasufell]

On 10/15/2015 03:26 PM, Michael Orlitzky wrote:
> On 10/14/2015 11:39 PM, Mike Frysinger wrote:
>> iputils is currently in @system for everyone.  by default, it only
>> installs `ping`.  do we feel strongly enough about this to require
>> all systems include it ?  or should this wait for the long idea of
>> releasing stage4's instead of stage3's ?
>> -mike
>>
> 
> Get rid of it. The @system set isn't for "stuff a lot of people want
> installed."
> 
> 

+1

Re: [gentoo-dev] [rfc] drop iputils from @system (i.e. ping)

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/10/15 06:57 AM, Rich Freeman wrote:
> On Wed, Oct 14, 2015 at 11:39 PM, Mike Frysinger
>  wrote:
>> iputils is currently in @system for everyone.  by default, it
>> only installs `ping`.  do we feel strongly enough about this to
>> require all systems include it ?  or should this wait for the
>> long idea of releasing stage4's instead of stage3's ?
> 
> IMO this should certainly be installed by default, but it should
> also not be a part of the @system set unless portage depends on
> it or something like that.
> 
> Thus this should probably wait until we start releasing stage4s.
> 

So as mentioned already, there's a ping functionality provided by
busybox (and busybox won't be dropped from @system any time soon,
right?).  So long as people know that works (which may require
documentation updates), the removal of iputils will likely have very
little impact.

Secondly, iamben and I were discussing that the addition of a
section to the Handbook, "Optional: Highly Recommended Packages and
Tools" to, say, the bottom of the 'Installing system tools' chapter.
 A table containing package name and a quick description of its
importance should do.

Thirdly, is there any method that will alert users that iputils is
going to be depcleaned after it's dropped from @system ??  I know we
recommend people run it with --pretend, but if people aren't looking
for packages being dropped from @system I can see this falling
through the cracks a lot...


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYfvwUACgkQAJxUfCtlWe18eQEA7NBwxWbm5so+bTRUDNSWtY36
iEawa30vYoGvTo963GIA/1qrosPRVdxhEys5Wf2t3c6h7BWAmujd+A9sh035OoVb
=Ztgc
-END PGP SIGNATURE-

Re: [gentoo-dev] ironing out release tarballs

[Anthony G. Basile]

On 10/15/15 3:15 PM, Zac Medico wrote:


In portage, @world = @profile + @selected + @system, which means that
@profile is protected from depclean since it's a part of @world.

[1] https://bugs.gentoo.org/show_bug.cgi?id=532224


I thought so but wasn't sure and was about to test.  Both @system and 
@profile are controlled via the packages file in portage and stack.  
Packages in @system lead with an * while @profile don't. @system 
packages have incomplete dependency specifications while @profile have 
full.  This affects more than just emerge's ability to parallelize, no?


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] ironing out release tarballs

[Zac Medico]

On 10/15/2015 01:45 PM, Rich Freeman wrote:
> On Thu, Oct 15, 2015 at 4:10 PM, Zac Medico  wrote:
>> What's probably desired is to create a stage3 profile which adds
>> whatever extra stuff you want to @system, and to use the stage3 profile
>> for to build stage3. After the stage3 is built, catalyst could set some
>> other profile if we don't want users to have the stage3 profile by default.
> 
> Unless we seed @selected with the extra stuff, it will get removed the
> first time the user runs --depclean, which probably isn't what we
> want.
> 
> I'm fine with going the multi-profile route, but it seems to me that
> we still need some kind of initial @selected set.
> 
> Basically the goal here is to give the user a bunch of useful stuff by
> default (specified in some way in the profile), but make it easy for
> the user to remove it if they wish.
> 
> A side goal is to do this without adding 14 more profiles, because we
> don't have mixins.
> 

Given the goals, having catalyst seed /var/lib/portage/world seems
pretty reasonable to me.
-- 
Thanks,
Zac

Re: [gentoo-dev] ironing out release tarballs

[Mike Frysinger]

On 15 Oct 2015 12:15, Zac Medico wrote:
> On 10/15/2015 08:34 AM, Mike Frysinger wrote:
> > background:
> > everyone wants @system to be slim, but most people want the initial stage
> > tarball that we release and you install Gentoo from to not be completely
> > sparse.  we've got a bug for this topic:
> > https://bugs.gentoo.org/393445
> > 
> > items to sort out:
> > - should the list of packages be in catalyst or profile-stacked content
> > -> imo it should be entirely in the profile
> > 
> > - should the packages list be in a new packages.default, or should we 
> > create a
> >   new set to hold it, or should we just go with @profile ?
> > -> @profile has the advantage of already existing.  we have to be careful 
> > so as
> >to make it difficult to uninstall packages that the user does not 
> > actually
> >want.
> 
> In portage, the current meaning of @profile is very similar to @system,
> except that it implies that members specify dependencies completely
> (allowing for optimal parallelization) [1]. The @profile set is only
> enabled for profiles from repositories that have "profile-formats =
> profile-set" set in metadata/layout.conf. It's an extension which is not
> covered by PMS.

layout.conf isn't covered by PMS, nor are sets, and packages file format is
compatible with PMS.  so i think we are OK here.

> > - if the packages aren't in @profile, should they be seeded in @world ?
> > -> imo yes as  we don't want all the default packages getting depcleaned as
> >soon as you start using the new install.  if they're in @profile, then 
> > this
> >is a moot point (assuming depclean does not clean out @profile).
> 
> In portage, @world = @profile + @selected + @system, which means that
> @profile is protected from depclean since it's a part of @world.

so if iputils is in @profile, and i do:
emerge -C iputils
i don't get the ugly warning about it being in @system, but if i do:
emerge @world
iputils comes back.  i think that's OK actually since people can do:
emerge @selected
which has the classic @world meaning.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] ironing out release tarballs

[Rich Freeman]

On Thu, Oct 15, 2015 at 4:10 PM, Zac Medico  wrote:
> What's probably desired is to create a stage3 profile which adds
> whatever extra stuff you want to @system, and to use the stage3 profile
> for to build stage3. After the stage3 is built, catalyst could set some
> other profile if we don't want users to have the stage3 profile by default.

Unless we seed @selected with the extra stuff, it will get removed the
first time the user runs --depclean, which probably isn't what we
want.

I'm fine with going the multi-profile route, but it seems to me that
we still need some kind of initial @selected set.

Basically the goal here is to give the user a bunch of useful stuff by
default (specified in some way in the profile), but make it easy for
the user to remove it if they wish.

A side goal is to do this without adding 14 more profiles, because we
don't have mixins.

-- 
Rich

Re: [gentoo-dev] ironing out release tarballs

[Rich Freeman]

On Thu, Oct 15, 2015 at 5:15 PM, Zac Medico  wrote:
> On 10/15/2015 02:03 PM, Rich Freeman wrote:
>> On Thu, Oct 15, 2015 at 4:57 PM, Zac Medico  wrote:
>>> Given the goals, having catalyst seed /var/lib/portage/world seems
>>> pretty reasonable to me.
>>
>> Then the question becomes how.  Does it diff @profile between the two
>> profiles and put the extra stuff in @selected?  Or, does the profile
>> just contain a special file containing the stuff that gets seeded?
>> That is really the gist of the two approaches, and if you just have a
>> special file full of stuff that gets seeded you really don't need
>> another profile, which is nice since profiles are a PITA right now.
>>
>
> We already have packages.build which is used to build stage1, so
> introducing a packages.stage3 that's used to seed @selected (aka
> /var/lib/portage/world) for stage3 seems reasonable.

Seems reasonable to me, and the nice thing is that it doesn't change
the behavior of anything at all besides catalyst, so other than
starting out with a non-empty /var/lib/portage/world users won't see a
thing happen.

I won't bikeshed on the name of the file.  Whatever seems reasonable
to the catalyst team works fine for me.

This then conserves @profile for stuff that is more essential to the
profile itself, such as a fancy firmware loader for an arm box or
whatever (in our future luxury world where we can spare new profiles
for specific boards and such).  Of course, it wouldn't hurt to
standardize on how such sets work if we're going to start using them
seriously if that isn't in PMS.  However, I see all of that as
off-topic for the present discussion other than the desire to not
interfere with it.

-- 
Rich

Re: [gentoo-dev] ironing out release tarballs

[Zac Medico]

On 10/15/2015 12:29 PM, Ian Stakenvicius wrote:
> On 15/10/15 03:15 PM, Zac Medico wrote:
>> On 10/15/2015 08:34 AM, Mike Frysinger wrote:
>>> background: everyone wants @system to be slim, but most people
>>> want the initial stage tarball that we release and you install
>>> Gentoo from to not be completely sparse.  we've got a bug for
>>> this topic: https://bugs.gentoo.org/393445
>>>
>>> items to sort out: - should the list of packages be in catalyst
>>> or profile-stacked content -> imo it should be entirely in the
>>> profile
>>>
>>> - should the packages list be in a new packages.default, or
>>> should we create a new set to hold it, or should we just go
>>> with @profile ? -> @profile has the advantage of already
>>> existing.  we have to be careful so as to make it difficult to
>>> uninstall packages that the user does not actually want.
> 
>> In portage, the current meaning of @profile is very similar to
>> @system, except that it implies that members specify dependencies
>> completely (allowing for optimal parallelization) [1]. The
>> @profile set is only enabled for profiles from repositories that
>> have "profile-formats = profile-set" set in metadata/layout.conf.
>> It's an extension which is not covered by PMS.
> 
>>> - if the packages aren't in @profile, should they be seeded in
>>> @world ? -> imo yes as  we don't want all the default packages
>>> getting depcleaned as soon as you start using the new install.
>>> if they're in @profile, then this is a moot point (assuming
>>> depclean does not clean out @profile).
> 
>> In portage, @world = @profile + @selected + @system, which means
>> that @profile is protected from depclean since it's a part of
>> @world.
> 
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=532224
> 
> 
> 
> So just to clarify..  if we start adding these packages that are
> removed from @system into @profile, what do we gain here?  They'll
> exist in the stage3's (which is one of the goals right?), and
> they'll be included in @world without entries in
> /var/lib/portage/world (so end-users will have them on their
> systems)..  Seems like everything would be the same as if they were
> in @system, except 'emerge -e @system' wouldn't rebuild them..? Do
> we get the advantage(s) we were looking for, going this route?


What's probably desired is to create a stage3 profile which adds
whatever extra stuff you want to @system, and to use the stage3 profile
for to build stage3. After the stage3 is built, catalyst could set some
other profile if we don't want users to have the stage3 profile by default.
-- 
Thanks,
Zac

Re: [gentoo-dev] ironing out release tarballs

[Rich Freeman]

On Thu, Oct 15, 2015 at 4:57 PM, Zac Medico  wrote:
> Given the goals, having catalyst seed /var/lib/portage/world seems
> pretty reasonable to me.

Then the question becomes how.  Does it diff @profile between the two
profiles and put the extra stuff in @selected?  Or, does the profile
just contain a special file containing the stuff that gets seeded?
That is really the gist of the two approaches, and if you just have a
special file full of stuff that gets seeded you really don't need
another profile, which is nice since profiles are a PITA right now.

-- 
Rich

Re: [gentoo-dev] ironing out release tarballs

[Zac Medico]

On 10/15/2015 02:13 PM, Mike Frysinger wrote:
> On 15 Oct 2015 12:15, Zac Medico wrote:
>> On 10/15/2015 08:34 AM, Mike Frysinger wrote:
>>> background:
>>> everyone wants @system to be slim, but most people want the initial stage
>>> tarball that we release and you install Gentoo from to not be completely
>>> sparse.  we've got a bug for this topic:
>>> https://bugs.gentoo.org/393445
>>>
>>> items to sort out:
>>> - should the list of packages be in catalyst or profile-stacked content
>>> -> imo it should be entirely in the profile
>>>
>>> - should the packages list be in a new packages.default, or should we 
>>> create a
>>>   new set to hold it, or should we just go with @profile ?
>>> -> @profile has the advantage of already existing.  we have to be careful 
>>> so as
>>>to make it difficult to uninstall packages that the user does not 
>>> actually
>>>want.
>>
>> In portage, the current meaning of @profile is very similar to @system,
>> except that it implies that members specify dependencies completely
>> (allowing for optimal parallelization) [1]. The @profile set is only
>> enabled for profiles from repositories that have "profile-formats =
>> profile-set" set in metadata/layout.conf. It's an extension which is not
>> covered by PMS.
> 
> layout.conf isn't covered by PMS, nor are sets, and packages file format is
> compatible with PMS.  so i think we are OK here.
> 
>>> - if the packages aren't in @profile, should they be seeded in @world ?
>>> -> imo yes as  we don't want all the default packages getting depcleaned as
>>>soon as you start using the new install.  if they're in @profile, then 
>>> this
>>>is a moot point (assuming depclean does not clean out @profile).
>>
>> In portage, @world = @profile + @selected + @system, which means that
>> @profile is protected from depclean since it's a part of @world.
> 
> so if iputils is in @profile, and i do:
>   emerge -C iputils
> i don't get the ugly warning about it being in @system, but if i do:
>   emerge @world
> iputils comes back.  i think that's OK actually since people can do:
>   emerge @selected
> which has the classic @world meaning.
> -mike
> 

People need to be able to use @world without it pulling in unwanted
packages, since it's the only way to properly do a full update of all
relevant packages (relevant packages being those that would not be
removed by depclean).
-- 
Thanks,
Zac

Re: [gentoo-dev] ironing out release tarballs

[Zac Medico]

On 10/15/2015 01:29 PM, Anthony G. Basile wrote:
> On 10/15/15 4:14 PM, Zac Medico wrote:
>> On 10/15/2015 01:06 PM, Anthony G. Basile wrote:
>>> On 10/15/15 3:15 PM, Zac Medico wrote:
 In portage, @world = @profile + @selected + @system, which means that
 @profile is protected from depclean since it's a part of @world.

 [1] https://bugs.gentoo.org/show_bug.cgi?id=532224
>>> I thought so but wasn't sure and was about to test.  Both @system and
>>> @profile are controlled via the packages file in portage and stack.
>>> Packages in @system lead with an * while @profile don't. @system
>>> packages have incomplete dependency specifications while @profile have
>>> full.
>> Right.
>>
>>> This affects more than just emerge's ability to parallelize, no?
>> Having complete dependency specifications could be useful for some other
>> things, but allowing for more aggressive parallelization is one of the
>> most obvious advantage.
> 
> Okay, good because that fits my understanding of how we'd be dividing
> @system from @profile.
> 
> @system = the bare set that we need in an stage3 in order to build
> another stage3 via the catalyst process.  so the way this works is that
> you unpack a stage3, chroot into it, and then do a `ROOT=/some/new/root
> emerge @system` to prepare a pristine new root.  that root then seeds
> your stage2 at which point your rebuild your toolchain.  then that seeds
> your new stage3 in which you rebuild @system.
> 
> So that defines @system from the point of view of using a current stage3
> to give birth to a next generation stage3.  But that may not be what you
> want to release, eg. do you need any networking stuff in there?  This
> gave birth to the idea of a stage4 which would have the added goodies
> needed for an end user to grow a system from our release tarball. 
> vapier is suggesting using @profile for the extra needed beyond @system
> for the release.  So at all points except the very end, you just use
> @system for building because that's all you need, and then finally you
> produce an @system+@profile for release.
> 

What you're talking about essentially results in a @world set which
varies depending on the context. I'm not so sure that's a good idea. I'm
inclined to suggest that you just use a different profile for each
context (like the stage3 profile that I suggested in my reply to Ian).
-- 
Thanks,
Zac

Re: [gentoo-dev] ironing out release tarballs

[Zac Medico]

On 10/15/2015 02:51 PM, Anthony G. Basile wrote:
> On 10/15/15 5:20 PM, Zac Medico wrote:
>> On 10/15/2015 02:13 PM, Mike Frysinger wrote:
>>
>> so if iputils is in @profile, and i do:
>> emerge -C iputils
>> i don't get the ugly warning about it being in @system, but if i do:
>> emerge @world
>> iputils comes back.  i think that's OK actually since people can do:
>> emerge @selected
>> which has the classic @world meaning.
>> -mike
>>
>> People need to be able to use @world without it pulling in unwanted
>> packages, since it's the only way to properly do a full update of all
>> relevant packages (relevant packages being those that would not be
>> removed by depclean).
> But that's true of @system packages now.  If a user does `emerge -C
> iputils` they get a warning about it being in the system set and when
> they do `emerge @world` it comes back. 

I think it's obvious that such packages don't belong in @system, unless
we're talking about a profile where iputils is absolutely required for
some reason.

> The only change in moving it to @profile is the warning.

What's the point of getting rid of the warning if the package is going
to get pulled back in on the next @world update? Either way, the end
result it that the user has to go through some hoops
(/etc/portage/profile overrides) if they don't want that package
installed again.

>  Also, I think the other change is during the
> building of the /tmp/stage1root during stage1, @system won't include
> iputils and this saves on the number of packages built.

The last time I checked, @system was not used for stage1. Catalyst used
package.build instead. Has that changed?
-- 
Thanks,
Zac

Re: [gentoo-dev] ironing out release tarballs

[Zac Medico]

On 10/15/2015 01:06 PM, Anthony G. Basile wrote:
> On 10/15/15 3:15 PM, Zac Medico wrote:
>>
>> In portage, @world = @profile + @selected + @system, which means that
>> @profile is protected from depclean since it's a part of @world.
>>
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=532224
> 
> I thought so but wasn't sure and was about to test.  Both @system and
> @profile are controlled via the packages file in portage and stack. 
> Packages in @system lead with an * while @profile don't. @system
> packages have incomplete dependency specifications while @profile have
> full.

Right.

> This affects more than just emerge's ability to parallelize, no?

Having complete dependency specifications could be useful for some other
things, but allowing for more aggressive parallelization is one of the
most obvious advantage.
-- 
Thanks,
Zac

Re: [gentoo-dev] ironing out release tarballs

[Anthony G. Basile]

On 10/15/15 4:14 PM, Zac Medico wrote:

On 10/15/2015 01:06 PM, Anthony G. Basile wrote:

On 10/15/15 3:15 PM, Zac Medico wrote:

In portage, @world = @profile + @selected + @system, which means that
@profile is protected from depclean since it's a part of @world.

[1] https://bugs.gentoo.org/show_bug.cgi?id=532224

I thought so but wasn't sure and was about to test.  Both @system and
@profile are controlled via the packages file in portage and stack.
Packages in @system lead with an * while @profile don't. @system
packages have incomplete dependency specifications while @profile have
full.

Right.


This affects more than just emerge's ability to parallelize, no?

Having complete dependency specifications could be useful for some other
things, but allowing for more aggressive parallelization is one of the
most obvious advantage.


Okay, good because that fits my understanding of how we'd be dividing 
@system from @profile.


@system = the bare set that we need in an stage3 in order to build 
another stage3 via the catalyst process.  so the way this works is that 
you unpack a stage3, chroot into it, and then do a `ROOT=/some/new/root 
emerge @system` to prepare a pristine new root.  that root then seeds 
your stage2 at which point your rebuild your toolchain.  then that seeds 
your new stage3 in which you rebuild @system.


So that defines @system from the point of view of using a current stage3 
to give birth to a next generation stage3.  But that may not be what you 
want to release, eg. do you need any networking stuff in there?  This 
gave birth to the idea of a stage4 which would have the added goodies 
needed for an end user to grow a system from our release tarball.  
vapier is suggesting using @profile for the extra needed beyond @system 
for the release.  So at all points except the very end, you just use 
@system for building because that's all you need, and then finally you 
produce an @system+@profile for release.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] ironing out release tarballs

[Rich Freeman]

On Thu, Oct 15, 2015 at 6:00 PM, Zac Medico  wrote:
> On 10/15/2015 02:51 PM, Anthony G. Basile wrote:
>
>> The only change in moving it to @profile is the warning.
>
> What's the point of getting rid of the warning if the package is going
> to get pulled back in on the next @world update? Either way, the end
> result it that the user has to go through some hoops
> (/etc/portage/profile overrides) if they don't want that package
> installed again.

++

I think just pre-seeding the world file is a simpler solution.  Users
can just uninstall the files normally then.


-- 
Rich

Re: [gentoo-dev] ironing out release tarballs

[Anthony G. Basile]

On 10/15/15 6:00 PM, Zac Medico wrote:

.
The last time I checked, @system was not used for stage1. Catalyst used
package.build instead. Has that changed?
Sorry, yes it is.  I forgot how that file was interpreted.  I was 
thinking when I wrote my previous emails that it contained a list of 
packages in addition to @system, but its actually the full stage1 list, 
and packages.build files stack, so that (for example) my


default/linux/uclibc/packages.build

builds on top of the list in

default/linux/packages.build

For the full stage1 list of uclibc stages.

Anyhow, I like the direction Rich and you are going in with 
packages.stage3.  Can we call it something else though, like 
packages.world.  :)


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] ironing out release tarballs

[Zac Medico]

On 10/15/2015 02:03 PM, Rich Freeman wrote:
> On Thu, Oct 15, 2015 at 4:57 PM, Zac Medico  wrote:
>> Given the goals, having catalyst seed /var/lib/portage/world seems
>> pretty reasonable to me.
> 
> Then the question becomes how.  Does it diff @profile between the two
> profiles and put the extra stuff in @selected?  Or, does the profile
> just contain a special file containing the stuff that gets seeded?
> That is really the gist of the two approaches, and if you just have a
> special file full of stuff that gets seeded you really don't need
> another profile, which is nice since profiles are a PITA right now.
> 

We already have packages.build which is used to build stage1, so
introducing a packages.stage3 that's used to seed @selected (aka
/var/lib/portage/world) for stage3 seems reasonable.
-- 
Thanks,
Zac

Re: [gentoo-dev] ironing out release tarballs

[Anthony G. Basile]

For some reason I didn't receive the original email from Mike.  I'll 
answer via Rich's email. Hopefully I won't be misinterpreting anything.


On 10/15/15 1:43 PM, Rich Freeman wrote:

On Thu, Oct 15, 2015 at 11:34 AM, Mike Frysinger  wrote:

items to sort out:
- should the list of packages be in catalyst or profile-stacked content
-> imo it should be entirely in the profile

++

This would be really nice to combine with mix-ins so that instead of
special cases we could just use additional profiles (without the
normal cost of additional profiles), but absent that the approach you
have below seems fine.


I assume you're talking about the list of packages in each stage.  I 
would like them entirely in the profile.  This gives the profile 
maintainer control and I need that for some of the more exotic stuff I 
work on.



- should the packages list be in a new packages.default, or should we create a
   new set to hold it, or should we just go with @profile ?
-> @profile has the advantage of already existing.  we have to be careful so as
to make it difficult to uninstall packages that the user does not actually
want.

I would be interested in use cases for @profile OTHER than convenience
packages (sshd, screen, etc).

Again, this is a case where having more profiles would get rid of the
need to have a compromise.  Just make it @profile, and be sure to have
a profile available that doesn't have any packages beyond @system.

However, if some profiles really do need to install fairly critical
packages then maybe we should also have a packages.default in addition
to @profile.


Why would we need a new packages.default or @newset?  @profile should be 
enough.  I guess I'm not sure how packages.default would work 
differently than @profile?  What would it add?





- if the packages aren't in @profile, should they be seeded in @world ?
-> imo yes as  we don't want all the default packages getting depcleaned as
soon as you start using the new install.  if they're in @profile, then this
is a moot point (assuming depclean does not clean out @profile).

If we end up with @system+@profile+packages.default then I'd say that
packages.default gets seeded in @world.  @profile becomes difficult to
uninstall.  This should be the solution if some profiles really do
need to add essential packages as well as convenience packages, but
the essential packages aren't assumed dependencies.

If we end up with just @system+@profile then I'd say that packages in
@profile get seeded in @world, and thus nothing special needs to be
done to uninstall them.  This should be done if there aren't essential
profile packages.


i'm happy with having them in @profile and making sure that depclean 
doesn't clear @profile.





- should stage3 be @system only, or @system+@profile, or
   @system+@profile+packages.default ?
-> this depends on the previous discussion a bit.  today, stage3's are
@system, but imo @system+@profile is reasonable.  see next question too.

Agree it depends on the previous outcome.


Answer to this and next.  stage3 should be @system+@profile (again I'm 
sure what packages.default would add).   I see little value in a stage3 
which is @system only followed by a stage4 which is @system+@profile.



- should we release stage4's instead of stage3's ?
-> if we keep stage3 as @system-only, then we'd build stage4's which would add
@profile/whatever
-> downside is that we've been training the world to download & install stage3
for almost 15 years
-> imo as long as the default @profile is kept slim, adjusting the definition of
a stage3 is OK


I'm in agreement with your last statement, let's just adjust the 
definition of stage3 and keep @profile slim.  Its a lot of work to fix 
up our documentation to read stage4 instead of stage3 with little gain 
in my opinion.  And users could be confused.


If we really needed a stage with just @system, we could add some 
catalyst flag that produced a stage2.5 instead of a stage3.  So a 
typical run could be stage1 -> stage2 -> stage3 (where stage3 means 
@system+@profile) and optionally stage1 -> stage2 -> stage2.5 -> stage3.



I don't have a strong opinion on this.  I don't see the need to
maintain separate stage3s in addition to the stage4s, so we're just
arguing semantics.

I think the real question I have is what would the @profile set be
used for OTHER than convenience packages?  While I did mention mix-ins
as being a better long-term solution I'm not suggesting that we should
hold off on a reasonable interim solution until we work that out.
Without mix-in support we don't really want to add more profiles,
which is the other way to go with this.




--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] ironing out release tarballs

[Anthony G. Basile]

On 10/15/15 5:20 PM, Zac Medico wrote:

On 10/15/2015 02:13 PM, Mike Frysinger wrote:

so if iputils is in @profile, and i do:
emerge -C iputils
i don't get the ugly warning about it being in @system, but if i do:
emerge @world
iputils comes back.  i think that's OK actually since people can do:
emerge @selected
which has the classic @world meaning.
-mike

People need to be able to use @world without it pulling in unwanted
packages, since it's the only way to properly do a full update of all
relevant packages (relevant packages being those that would not be
removed by depclean).
But that's true of @system packages now.  If a user does `emerge -C 
iputils` they get a warning about it being in the system set and when 
they do `emerge @world` it comes back.  The only change in moving it to 
@profile is the warning.  Also, I think the other change is during the 
building of the /tmp/stage1root during stage1, @system won't include 
iputils and this saves on the number of packages built.


--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] ironing out release tarballs

[Alexis Ballier]

On Thu, 15 Oct 2015 11:34:22 -0400
Mike Frysinger  wrote:

> background:
> everyone wants @system to be slim, but most people want the initial
> stage tarball that we release and you install Gentoo from to not be
> completely sparse.  we've got a bug for this topic:
> https://bugs.gentoo.org/393445
> 
> items to sort out:
> - should the list of packages be in catalyst or profile-stacked
> content -> imo it should be entirely in the profile  

fully agree

> - should the packages list be in a new packages.default, or should we
> create a new set to hold it, or should we just go with @profile ?
> -> @profile has the advantage of already existing.  we have to be
> careful so as to make it difficult to uninstall packages that the
> user does not actually want.
> 
> - if the packages aren't in @profile, should they be seeded in
> @world ? -> imo yes as  we don't want all the default packages
> getting depcleaned as soon as you start using the new install.  if
> they're in @profile, then this is a moot point (assuming depclean
> does not clean out @profile).

some kind of 'world' file in profiles like the 'packages' one that is
just used to populate world file after (or just before) stage3 build ?

not sure if sets provide the same flexibility: i can imagine iputils in
that set, but also another embedded profile with
busybox[make-symlinks], or the bsds

> - should stage3 be @system only, or @system+@profile, or 
>   @system+@profile+packages.default ?
> -> this depends on the previous discussion a bit.  today, stage3's
> are @system, but imo @system+@profile is reasonable.  see next
> question too.
> 
> - should we release stage4's instead of stage3's ?
> -> if we keep stage3 as @system-only, then we'd build stage4's which
> would add @profile/whatever
> -> downside is that we've been training the world to download &
> install stage3 for almost 15 years
> -> imo as long as the default @profile is kept slim, adjusting the
> definition of a stage3 is OK

i also think it's better to adjust stage3 if it is kept relatively slim,
but i'm pretty sure there'll be demand for @system only stages

Alexis.

Re: [gentoo-dev] call for testers (obscure cgroups bugs in OpenRC)

[William Hubbs]

On Thu, Oct 15, 2015 at 11:17:39AM -0500, William Hubbs wrote:
> All,
> 
> There are some very obscure cgroups related bugs in OpenRC which I have
> never been able to reproduce [1] [2] [3].

Disregard the second bug, it is a documentation issue possibly, but the
first and third bugs are the ones to test.

William


signature.asc
Description: Digital signature

[gentoo-dev] Re: [PATCH] cmake-utils.eclass: die if ninja is enabled but not installed

[Michael Palimaka]

On 16/10/15 03:04, Michał Górny wrote:
> 
> 
> Dnia 15 października 2015 17:44:47 CEST, Michael Palimaka 
>  napisał(a):
>> This could happen if ninja is manually enabled (eg. make.conf) but not
>> installed
>> ---
>> eclass/cmake-utils.eclass | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
>> index 480cd09..012b13f 100644
>> --- a/eclass/cmake-utils.eclass
>> +++ b/eclass/cmake-utils.eclass
>> @@ -228,6 +228,11 @@ _generator_to_use() {
>>
>>  case ${CMAKE_MAKEFILE_GENERATOR} in
>>  ninja)
>> +# if ninja is enabled but not installed, the build 
>> could fail
>> +# this could happen if ninja is manually enabled (eg. 
>> make.conf)
>> but not installed
>> +if ! has_version dev-util/ninja; then
> 
> I'd suggest avoiding has_version and just checking for the binary. type -P, I 
> think. Ciaran can give you the rationale, I believe.

There's no guarantee that the binary will be provided by dev-util/ninja
(we've had a bug about this already).

Re: [gentoo-dev] ironing out release tarballs

[Mike Frysinger]

On 15 Oct 2015 19:01, Alexis Ballier wrote:
> On Thu, 15 Oct 2015 11:34:22 -0400 Mike Frysinger wrote:
> > - should the packages list be in a new packages.default, or should we
> > create a new set to hold it, or should we just go with @profile ?
> > -> @profile has the advantage of already existing.  we have to be
> > careful so as to make it difficult to uninstall packages that the
> > user does not actually want.
> > 
> > - if the packages aren't in @profile, should they be seeded in
> > @world ? -> imo yes as  we don't want all the default packages
> > getting depcleaned as soon as you start using the new install.  if
> > they're in @profile, then this is a moot point (assuming depclean
> > does not clean out @profile).
> 
> some kind of 'world' file in profiles like the 'packages' one that is
> just used to populate world file after (or just before) stage3 build ?

i suggested the name "packages.default" originally to convey the notion
that it's just the default set of packages (you'd find in a release).
keeping the "packages." prefix seemed to be better namespace wise.

doesn't require a PMS update because only releng tools (catalyst) would
read it.  set integration would have to conform to PMS.

> not sure if sets provide the same flexibility: i can imagine iputils in
> that set, but also another embedded profile with
> busybox[make-symlinks], or the bsds

i'm not sure putting USE flag qualifiers makes sense as the next time the
package updates, the USE flags will change.  if profiles want to default
USE flags, the existing package.use makes more sense imo.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] ironing out release tarballs

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/10/15 03:15 PM, Zac Medico wrote:
> On 10/15/2015 08:34 AM, Mike Frysinger wrote:
>> background: everyone wants @system to be slim, but most people
>> want the initial stage tarball that we release and you install
>> Gentoo from to not be completely sparse.  we've got a bug for
>> this topic: https://bugs.gentoo.org/393445
>> 
>> items to sort out: - should the list of packages be in catalyst
>> or profile-stacked content -> imo it should be entirely in the
>> profile
>> 
>> - should the packages list be in a new packages.default, or
>> should we create a new set to hold it, or should we just go
>> with @profile ? -> @profile has the advantage of already
>> existing.  we have to be careful so as to make it difficult to
>> uninstall packages that the user does not actually want.
> 
> In portage, the current meaning of @profile is very similar to
> @system, except that it implies that members specify dependencies
> completely (allowing for optimal parallelization) [1]. The
> @profile set is only enabled for profiles from repositories that
> have "profile-formats = profile-set" set in metadata/layout.conf.
> It's an extension which is not covered by PMS.
> 
>> - if the packages aren't in @profile, should they be seeded in
>> @world ? -> imo yes as  we don't want all the default packages
>> getting depcleaned as soon as you start using the new install.
>> if they're in @profile, then this is a moot point (assuming
>> depclean does not clean out @profile).
> 
> In portage, @world = @profile + @selected + @system, which means
> that @profile is protected from depclean since it's a part of
> @world.
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=532224
> 


So just to clarify..  if we start adding these packages that are
removed from @system into @profile, what do we gain here?  They'll
exist in the stage3's (which is one of the goals right?), and
they'll be included in @world without entries in
/var/lib/portage/world (so end-users will have them on their
systems)..  Seems like everything would be the same as if they were
in @system, except 'emerge -e @system' wouldn't rebuild them..? Do
we get the advantage(s) we were looking for, going this route?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYf/rUACgkQAJxUfCtlWe3dWQEAlo+oBK+uyzRf+fzF2o17skMS
0438JShMlObzWOkgZYYA/R65hZUl7enVItRWvzqPSP0qfKLjmXjCWcJiuepBBoRl
=1fJ6
-END PGP SIGNATURE-

Re: [gentoo-dev] [rfc] enable USE=xattr by default

[Mike Gilbert]

On Thu, Oct 15, 2015 at 8:36 AM, Rich Freeman  wrote:
> On Thu, Oct 15, 2015 at 7:58 AM, Alexander Tsoy  wrote:
>>
>> I was wrong. This patch was not merged upstream. It is still needed and
>> included in latest genpatches for 4.2:
>>
>> $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
>> ./1500_XATTR_USER_PREFIX.patch
>
> I suspect what we all have in common then is that we're using tmpfs to
> do builds and we're not using genpatches.
>
> If the warning isn't an issue for non-hardened users then I don't see
> any need to change anything.  Is the patch (or something similar)
> likely to get merged?  It doesn't really seem ideal to be dependent on
> something not in mainline.

Indeed. I would suggest we at least disable XT PaX markings in the
base profile until this gets merged in the mainline kernel.

Re: [gentoo-dev] ironing out release tarballs

[Zac Medico]

On 10/15/2015 08:34 AM, Mike Frysinger wrote:
> background:
> everyone wants @system to be slim, but most people want the initial stage
> tarball that we release and you install Gentoo from to not be completely
> sparse.  we've got a bug for this topic:
> https://bugs.gentoo.org/393445
> 
> items to sort out:
> - should the list of packages be in catalyst or profile-stacked content
> -> imo it should be entirely in the profile
> 
> - should the packages list be in a new packages.default, or should we create a
>   new set to hold it, or should we just go with @profile ?
> -> @profile has the advantage of already existing.  we have to be careful so 
> as
>to make it difficult to uninstall packages that the user does not actually
>want.

In portage, the current meaning of @profile is very similar to @system,
except that it implies that members specify dependencies completely
(allowing for optimal parallelization) [1]. The @profile set is only
enabled for profiles from repositories that have "profile-formats =
profile-set" set in metadata/layout.conf. It's an extension which is not
covered by PMS.

> - if the packages aren't in @profile, should they be seeded in @world ?
> -> imo yes as  we don't want all the default packages getting depcleaned as
>soon as you start using the new install.  if they're in @profile, then this
>is a moot point (assuming depclean does not clean out @profile).

In portage, @world = @profile + @selected + @system, which means that
@profile is protected from depclean since it's a part of @world.

[1] https://bugs.gentoo.org/show_bug.cgi?id=532224
-- 
Thanks,
Zac

Re: [gentoo-dev] ironing out release tarballs

[Rich Freeman]

On Thu, Oct 15, 2015 at 11:34 AM, Mike Frysinger  wrote:
>
> items to sort out:
> - should the list of packages be in catalyst or profile-stacked content
> -> imo it should be entirely in the profile

++

This would be really nice to combine with mix-ins so that instead of
special cases we could just use additional profiles (without the
normal cost of additional profiles), but absent that the approach you
have below seems fine.

>
> - should the packages list be in a new packages.default, or should we create a
>   new set to hold it, or should we just go with @profile ?
> -> @profile has the advantage of already existing.  we have to be careful so 
> as
>to make it difficult to uninstall packages that the user does not actually
>want.

I would be interested in use cases for @profile OTHER than convenience
packages (sshd, screen, etc).

Again, this is a case where having more profiles would get rid of the
need to have a compromise.  Just make it @profile, and be sure to have
a profile available that doesn't have any packages beyond @system.

However, if some profiles really do need to install fairly critical
packages then maybe we should also have a packages.default in addition
to @profile.

>
> - if the packages aren't in @profile, should they be seeded in @world ?
> -> imo yes as  we don't want all the default packages getting depcleaned as
>soon as you start using the new install.  if they're in @profile, then this
>is a moot point (assuming depclean does not clean out @profile).

If we end up with @system+@profile+packages.default then I'd say that
packages.default gets seeded in @world.  @profile becomes difficult to
uninstall.  This should be the solution if some profiles really do
need to add essential packages as well as convenience packages, but
the essential packages aren't assumed dependencies.

If we end up with just @system+@profile then I'd say that packages in
@profile get seeded in @world, and thus nothing special needs to be
done to uninstall them.  This should be done if there aren't essential
profile packages.

>
> - should stage3 be @system only, or @system+@profile, or
>   @system+@profile+packages.default ?
> -> this depends on the previous discussion a bit.  today, stage3's are
>@system, but imo @system+@profile is reasonable.  see next question too.

Agree it depends on the previous outcome.

>
> - should we release stage4's instead of stage3's ?
> -> if we keep stage3 as @system-only, then we'd build stage4's which would add
>@profile/whatever
> -> downside is that we've been training the world to download & install stage3
>for almost 15 years
> -> imo as long as the default @profile is kept slim, adjusting the definition 
> of
>a stage3 is OK

I don't have a strong opinion on this.  I don't see the need to
maintain separate stage3s in addition to the stage4s, so we're just
arguing semantics.

I think the real question I have is what would the @profile set be
used for OTHER than convenience packages?  While I did mention mix-ins
as being a better long-term solution I'm not suggesting that we should
hold off on a reasonable interim solution until we work that out.
Without mix-in support we don't really want to add more profiles,
which is the other way to go with this.

-- 
Rich

[gentoo-portage-dev] gentoolkit.git repository reorganized

[Paul Varner]

All:

Due to historical reasons the gentoolkit git repository was organized
with two branches, gentoolkit and gentoolkit-dev with master effectively
being an empty branch.  This was confusing to contributers and with git
did not make a lot of sense.  Over the last couple of days, I have done
the following:

1. Migrated the gentoolkit-dev branch to its own gentoolkit-dev.git
repository
2. Moved the gentoolkit branch to master on the gentoolkit.git repository

The one thing left to do is to remove the gentoolkit-dev branch from the
gentoolkit repository, I'm going to wait for several days to make sure
that there is nothing missing in the gentoolkit-dev repo before removing it.

Due to the nature of the changes to the repos, I've found that it is
easiest to backup the current clone and re-clone the repository to make
sure that everything is up to date with the changes.

Regards,
Paul