Re: [gentoo-dev] REQUIRED_USE, global USE flags, user-friendliness...

2017-02-03 Thread Christopher Head
On Sun, 29 Jan 2017 15:11:43 +0100
Róbert Čerňanský  wrote:

> If I may add a user opinion.  I agree with you but I would choose
> different solution for user-friendliness.  Instead of _adding_
> interactivity to PM I would _remove_ it.  So if there would be
> multiple choices the user would not be prompted, but some default
> option would be selected by PM.  To the user, such behaviour would be
> similar to current handling of virtuals - if a package depends on a
> virtual the user is not prompted to make a choice but the default is
> selected instead.

This. Exactly this. In fact, I would go even further. Let’s look at two
parallel situations.

Situation 1: app-cat/foo DEPENDs on dev-libs/bar. I want app-cat/foo. I
emerge app-cat/foo. Portage automatically installs dev-libs/bar. It
doesn’t require me to say anything about dev-libs/bar (though if I ask
to confirm before starting the build then it will mention it). I never
have to add dev-libs/bar to any user-maintained files
(i.e. /etc/portage/* or /var/lib/portage/world). If I ever uninstall
app-cat/foo, then dev-libs/bar will go away on its own when I depclean.

Situation 2: app-cat/foo DEPENDs on dev-libs/bar[baz]. I want
app-cat/foo. I emerge app-cat/foo. Portage… fails. It requires me to
manually add “dev-libs/bar baz” to /etc/portage/package.use/* (it will
do it itself, if desired, due to autounmask, but of course it puts it
in the wrong file because I like to keep things organized with multiple
files). That setting goes on living in /etc/portage, a user-maintained
area, forever. If I ever uninstall app-cat/foo, baz will stay set until
I eventually get around to slogging through /etc/portage/package.use
looking for things I can turn off because I don’t need them any more.

Why? It’s just another dependency. Why does DEPEND="dev-libs/bar" work
so beautifully but DEPEND="dev-libs/bar[baz]" work so horribly? If I
haven’t explicitly said I want baz, and I haven’t explicitly said I
*don’t* want baz, and enabling baz doesn’t conflict with any other
packages I have installed, Portage should just rebuild dev-libs/bar
with USE=+baz. If I eventually uninstall app-cat/foo, something like
depclean should reinstall dev-libs/bar with USE=-baz. Just like all the
other dependencies, if I don’t care to make a manual choice, it should
be automatic and dynamic.
-- 
Christopher Head


pgpdkiVtAMXgB.pgp
Description: OpenPGP digital signature


[gentoo-dev] RFC: Introducing stable profiles for arm64 (aarch64)

2017-02-03 Thread Mart Raudsepp
Hello,

I am working towards having a clean deptree for arm64 and afterwards
marking the non-hardened 5 arm64 profiles stable (or 4 - I don't see
value in the developer profile without the desktop specific
subprofiles, until there are mix-ins).

This e-mail is meant to make sure there are no other pre-requisites for
just flipping the switch in profiles.desc from exp to stable, and to
express that intent and garner any hands-on help.

Also some eyes on the profiles (profiles/arch/arm64/*) would be useful,
especially from those who knows how all these CHOST/LIBDIR and other
things need to be, to make sure these are all right before the profiles
go stable.


Currently my plan is to solve all the deptree issues by mostly stable
use masks where needed (the stage building stable keywords haven't kept
the deptree in mind so far, just for what USE flags are enabled for
stage building), and keywording ~arm64 or use.mask/package.use.mask'ing
to fix the ~arm64 deptree too (depending on if I want it keyworded
immediately, or delay for future consideration and fix the deptree by
use masks till then).
I'm having the CI hamsters spin for this at
https://github.com/gentoo/gentoo/pull/3622

Yes, there is quite some work to do, but this e-mail is meant to get
any necessary formalities out of the way in parallel, so we can get the
switch flipped right after instead of discussing it then, and not
continue a chasing game due to repoman not telling to file a KEYWORDREQ
for us for new deps.

Note that there is no arm64 project as of yet, it's been worked on to
some capacity as part of arm project, which I believe to be a bit
confusing (albeit similar to ppc/ppc64), but also a bit daunting with
the arm4/5/6/7/vfp/neon/etc combination explosion stuff in arm32 land
(so I think it's good to have a clean break there with project
documentation pages, people involvement, etc). I haven't been able to
convince steev as of yet about this and haven't exercised any project
creation rights myself yet :D


Mart

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


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Patrick McLean
On Fri, 3 Feb 2017 19:59:34 -0500
Ian Stakenvicius  wrote:

> On 03/02/17 02:37 PM, Michael Orlitzky wrote:
> > On 02/03/2017 10:30 AM, Ian Stakenvicius wrote:  
> >>
> >> ok you lost me.  Could you provide an explicit example of what you
> >> would want to see enabled in the profile (while everything else is
> >> disabled) that you don't get when USE="-*" is set?  
> > 
> > USE="hardened pax_kernel ..."
> >   
> 
> ok, so global flags that are never modified via IUSE defaults.  It
> still looks to me like all you need to do to get what you want is swap
> the order of 'conf' and 'defaults' in USE_ORDER? (man make.conf)
> 
> > 
> > I don't want to turn off all IUSE defaults. Since we have no policy
> > on what IUSE defaults should be used for, half of them are
> > important, and the other half are junk. I don't want to disable the
> > ones that are critical for the package to function, and I don't
> > want to disable the ones that satisfy an (otherwise unsatisfied)
> > REQUIRED_USE constraint. 
> 
> And herein lies the crux.  "Junk" is your definition, but it's not
> necessarily the maintainer's definition.  "Critical for the package to
> function" is entirely dependent on what you expect to use the package
> for.  If you want to disable everything optional then USE="-*" will do
> that, and really all you should be losing is the ability to have
> REQUIRED_USE auto-resolve based on the IUSE defaults that are set.
> However, even in that case, it seems likely that you may well want to
> use a different option to resolve a REQUIRED_USE conflict to ensure
> your minimalist install than is the default that the maintainer
> provided.
> 

I think the current policy of "maintainer's discretion" is probably the
only reasonable way to approach IUSE defaults. Attempting to dictate
some policy based on differing definitions of what is acceptable or not
is just a path to a lot of pain for very little gain. I don't think
that there are a very large proportion of people who want some sort of
"minimal" system, sacrificing basic, expected functionality (as say
"-readline" on app-shells/bash would do) in the default configuration
.
Leaving the IUSE defaults up to the maintainer allows said maintainer
to select what they consider reasonable defaults.



Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Ian Stakenvicius
On 03/02/17 02:37 PM, Michael Orlitzky wrote:
> On 02/03/2017 10:30 AM, Ian Stakenvicius wrote:
>>
>> ok you lost me.  Could you provide an explicit example of what you
>> would want to see enabled in the profile (while everything else is
>> disabled) that you don't get when USE="-*" is set?
> 
> USE="hardened pax_kernel ..."
> 

ok, so global flags that are never modified via IUSE defaults.  It
still looks to me like all you need to do to get what you want is swap
the order of 'conf' and 'defaults' in USE_ORDER? (man make.conf)

> 
> I don't want to turn off all IUSE defaults. Since we have no policy on
> what IUSE defaults should be used for, half of them are important, and
> the other half are junk. I don't want to disable the ones that are
> critical for the package to function, and I don't want to disable the
> ones that satisfy an (otherwise unsatisfied) REQUIRED_USE constraint.
> 

And herein lies the crux.  "Junk" is your definition, but it's not
necessarily the maintainer's definition.  "Critical for the package to
function" is entirely dependent on what you expect to use the package
for.  If you want to disable everything optional then USE="-*" will do
that, and really all you should be losing is the ability to have
REQUIRED_USE auto-resolve based on the IUSE defaults that are set.
However, even in that case, it seems likely that you may well want to
use a different option to resolve a REQUIRED_USE conflict to ensure
your minimalist install than is the default that the maintainer provided.





signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Kent Fredric
On Thu, 2 Feb 2017 18:01:54 -0600
Gordon Pettey  wrote:

> If you want to keep this kind of thing in the ebuilds, IUSE="+blah" doesn't
> allow any granularity. Another variable USE_PROFILE should be added
> analogue to DEPENDS:
> IUSE="gnome-keyring gtk-theme kwallet pulseuadio qt-theme
> annoyingUpstreamDefault"
> USE_PROFILE="
> desktop? ( pulseaudio )
> gtk? ( gtk-theme )
> gnome? ( @gtk gnome-keyring)
> kde? ( @qt kwallet )
> qt? ( qt-theme )
> upstream? ( annoyingUpstreamDefault )
> "

This is the way I'd suggest going as well. Mostly, because needless 
double-accounting
by communicating this same information to a global profile seems like creating
work without benefit.

I'd probably suggest something like this, but with a restriction that every
"foo?" on the left hand side being a defined global term.

Especially considering that USE="-*" doesn't necessarily give you "less 
dependencies",
in the case of dev-util/pkgconfig, USE="-*" aligns with the existing (default) 
mechanic
of USE="-internal-glib", and so a "minimal system" would either 

a. Prefer dev-util/pkgconf which doesn't require glib at all ( bug #606260 [1] )

b. Prefer USE="internal-glib"

Clearly given bug #606260, our current mechanism of following upstream defaults
is not ideal for minimal systems, even though its fine for 99.99% of users.

Hence, I'd prefer something akin to:

virtual/pkgconfig: 

RDEPEND="
 profile:minimal? ( 
|| ( dev-util/pkgconf dev-util/pkgconfig[internal-glib] 
dev-util/pkgconfig )
 )
 +profile:upstream? (
|| ( dev-util/pkgconfig dev-util/pkgconf )
 )
"

Granted here I'm stepping slightly outside the conversation of USE defaults, 
because
this is a related system where the concepts of defaults are present, but are 
instead
regulated by implicit controls based on what the user has already decided to 
install.

And this example suggested usage is a bit dodgy because it could be abused by 
people
using profiles instead of useflags to control behaviour.

However:

IUSE="minimal"
IUSE_PROFILES="
minimal? ( minimal )
"
RDEPEND="
 minimal? ( 
|| ( dev-util/pkgconf dev-util/pkgconfig[internal-glib] 
dev-util/pkgconfig )
 )
 !minimal? (
|| ( dev-util/pkgconfig dev-util/pkgconf )
 )
"

Would be less abusey.

Also, this approach in general means instead of needing repoman to compute the 
interaction
of  x  for all(@profiles), it only needs to compute the 
interactions
for Profile X x Profile Y for union(x.profiles y.profiles)

( Though personally I don't think repoman needs to compute anything for 
defaults,
  I just saw somebody else mention this in a different part of this thread and 
it confused
  me. However, it *could* be useful to be able to ensure cohesion within a 
single chosen
  profile name, being able to state "If you set your profile to X and don't 
change anything
  in package.use, everything that has profile X will be installable as-is" )

And this of course brings into observation my favourite negative-useflag,
for which USE="-*" will have the opposite effect to that you intend.

__ SIMPLIFIED __ 

# May contain only the possible useflags, not setting defaults 
IUSE=""

# A list of "profilename ? ( assumed defaulted on flags )"
# where "profilename" must be a defined profile ID
# "profilename" can have a "+" to indicate it is the default profile
# if none of the others listed in IUSE_PROFILES matches a user description

IUSE_PROFILES="" 


> @ is already used for sets, so "some other use_profile's set of defined
> flags" seems reasonable. It should be additive only, so no +- prefixes
> needed (or allowed). If a package is emerged without any USE_PROFILE set,
> you might einfo "This package supports was emerged with no use profile. It
> supports blah1, blah2, and blah3. Upstream recommends blah2." USE_PROFILE
> should never have any default selected by an ebuild; if a flag is required
> to build, is shouldn't be a flag. You get independent behavior per package
> rather than listing every single package that ever existed in
> profile/package.use, package behavior actually being with the package
> instead of global profiles, and you get rid of the mess of uncustomizable
> IUSE="+something" everywhere that makes people like me tend to start off
> every new Gentoo install with echo "USE=\"-*\"" >> /etc/portage/make.conf.
> Just need to come up with sane naming convention for common possibilities
> like kde, gnome, and generic desktop.

Personally, I think encouraging people to set profiles on a per-package level
fights the cause of this feature in ways that should be governed by USE flags.

The real utility of profile-governed defaults is that you should select a given
profile, and *everything* should work out of the box *without* needing to change
use flags, and repoman should compute how "my profiles defaults expanded into 
dependencies"
would introduce a need to change USE flags on dependencies, and should raise

Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread William L. Thomson Jr.
On Friday, February 3, 2017 2:53:59 PM EST Michael Orlitzky wrote:
> On 02/03/2017 01:33 PM, Patrick McLean wrote:
> > We might as well go back to before IUSE defaults then. Part of the
> > advantage of IUSE defaults is maintainers don't all have to fiddle with
> > the profiles, everything can be self-contained in the ebuild. This
> > drastically complicates maintenance, having two locations to track and
> > change rather than just one.
> 
> You still retain the benefit for IUSE defaults that actually belong in
> the base profile, just not for upstream defaults or the ones that you
> personally prefer.

That is a side effect, as it is more about the package maintainer choosing the 
defaults. They are not messing with profiles. That base ends up with it is 
indirect. Otherwise IUSE default flags would have to be per profile rather than 
in the package. Which would create more work for package maintainers.

> > I suspect that there is a small subset
> > of people interested in this, and perhaps those people could maintain a
> > "minimal" profile that unsets IUSE defaults.
> 
> Then every IUSE default gets recorded twice: once when the maintainer
> puts it in the ebuild, and once when I add it (negated) to the minimal
> profile. That's a bad design even if we pretend that I can solve the
> problem of tracking every IUSE change in the tree.

Sorry if its been suggested, I haven't followed every comment. What about some 
global env variable that could override all default IUSE. That can set in 
base, and set what ever minimal IUSE flags that are needed.

-- 
William L. Thomson Jr.


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


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Michael Orlitzky
On 02/03/2017 01:33 PM, Patrick McLean wrote:
> 
> We might as well go back to before IUSE defaults then. Part of the
> advantage of IUSE defaults is maintainers don't all have to fiddle with
> the profiles, everything can be self-contained in the ebuild. This
> drastically complicates maintenance, having two locations to track and
> change rather than just one.

You still retain the benefit for IUSE defaults that actually belong in
the base profile, just not for upstream defaults or the ones that you
personally prefer.


> I suspect that there is a small subset
> of people interested in this, and perhaps those people could maintain a
> "minimal" profile that unsets IUSE defaults.

Then every IUSE default gets recorded twice: once when the maintainer
puts it in the ebuild, and once when I add it (negated) to the minimal
profile. That's a bad design even if we pretend that I can solve the
problem of tracking every IUSE change in the tree.


> Also, I would just point out that the particular IUSE default that
> you objected to in your original email does not really affect this
> "minimalist" ideal that you seem to hold. The "hpn" USE flag on
> openssh does not actually pull in any extra dependencies, it just
> adds some optimizations to the network code to make it faster.
> 

Yeah, that. OpenSSH is probably the most security-critical package on
our systems. OpenSSH is maintained upstream by a talented team of
security-conscious people. The HPN patch is,

  a) a third-party patch...
  b) that has been rejected by the talented security-conscious team...
  c) and is useless for most people.

So why are we deciding for our users that they must have it?




Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Michael Orlitzky
On 02/03/2017 10:30 AM, Ian Stakenvicius wrote:
> 
> ok you lost me.  Could you provide an explicit example of what you
> would want to see enabled in the profile (while everything else is
> disabled) that you don't get when USE="-*" is set?

USE="hardened pax_kernel ..."

> 
> It's sounding more and more like you just want to be able to turn off
> all IUSE defaults, and you can effectively do that by changing the USE
> order can't you?

I don't want to turn off all IUSE defaults. Since we have no policy on
what IUSE defaults should be used for, half of them are important, and
the other half are junk. I don't want to disable the ones that are
critical for the package to function, and I don't want to disable the
ones that satisfy an (otherwise unsatisfied) REQUIRED_USE constraint.




Re: [gentoo-dev] Re: Requirements for UID/GID management

2017-02-03 Thread Michael Orlitzky
On 02/03/2017 09:51 AM, Martin Vaeth wrote:
> Michael Orlitzky  wrote:
>>
>> The fact that all permission and ownership information is shared is
>> precisely the problem. When you change ownership of the hardlink (which
>> you'll never know is a hardlink), you change ownership of /etc/shadow.
> 
> Why should this be a problem except for a race between reading
> and changing the ownership?
> Admittedly, by using "find ... -exec ... +" the time for an exploit
> of the race is even increased when a "standard" chown command is used.
> 
> However, it is no rocket science to write a race-free chown command
> in C: Just open the file and use stat() and fchown() to be sure to
> change only files from the "correct" user.
> 
> Since this works on the filehandle and not on the filename, I think
> that there is no possibility for an exploit when this is used in the
> above find loop.

Not a bad idea... we chould ship that safe-chown utility, and then tell
users how to use it to fix their UIDs. The draft that I wrote up was for
the "fixed UID with random fallback" model, but said utility could still
be useful for people who want to change their running systems to use the
same UIDs that would have been chosen by default.




Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread james

On 02/03/2017 12:39 PM, james wrote:


 So imagine flags are a giant 'sparse matrix' that  I need to 'mollify'
individually periodically, then run CI on that complete-set of packages,
and then test against automated attack vectors.



So, were we to want to 'enhance' flag representation from a binary
tree form to a sparse matrix, there are many more robust things
we can do. For  those not aware of sparse matrix benefits, they 
basically provide for streamlined solving of large complex problems,

buy using special (matrix tricks) mathematical techniques to reduce
the full, valid set of parameters, into very small sets of smaller 
problems. IMO, very applicable to CI and flag set testing. These sorts 
of theories are trivial to test on minimized systems (huge shout out to 
Walt, as the king of the minimizers!).



For starters, I suggest the package listing (i.e.) the future complete
listing of gentoo packages down the 'Y' (left) axis and the actual flag 
status along the (top) X axis. Left Margin and Top margin 
representations allow the (sub)matrix to be manually viewed as a typical 
2-D table, very convenient. First we can alphabetize this 2-D flag 
matrix for a baseline (base profile) reference matrix.


But, once you start thinking about it, recalling your grammar school 
matrix algebra class, you realized that grouping flags by their myriad 
of heuristical properties, you realize that the aggregate effect of a 
flag is not binary at all, but more akin to a 'fuzzy logic' function. 
For example, cluster up a group of packagers inside the sparse matrix 
that all have the same flag, but it has different meanings, slightly per 
package. Turn that flag (on) for all packages and it has a "staccato" 
effect on the system as a whole. Turn that flag off and it is 
null-effect (at least theoretically). This is how we currently discern 
flag setting meanings, but by manually bumbling around in the dark.



Now, any number of flag activation, per package of that flag may or may 
not have secondary (tertiary etc; kinda  line harmonics on a LaPlace
or Z/s transform) effects on the system as a whole. WE as a community, 
have been ad-hoc tweaking flags and noting the effects, in an 
inconsistent manner, with only anecdotal means to share the result
of those intrinsic flag settings. Alchemy 2,000 years ago was almost 
identical to how we (today) analyze flag effects. Grouping all the 
packages with a given flag, for CI studies allow for row reduction in 
the sparse matrix of flags, as CI runs are amassed into a larger 
collective of heuristical interpretations of such specific flag groupings.



Or that is my latest treaty_proposal, on how to filter a particular 
collection of flag settings and installed packages. I am open to other 
ideas too, as well as traditional regression testing in a hybrid model.



Ultimate flexibility in the profile/flag tree, greatly simplifies the
automation of CI testing and automated results interpretations, imo. So 
hopefully I have sufficiently explained my pathway forward, what I need, 
and how these seemingly disparate issues, are all really just moving 
parts of a much larger (system) need.



At the very least a 100% flexible flag settings/negation, via a profile 
tree and other mechanisms, will not hinder the formation of matrix 
representations of flag configuration sets, which are keenly needed to 
draw reasonable automated conclusions from CI, at least related to flag 
settings and secondary (inter-intra) flag setting interactions.



hth,
James




Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Patrick McLean
On Fri, 3 Feb 2017 08:43:50 -0500
Michael Orlitzky  wrote:

> On 02/03/2017 08:21 AM, Ian Stakenvicius wrote:
> >>
> >> How about rather changing our defaults to satisfy the minimalists
> >> who don't mind drastically reduced functionality and usability in
> >> pursuit of "minimalism" we just strive to make USE="-*" mostly
> >> usable, so the minimalists can get what they want, while still
> >> having sane defaults. 
> > 
> > I'm in favour of this too -- I know we don't "officially" support
> > USE="-*" but I think we should still strive to make it work with
> > minimal effort to end-users -- that effort being mainly setting
> > whatever is necessary for REQUIRED_USE resolution.
> >   
> 
> It will never be easy, because USE="-*" overrides your profile. What
> people want is a way to have USE="-*" apply between the base profile
> and the one that they select.
> 
> This is all easily fixed by creating a new profile one-level above
> base where developers can put their favorite USE flags:
> 
>   1. We create a new empty profile called "penultimate" inheriting
>  from base.
> 
>   2. Update the profiles that inherit from base to inherit from
>  penultimate.
> 
>   3. Move every upstream and maintainer-pet IUSE default into the
>  penultimate profile.
> 
>   4. Make it policy that IUSE defaults should only be used for
>  critical flags and REQUIRED_USE persuasion.
> 
>   5. Now we can create embedded, hardened, etc. profiles that inherit
>  from base and get a minimal working set of USE flags.
> 

We might as well go back to before IUSE defaults then. Part of the
advantage of IUSE defaults is maintainers don't all have to fiddle with
the profiles, everything can be self-contained in the ebuild. This
drastically complicates maintenance, having two locations to track and
change rather than just one.

I don't know that I would agree that making an absolutely "minimal"
build as easy as possible is something that most people want
(especially if it makes maintainership more complicated for a
significant number of packages). I suspect that there is a small subset
of people interested in this, and perhaps those people could maintain a
"minimal" profile that unsets IUSE defaults.

Also, I would just point out that the particular IUSE default that
you objected to in your original email does not really affect this
"minimalist" ideal that you seem to hold. The "hpn" USE flag on
openssh does not actually pull in any extra dependencies, it just
adds some optimizations to the network code to make it faster.



Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread james

On 02/03/2017 01:12 AM, Walter Dnes wrote:

On Thu, Feb 02, 2017 at 01:01:52PM -0500, Rich Freeman wrote


Is there a better way we can have our cake and eat it too?  I'll admit
that a huge package.use on the minimal profile isn't a whole lot
better than a huge package.use on all the other profiles.

Do we need another form of syntax in individual ebuilds to try to
separate out the various cases you cite?  Does anybody care to
actually suggest one?

I still think that we shouldn't encourage users to lightly deviate
from all the upstream defaults.  There are of course legitimate
reasons for doing so, and you and I can probably appreciate when we
should do this, but for somebody starting out we're giving them a lot
of rope to hang themselves with.


  The "case" for IUSE often depends on a fallacious strawman argument
about USE="-*".  The strawman argument is that people run with the USE
variable in make.conf consisting of "USE=-*" and that every package
requires an entry in package.use WRONG! WRONG! WRONG!  That is a braindead
approach.  The way I recommend doing it is...

USE="-* fu bar blah blah blah"

...where commonly-used flags are included in USE.  My rule-of-thumb is

Given that
* not including a flag in USE requires X entries adding it in package.use
* including a flag in USE requires Y entries negating it in package.use

If ( X > Y ) then
   include the the flag in USE
else
   do not include the the flag in USE
end if

  I effectively "build my own profile" rather than depend on multiple
levels of inheritance.  My current desktop runs with the following USE
flags...

USE="X apng bindist ffmpeg jpeg opengl png szip truetype x264 x265 xorg threads webp 
-acl -berkdb -caps -cracklib -crypt -filecaps -gallium -gdbm -graphite -gstreamer -iconv 
-introspection -ipc -iptables -ipv6 -libav -llvm -manpager -nls -openmp -pam -pch 
-sendmail -tcpd -udev -unicode -xinerama"

  Note all the negative flags.  I'll try installing uclibc to a laptop
one of these days.  I figure that it'll probably have a shorter USE line
if I start USE with "-*", and I will not have a larger package.use file.


+1

I've used Gentoo since 2004. I started down the minimal flag path, first 
building iptables-based firewalls on gentoo. So that would be a 
(minimal)base+iptables profile. My historical experience is that flag 
negation has been a "dirty function" over the years; i.e. not consistent
sometimes, across time. That has resulted in a variety of flag negation 
strategies to "tweek" the final results, seemingly more of an art form
with hidden tricks, and a robust (documented) semantic. Most hard to 
track down problems were in the actual packages (ebuild) as we have 
danced across EAPI standards all the way back to no EAPI standards and a 
weak complement of documentation.


This happened because of 'package creep' or just needing/wanting to add 
more and more codes to the firewalls. So now, my firewalls range from 
truly minimal, all the way to enhancements that supercede suricata. So 
imagine flags are a giant 'sparse matrix' that  I need to 'mollify' 
individually periodically, then run CI on that complete-set of packages, 
and then test against automated attack vectors.



With CI, in a stage-4 install, we minimalist could test the our 
collective of (minimized flag) packages and do our own CI. Even perhaps
sharing the result of our CI testing of such minimized systems when a 
gentoo mechanism is available that can handle such massive amounts of 
data. I proposed this (CI-stage-4) a while back in a gentoo-dev thread 
and so here we are, again. Granted, this in-house gentoo-CI work was not 
ready for such wider usage, when I last looked, but it will go a long 
way in providing a robust tool for minimalist. Many are getting into the 
minimalist systems, for security reasons too.


My needs, on the surface, may(maynot) appear to diverge from Walts, but 
I surely hope that whatever the consensus solution is, at least for now, 
it is flexible enough to coalesce all of the various minimalist into the 
same area of the profile tree. We can then share ideas and results of 
testing.


I really need to apologize to many devs. But, I'm getting very close to
having something absolutely wonderful, about 90% thanks to the gentoo
devs. I do not want to appear to be childish throwing a tantrum about
this, but, well, I just really cannot help it; as y'all can imagine?


hth,
James




Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

2017-02-03 Thread Francesco Riosa
2017-02-03 10:52 GMT+01:00 Lars Wendler :

> On Fri, 3 Feb 2017 10:32:30 +0100 Kristian Fiskerstrand wrote:
>
> >On 02/03/2017 10:10 AM, Benda Xu wrote:
> >> William Hubbs  writes:
> >>
> >>> I have been looking at the meson build system [1] [2], and I like
> >>> what I see.
> >>>
> >>> I have opened an issue on OpenRC's github wrt migrating OpenRC to
> >>> the meson build system [3].
> >>>
> >>> As I said on the bug, the downside is the addition of py3 and ninja
> >>> as build time dependencies, but I think the upside (a build system
> >>> where we don't have to worry about parallel make issues or
> >>> portability) outweighs that.
> >>>
> >>> What do folks think here?
> >>
> >> I would discourage it.  Making OpenRC build-depend on python
> >> introduces unnecessary complexity that will undermine the
> >> portability of OpenRC sooner or later.
> >>
> >> After all OpenRC is a small program easy to build with a hand-written
> >> Makefile.
> >>
> >> Parallel make issues?  No problem let's just solve it.
> >>
> >>
> >> Please, keep it simple.
> >
> >I'm adding my support to this sentiment
> >
> >
>
> +1
>
> --
> Lars Wendler
> Gentoo package maintainer
> GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39
>
> Attention! New gpg key! See
> https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html
>

Replay @ random using gmail webmail interface;

May be worth mentioning that also other distro like Alpine Linux uses
openrc, they can be interested


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Ian Stakenvicius
On 03/02/17 08:43 AM, Michael Orlitzky wrote:
> On 02/03/2017 08:21 AM, Ian Stakenvicius wrote:
>>>
>>> How about rather changing our defaults to satisfy the minimalists who
>>> don't mind drastically reduced functionality and usability in pursuit
>>> of "minimalism" we just strive to make USE="-*" mostly usable, so the
>>> minimalists can get what they want, while still having sane defaults. 
>>>
>>
>> I'm in favour of this too -- I know we don't "officially" support
>> USE="-*" but I think we should still strive to make it work with
>> minimal effort to end-users -- that effort being mainly setting
>> whatever is necessary for REQUIRED_USE resolution.
>>
> 
> It will never be easy, because USE="-*" overrides your profile. What
> people want is a way to have USE="-*" apply between the base profile and
> the one that they select.
> 

ok you lost me.  Could you provide an explicit example of what you
would want to see enabled in the profile (while everything else is
disabled) that you don't get when USE="-*" is set?

It's sounding more and more like you just want to be able to turn off
all IUSE defaults, and you can effectively do that by changing the USE
order can't you?





signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Requirements for UID/GID management

2017-02-03 Thread Martin Vaeth
Michael Orlitzky  wrote:
>
> The fact that all permission and ownership information is shared is
> precisely the problem. When you change ownership of the hardlink (which
> you'll never know is a hardlink), you change ownership of /etc/shadow.

Why should this be a problem except for a race between reading
and changing the ownership?
Admittedly, by using "find ... -exec ... +" the time for an exploit
of the race is even increased when a "standard" chown command is used.

However, it is no rocket science to write a race-free chown command
in C: Just open the file and use stat() and fchown() to be sure to
change only files from the "correct" user.

Since this works on the filehandle and not on the filename, I think
that there is no possibility for an exploit when this is used in the
above find loop.




Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Michael Orlitzky
On 02/03/2017 08:21 AM, Ian Stakenvicius wrote:
>>
>> How about rather changing our defaults to satisfy the minimalists who
>> don't mind drastically reduced functionality and usability in pursuit
>> of "minimalism" we just strive to make USE="-*" mostly usable, so the
>> minimalists can get what they want, while still having sane defaults. 
>>
> 
> I'm in favour of this too -- I know we don't "officially" support
> USE="-*" but I think we should still strive to make it work with
> minimal effort to end-users -- that effort being mainly setting
> whatever is necessary for REQUIRED_USE resolution.
> 

It will never be easy, because USE="-*" overrides your profile. What
people want is a way to have USE="-*" apply between the base profile and
the one that they select.

This is all easily fixed by creating a new profile one-level above base
where developers can put their favorite USE flags:

  1. We create a new empty profile called "penultimate" inheriting
 from base.

  2. Update the profiles that inherit from base to inherit from
 penultimate.

  3. Move every upstream and maintainer-pet IUSE default into the
 penultimate profile.

  4. Make it policy that IUSE defaults should only be used for
 critical flags and REQUIRED_USE persuasion.

  5. Now we can create embedded, hardened, etc. profiles that inherit
 from base and get a minimal working set of USE flags.





Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Ian Stakenvicius
On 02/02/17 10:14 PM, Patrick McLean wrote:
> On Thu, 2 Feb 2017 20:40:38 -0500
> Michael Orlitzky  wrote:
> 
>> On 02/02/2017 01:01 PM, Rich Freeman wrote:
>>> On Thu, Feb 2, 2017 at 11:25 AM, Michael Orlitzky 
>>> wrote:  

 If (base == minimal), then all of the upstream defaults need to be
 added to package.use for the upstream-defaults profile. That's
 bad,  
>>>
>>> I'll go further and say that it is unacceptably bad.
>>>   
>>
>> Only if anyone wants an upstream-defaults profile. But nobody's asked
>> for one, in contrast with the large number of users who want minimal.
>>
>>
>>> Is there a better way we can have our cake and eat it too?  I'll
>>> admit that a huge package.use on the minimal profile isn't a whole
>>> lot better than a huge package.use on all the other profiles.  
>>
>> Every important upstream default is already enabled in some profile.
>> If dropping a particular IUSE default breaks desktop systems, then
>> that flag belongs enabled in the desktop profile. If it breaks every
>> system, then let's keep it default.
>>
> 
> How about rather changing our defaults to satisfy the minimalists who
> don't mind drastically reduced functionality and usability in pursuit
> of "minimalism" we just strive to make USE="-*" mostly usable, so the
> minimalists can get what they want, while still having sane defaults. 
> 

I'm in favour of this too -- I know we don't "officially" support
USE="-*" but I think we should still strive to make it work with
minimal effort to end-users -- that effort being mainly setting
whatever is necessary for REQUIRED_USE resolution.





signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Guidelines for IUSE defaults

2017-02-03 Thread Ian Stakenvicius
On 02/02/17 08:21 PM, Michael Orlitzky wrote:
> On 02/02/2017 06:41 PM, Ian Stakenvicius wrote:
>> Responding here instead of the first time it was posted, just 'cause.
>>
>> On 02/02/17 06:35 PM, james wrote:
>>> "
>>> I'm not saying that we should have a minimal experience out-of-the-box,
>>> only that the base profile should result in an effectively-minimal set
>>> of USE flags. Adding IUSE defaults is essentially adding defaults to the
>>> base profile."
>>
>> Yes.  More specifically, it's adding these defaults without setting
>> the flags globally, thereby not introducing system-wide defaults
>> across all packages but only those that make sense on a per-package
>> basis for that package to operate properly.
>>
>> IMO this is the effectively minimal-set of use flags we should have.
> 
> I... agree? We should enable the flags that are necessary for the
> package to work, and we should enable whatever is necessary to avoid
> REQUIRED_USE roadblocks. That's what I started out by suggesting.
> 

Where we disagree is that this includes all of scenarios #2, #3, and
#4 IMO.  #4 perhaps less so than the others, but IMO if there is a
good reason feature-wise for that to be default-enabled, then the
maintainer should still default-enable it and do so via IUSE-defaults.

Remember one of the primary reasons IUSE-defaults came about is
because maintainers were doing all of these things, but using "no*"
flags so that the features would be default-enabled.  I don't think
any of us want to see that again.





signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Gentoo Dinner@FOSDEM 2017

2017-02-03 Thread Xavier Miller

Hi,

Here are the practifcal informations for the Gentoo Dinner.

Place: Chez Léon, rue des Bouchers 18, 1000 Brussels (near the Grand 
Place) [2]

Date: Sat 4 Feb, 20:15

Menu: 30,60 EUR

28 places are ordered, based on the wiki page list [1].


See you tomorrow,
Xavier.


Le 2017-01-24 20:28, Xavier Miller a écrit :

Hi!

The traditional Gentoo Dinner @ FOSDEM 2017 comes back!
If you are interested, please edit the Wiki page[1].

I see some "possible" or "maybe", can you please confirm to "yes" or
"no" as soon as possible?





Kind regards,
Xavier Miller

[1] https://wiki.gentoo.org/wiki/FOSDEM_2017

[2] http://www.chezleon.be/en/general-information/




Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

2017-02-03 Thread Lars Wendler
On Fri, 3 Feb 2017 10:32:30 +0100 Kristian Fiskerstrand wrote:

>On 02/03/2017 10:10 AM, Benda Xu wrote:
>> William Hubbs  writes:
>>   
>>> I have been looking at the meson build system [1] [2], and I like
>>> what I see.
>>>
>>> I have opened an issue on OpenRC's github wrt migrating OpenRC to
>>> the meson build system [3].
>>>
>>> As I said on the bug, the downside is the addition of py3 and ninja
>>> as build time dependencies, but I think the upside (a build system
>>> where we don't have to worry about parallel make issues or
>>> portability) outweighs that.
>>>
>>> What do folks think here?  
>> 
>> I would discourage it.  Making OpenRC build-depend on python
>> introduces unnecessary complexity that will undermine the
>> portability of OpenRC sooner or later.
>> 
>> After all OpenRC is a small program easy to build with a hand-written
>> Makefile.
>> 
>> Parallel make issues?  No problem let's just solve it.
>> 
>> 
>> Please, keep it simple.  
>
>I'm adding my support to this sentiment
>
>

+1

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpEkZOYA01EV.pgp
Description: Digitale Signatur von OpenPGP


Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

2017-02-03 Thread Kristian Fiskerstrand
On 02/03/2017 10:10 AM, Benda Xu wrote:
> William Hubbs  writes:
> 
>> I have been looking at the meson build system [1] [2], and I like what I
>> see.
>>
>> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
>> meson build system [3].
>>
>> As I said on the bug, the downside is the addition of py3 and ninja as
>> build time dependencies, but I think the upside (a build system where
>> we don't have to worry about parallel make issues or portability)
>> outweighs that.
>>
>> What do folks think here?
> 
> I would discourage it.  Making OpenRC build-depend on python introduces
> unnecessary complexity that will undermine the portability of OpenRC
> sooner or later.
> 
> After all OpenRC is a small program easy to build with a hand-written
> Makefile.
> 
> Parallel make issues?  No problem let's just solve it.
> 
> 
> Please, keep it simple.

I'm adding my support to this sentiment


-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

2017-02-03 Thread Benda Xu
William Hubbs  writes:

> I have been looking at the meson build system [1] [2], and I like what I
> see.
>
> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
> meson build system [3].
>
> As I said on the bug, the downside is the addition of py3 and ninja as
> build time dependencies, but I think the upside (a build system where
> we don't have to worry about parallel make issues or portability)
> outweighs that.
>
> What do folks think here?

I would discourage it.  Making OpenRC build-depend on python introduces
unnecessary complexity that will undermine the portability of OpenRC
sooner or later.

After all OpenRC is a small program easy to build with a hand-written
Makefile.

Parallel make issues?  No problem let's just solve it.


Please, keep it simple.

Benda


signature.asc
Description: PGP signature


[gentoo-dev] Re: Guidelines for IUSE defaults

2017-02-03 Thread Duncan
Michael Orlitzky posted on Thu, 02 Feb 2017 10:49:41 -0500 as excerpted:

> On 02/02/2017 09:56 AM, Ian Stakenvicius wrote:
>> 
>>> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky 
>>> wrote:
>>> 
>>> IUSE defaults are used in a few different ways:
>>> 
>>> 1 To ensure that critical functionality is enabled.
>>> 
>>> * Example: force the "unix" module for apache.
>>> 
>>> 
>> This is not what IUSE defaults are for, this should be done with
>> package.use{,.stable}.{mask,force} in profiles.  If functionality is
>> critical then there (A) shouldn't be a use flag, or (B) shouldn't be a
>> way for USE= in make.conf to disable it.
>> 
>> 
> If we adopted this policy, then USE="-*" would no longer be guaranteed
> to break the system. It does still ignore your profile defaults, though,
> which presumably are important (e.g. for hardened). So we're still left
> with no way for me to turn off everyone's pet USE flags and keep my
> system working.

If USE="-*" is a guarantee of a broken system, it's a pretty weak one.  
In fact, so is flying with an empty @system (everything in the profile 
negated), as I do both of the above.

And in fact, my gentoo-based-admin life has been far simpler since I set 
it up that way.  =:^)

The biggest benefit of USE="-*" is that I no longer have to worry about 
investigating the "why" of USE flag changes when I change to a different 
profile, or when devs change my existing profile out from under me.  I 
have a set of USE flags I've decided I want (or need for long-term-
installed stuff like kde), and all packages that don't work with that 
default -- for instance, packages that required-use qt4 XOR qt5, already 
have their package.use setup as appropriate.

Otherwise, when I upgrade to a new profile, as I've needed to do several 
times over the nearing a decade and a half I've been running the same 
original installation rolling-update gentoo on rolling-update hardware, I 
have to do a bunch of research on all the USE flags that changed and how 
they affect my existing installation due to --newuse.  This way, that was 
all managed at the time I encountered the original USE flag conflict, and 
the profile I choose doesn't mess with my USE flags at all except via 
forces (which I can override if I have to, but I haven't had to, a 
testament to the wisely conservative usage of forced-USE).

Of course, I can and do still use the USE flags set in a profile as a 
guide, and that was a tremendous help in the kde-apps5/frameworks5/plasma5 
upgrade process despite the fact that I couldn't actually use the profile 
designed for that.

The biggest weakness, meanwhile, is that with USE="-*" there's no easy 
way to actually see what a package's USE-defaults are, without actually 
opening up the ebuild (or at least grepping) to see.  I've often wished 
there was some way to denote the default-on flags in emerge --pretend/--
ask so I could see what they are on a new package, and investigate why if 
necessary, but I understand the problem of a limited available symbol-
space, and actually looking in the ebuild isn't /horribly/ hard... as 
long as there's multiple terminals available to do it in, without 
unnecessarily canceling the --ask output that took so long to appear.

Of course it would be a bit different if I could actually use a profile 
with all the bits I needed, nomultilib, systemd, plasma, amd64, 
primarily.  But until mixins, nomultilib generally means at least some of 
the other stuff isn't available in a profile, so I gotta simply pick the 
nomultilib profile that best matches and check the other profiles, for 
example plasma, using them as a guide to set my flags the way I need them.

Similarly with @system.  Negating the entire thing a package at a time 
and seeing what --depclean wants to clean, then adding as appropriate to 
a set listed in world_sets if it's /really/ needed, means I don't have to 
worry about package.providing openrc, for instance, because it's not 
necessary with systemd, once a single symlink is setup.  Similarly with 
ssh if it's only a stand-alone system you're admining.  And most of the 
@system virtuals can simply be dropped, as specific selections from those 
virtuals have already been added to some set listed in world_sets.

Of course it helps that my routine-use emerge aliases have --ask 
--verbose --oneshot.  (I don't configure those as emerge-defaults because 
I do for example want --pretend occasionally instead of --ask.)  But 
that's a lesson most gentooers should have learned within six months.

Anyway, USE="-*" hardly breaks the system here.  In fact, rather the 
opposite, it fixes what was previously a major headache of a workaround 
for a broken system every time my profile changed, because I was setting 
most USE flags I wanted but until then, not *ALL* of them, in part 
because I couldn't see what I had missed because the profile was setting 
it for me... until it didn't, thus creating the problem.

So for some people,