Re: [gentoo-dev] Packages up for grabs

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/03/12 05:17 PM, Markos Chandras wrote:
> net-misc/wakeonlan

I'll take this one..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9Q23EACgkQAJxUfCtlWe0SIgD/cnWB5kdzyJfzf5MZnX73aIfQ
GfYKFX047IkboH6bHjQA/iutdhBTfeqSGO+dQouxY+A8iB15rI+tFVNEOilijCj+
=RKQQ
-END PGP SIGNATURE-

Re: [gentoo-dev] RFD: EAPI specification in ebuilds

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/03/12 10:41 AM, Zac Medico wrote:
> On 03/09/2012 07:21 AM, Michael Orlitzky wrote:
>> The advantage that the eapi function has over a comment is that
>> it's not magic -- it's just normal bash syntax. So we've
>> addressed that issue at a small performance cost (we're really
>> only sourcing the ebuild up to 'exit').
> 
> Also consider the case where a user syncs after not having updated
> for a couple of months, and the tree contains some ebuilds with
> EAPIs that are not supported by the currently installed package
> manager.


IIRC we get this already, when the EAPI isn't supported by the version
of portage installed -- upgrading really old systems won't allow an
emerge of python-2.7 due to a too-new EAPI, and python-2.7 is needed
to upgrade to the newer portage.

I don't see how the EAPI check itself failing and thereby excluding an
ebuild is much different than the specified EAPI excluding it..?
Either way, the end user is going to have issues if they don't keep
their portage up to date.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9aJ0QACgkQAJxUfCtlWe2tTAEA7iUgDOCaGoQhz1dXukQ/a3lY
rsdqewd2DYZWtsv+3XoA/iRVe+qf4HXdkWTchFRHlolaTJechz6AZCzKY/sNdu4w
=1e/8
-END PGP SIGNATURE-

Re: [gentoo-dev] RFD : .ebuild is only bash

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/03/12 02:50 PM, Ulrich Mueller wrote:
>> On Mon, 12 Mar 2012, Ciaran McCreesh wrote:
>> GLEP 55 is simple, it solves all the problems we have (including
>> the version issue, which everyone is conveniently ignoring), it
>> doesn't require us to guess what's going to happen next and it
>> can be implemented immediately. That's a rather big deal.
> 
> The "header comment" solution solves all these issues too, without 
> embedding unrelated information in the filename [1]. It can be 
> implemented immediately, too.
> 
> The argument that was always used against such solutions was that 
> it would "hurt performance". However, when the council asked for 
> benchmarks that would prove that point, nobody could provide them.
> 
> Ulrich


Regarding the filename issue, and the potential in the future for
ebuilds that get parsed with other parsers:

Is there any particular reason why we would want multiple ebuilds for
a package to exist for the same version, but supporting different
EAPIs (ad therefore different parsers)?

If the answer to this is no, that there should always be only one
ebuild per package version, then chances are good that we should keep
the eapi (or other identifier) out of the file name.  However, if the
answer is yes, then the filename method is probably the cleanest way
to do this.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9eRzkACgkQAJxUfCtlWe18WwD5AeXETH+J4X8d8P7TX76FPGPS
0vS2rrRZktpLp70TkcQA/0Cl2/OdSlfwi0CqC8IBJffsY3epXkqxhzPL8bwsNAoj
=Q5aK
-END PGP SIGNATURE-

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Ian Stakenvicius]

On 2012-03-12, at 9:22 PM, Joshua Kinard  wrote:

> 
> And yes, I've already tested out udev-181 on a VM with a
> separate /usr.  With devtmpfs, the system fully boots just fine, no
> initramfs needed.  Guess what the only piece of software to mess up is?
> Udev.  I largely think it's a timing issue in OpenRC, however, because /usr
> DOES get mounted fairly quickly, but not before udevd starts.  But udevd
> does restart itself and everything looks to work fine.  If you aren't
> watching the terminal, you wouldn't even notice the failures.
> 


THANK YOU for testing this -- I could not forsee a reason, back when this 
process started, as to why openrc couldn't mount /usr before udev started.   
since devtmpfs should provide the source devnode anyways.  It's good to have a 
(near) proof of that.

Ian

Re: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181]

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/03/12 11:14 PM, Joshua Kinard wrote:
> On 03/12/2012 22:33, Ian Stakenvicius wrote:
> 
>> 
>> On 2012-03-12, at 9:22 PM, Joshua Kinard 
>> wrote:
>> 
>>> 
>>> And yes, I've already tested out udev-181 on a VM with a
>>> separate /usr.  With devtmpfs, the system fully boots just
>>> fine, no initramfs needed.  Guess what the only piece of
>>> software to mess up is? Udev.  I largely think it's a timing
>>> issue in OpenRC, however, because /usr DOES get mounted fairly
>>> quickly, but not before udevd starts.  But udevd does restart
>>> itself and everything looks to work fine.  If you aren't
>>> watching the terminal, you wouldn't even notice the failures.
>>> 
>> 
>> 
>> THANK YOU for testing this -- I could not forsee a reason, back 
>> when this process started, as to why openrc couldn't mount /usr 
>> before udev started.   since devtmpfs should provide the source 
>> devnode anyways.  It's good to have a (near) proof of that.
>> 
>> Ian
> 
> Yeah, I think it's an easy fix either in openrc or in an initscript
>  somewhere.  I changed nothing except my kernel (was missing
> devtmpfs -- it's not under Filesystems!), uninstalled
> module-init-tools, and installed kmod + udev-181.  Then rolled back
> the snapshot once I had the results.

Ah, right; kmod.. Tthere's pressure for that one to move to /usr
too, isn't there mgorny?   ok, nvm.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9fTXIACgkQAJxUfCtlWe3RQQD8DIr8mZ773vIqhIxf5ERYWo8E
ZkfDgAUlUDF7hcDiuUIA/1amWFFZcVu36V6vikq4HGF0we43YYMVLW6b96SblGzN
=dKid
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: License problem

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/03/12 10:34 AM, Richard Yao wrote:
> On 03/21/12 10:18, Justin wrote:
>> I will not extract part of the software, e.g. subroutines, for
>> use in other contexts without permission of the author.
> 
> Portage could be considered to be one of these contexts.
> 

If the entire package is installed (ie, it's not broken up into
separate libraries or sub-packages) this would be fine (ie having the
package in portage), wouldn't it?

I guess the primary restriction here would be that nothing else would
be allowed to link against any embedded libraries; ie, the package
couldn't be a dep.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9p6ksACgkQAJxUfCtlWe0IugEAmsr4z1EunK61OPu6d17hK551
zFI7KaSUPT4EtXnZxboBAIBnPFlybqvfjJ/qj1Xwftf+IR8lzdkkIhWrF9BulNLQ
=wtVz
-END PGP SIGNATURE-

Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23/03/12 12:02 PM, Ciaran McCreesh wrote:
> On Fri, 23 Mar 2012 11:58:47 -0400 Mike Gilbert
>  wrote:
>>> oasis_src_compile() { oasis_src_compile_no_doc if has doc
>>> ${IUSE} && use doc; then ocaml setup.ml -doc || die fi }
>> 
>> This should probably call use_if_iuse from eutils.eclass, which 
>> handles IUSE="[+-]doc".
> 
> Actually, neither way works. The spec says:
> 
> Global variables must only contain invariant values 
> (see~\ref{sec:metadata-invariance}). If a global variable's value
> is invariant, it may have the value that would be generated at any 
> given point in the build sequence.
> 
> So you can't rely upon IUSE having the "merged" value in an
> eclass.
> 

I don't know if I follow this one or not.  When inheriting an eclass,
all entities within the eclass get merged into the ebuild.  As long as
there aren't any special conditional tricks being used to assign to
global variables like IUSE, it would still be invariant wouldn't it?

I think 'any point in the build sequence' is still
post-eclass-inheritance isn't it?



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9soW8ACgkQAJxUfCtlWe1UJQEAuTQriXmsu6YKcpeADGusTNdZ
k8Vr99LdEFwyXicZHMsBAN2bo95GvLvdrpVEj8h1THQ4HMZDvPRx0o/yrWzjxGNZ
=+e3P
-END PGP SIGNATURE-

Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23/03/12 12:19 PM, Ciaran McCreesh wrote:
> On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius
>  wrote:
>> I don't know if I follow this one or not.  When inheriting an
>> eclass, all entities within the eclass get merged into the
>> ebuild.  As long as there aren't any special conditional tricks
>> being used to assign to global variables like IUSE, it would
>> still be invariant wouldn't it?
> 
> The point is that the merging might be done inside the package
> manager (not in bash code) on the IUSE metadata variable, and the
> changes don't have to be reflected in the IUSE environment variable
> inside the ebuild.

If that was the case, then eclasses could no longer append deps to
(R)DEPEND, either .?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9spYUACgkQAJxUfCtlWe1g+QEA1NAl+nl3zCEOmTIjCN1271r7
pCJNO7aCW/iNrXniCQUA/3j1xktcStPmQL8rXPRLSjMy+vqBsclWQwFHa4eytu6B
=g3Dz
-END PGP SIGNATURE-

Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23/03/12 12:32 PM, Ian Stakenvicius wrote:
> On 23/03/12 12:19 PM, Ciaran McCreesh wrote:
>> On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius 
>>  wrote:
>>> I don't know if I follow this one or not.  When inheriting an 
>>> eclass, all entities within the eclass get merged into the 
>>> ebuild.  As long as there aren't any special conditional
>>> tricks being used to assign to global variables like IUSE, it
>>> would still be invariant wouldn't it?
> 
>> The point is that the merging might be done inside the package 
>> manager (not in bash code) on the IUSE metadata variable, and
>> the changes don't have to be reflected in the IUSE environment
>> variable inside the ebuild.
> 
> If that was the case, then eclasses could no longer append deps to 
> (R)DEPEND, either .?

Err, nvm..  i think i'm following the difference now.  functions like
has_version and so forth don't actually work on the value(s) of
*DEPEND themselves, so in the case of (R)DEPEND it wouldn't matter of
the package manager didn't expose the merge.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9spp8ACgkQAJxUfCtlWe1a2wD/YsHDM1hYik+d46fJ90yckI/U
OKr1ThK6hhJTbjmqGpgBAMekpXzx8NFIPerRPm037FgWQiCuUPDezAhmj8S73EPV
=CNHZ
-END PGP SIGNATURE-

Re: [gentoo-dev] automated bug filing (i.e. pybugz) failing because of missing token

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/03/12 04:04 AM, Ian Whyman wrote:
> On 27 March 2012 08:33, Dirkjan Ochtman  wrote:
>> On Mon, Mar 26, 2012 at 20:44, Alec Warner 
>> wrote:
 Long term, we may want to consider porting pybugz to use
 Bugzilla's XML-RPC api to avoid such breakage.
>>> 
>>> XML-RPC is shit.
>> 
>> https://wiki.mozilla.org/Bugzilla:REST_API
>> 
> 
> Shame that it requires custom patches to BZ, personally I think
> the preferable (and offically supported) method would be
> JSON-RPC[1]
> 
> Ian
> 
> 1.http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService/Server/JSONRPC.html
>
> 
What about all of the above?  :D  Shouldn't be hard to use the various
support libs to dump the request object to either format, right?

(no, i'm not volunteering)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9xxhoACgkQAJxUfCtlWe0nVwEA6DIm5IcHaxZuFUZz7ETOq8o3
zzVOBJqP84SY+FQv8xkBALlNtfKSgQLPR0Qoyc3/nUqt8hAuvOF0jOIEx9r0FVMm
=wYwb
-END PGP SIGNATURE-

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/03/12 02:47 PM, Rich Freeman wrote:
> On Tue, Mar 27, 2012 at 2:34 PM, Alexandre Rostovtsev
> 
>> The partitioning scheme is something that the user needs to
>> decide on *before* getting Gentoo up and running. After the user
>> had finished installing the operating system, it's too late to
>> inform him about the advantages of a separate /usr/portage.
> 
> Yes and no (if you have free space, you could easily move
> /usr/portage - some other changes are harder).
> 
> However, you could extend this line of argument to raid, lvm, and
> even stuff like the use of systemd or an alternative package
> manager.  All of those things are much easier to implement if you
> just start out with them.
> 
> I'm all for creating a wiki to talk about some alternative
> options. Perhaps even link to it at the start of the handbook in
> the intro (if you're not in a rush and want to read about more
> advanced configurations, check out ...).
> 
> However, I tend to agree that the handbook should be a 
> nearly-foolproof no-frills Gentoo installation.
> 


You know, we have "Code Listing 2.1: Filesystem Example" in Section 4,
we could always adjust that to have a /usr/portage partition in it
(take a bit of space away from /home, or something)

It doesn't recommend/require anything, but when users see it they'll
think about it.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9yDK4ACgkQAJxUfCtlWe19QgEA22gRFMmyaxVpJp+LeaPsTWOq
RqF2z9fZvebtBiSdLSUA/R4c10HtDeBpjEJyHCKbQkKJWc+ilRw8bilOgHgAvKT5
=egsm
-END PGP SIGNATURE-

Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/03/12 03:04 PM, Aaron W. Swenson wrote:
> 
>> You know, we have "Code Listing 2.1: Filesystem Example" in
>> Section 4, we could always adjust that to have a /usr/portage
>> partition in it (take a bit of space away from /home, or
>> something)
> 
>> It doesn't recommend/require anything, but when users see it 
>> they'll think about it.
> 
> That isn't the way users read it, though. They read it and assume
> that is precisely how they *need* to configure their disk layout.
> 
> - Aaron
> 

Really?  It's been a while since i hung out in #gentoo, but i was
there pretty solidly for a couple of years and i don't recall any new
user (to gentoo or linux) reporting in, saying they set up their
disk(s) with all of those partitions.  They pretty well always
followed the "default partitioning scheme" listed in the table in 4.b
(which is used for every other example on that chapter).

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9yEVoACgkQAJxUfCtlWe3EtgEAwr62YTL812ehPurzTJWT1sqr
SUQhJzybaLlY0Rf2T6ABANqOtXDK+IbRTjLw1fcfjGHqWuYUAfqYnYtniN5ztwHK
=Vi2z
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: location of portage tree

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/03/12 03:05 PM, William Hubbs wrote:
> All,
> 
> I know this has come up before, but I don't really recall what the 
> specific objections were.
> 
> IMO the portage directory doesn't belong under /usr at all. I was
> chatting with another developer who uses 
> /var/cache/portage/{tree,distfiles}, and I'm thinking about
> switching my default setup to do this.
> 
> I realize that historically the portage tree has been installed
> under /usr, but Can we consider changing this default for new
> installations and providing instructions for users for how to get
> the portage tree out of /usr? William
> 

IIRC, 'cache' can be a volatile storage area, that is, anything in it
can be removed.  One's system is b0rked (or at least, portage is) if
/path/to/portage/profiles goes missing.  I wholeheartedly agree that
distfiles should be moved to /var , but I think the portage tree
shouldn't be there..

(at least, shouldn't be in /var/cache/ ; maybe /var/lib/ ?  of course
then we're colliding with the existing use of /var/lib/portage ...)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9yEmYACgkQAJxUfCtlWe0FNAEAyD6zMS/R7P0kltN6J84kAOkM
5LHcznZRWnn6WFyy4CIA+wXNkzDQ5Pim/hqxHylSILlmUUkb+96KvkjX/mmO03eU
=VVCn
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: location of portage tree

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/03/12 04:08 PM, Kent Fredric wrote:
> On 28 March 2012 08:59, William Hubbs  wrote:
>> What I was wanting to discuss mainly was that /usr/portage isn't
>> right; I think we need to move that out of the /usr directory.
>> 
>> I'm not sure what the new default should be, nor how the default
>> should be decided. Maybe we just let Zac pick one?
> 
> While we're talking about things that probably don't belong in
> /usr/ :
> 
> src ,  esp /usr/src/linux and friends.
> 
> I know its not likely to ever change, but its always felt very
> very wrong to be under /usr
> 
> I've always sort of treated /usr as if it was this big space of 
> "untouchable, except by package manager", and /usr/src/linux sort
> of violates that sense  ( as does /usr/local/ to an extent , but
> its slightly different )
> 

Remember that these things pre-dated package managers, though, right?
 (of course i'm showing my own age here..) :D

To further the bikeshed:

- ---Quote: FHS 2.3---
/var/cache
Application cache data. Such data are locally generated as a result of
time-consuming I/O or calculation. The application must be able to
regenerate or restore the data. The cached files can be deleted
without loss of data.

..ok, I guess 'emerge --sync' is a valid regeneration method for the
cache.  I withdraw my objection to moving /usr/portage into /var/cache
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9yIfEACgkQAJxUfCtlWe0NMQEAgGugDZWZS5EfB3rn3oUOU7Vf
wYgYo3Oflgd4EqzjH20BAJkk2l/dXX0yAw6NZEmB9VuSfwgbQUQe/wetoMbbc5BR
=4AZd
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: location of portage tree

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28/03/12 03:04 PM, Rich Freeman wrote:
> On Wed, Mar 28, 2012 at 2:53 PM, Christoph Mende
>  wrote:
>> 
>> I believe it's /var/lib/. Here's what FHS says: /var/cache
>> is intended for cached data from applications. Such data is 
>> locally generated as a result of time-consuming I/O or
>> calculation. The application must be able to regenerate or
>> restore the data. Unlike /var/spool, the cached files can be
>> deleted without data loss.
>> 
> 
> I can do rm -rf /usr/portage ; mkdir /usr/portage ; emerge --sync
> and it will work just fine, I think.

It does, i tried it yesterday.

> 
> That really does point to cache.  The only thing different from a 
> browser cache is that portage doesn't automatically refresh it.
> 

Although, we could always make emerge do an automatic --sync if, say,
/path/to/portage/profiles doesn't exist.  :)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk9zbCwACgkQAJxUfCtlWe2abgEAl8eapp2DQOYJx6RAcl6Ei/iN
9L4e7tG9maNTryI6lKMBAOEqAdgWrKWx2UJ3+g7oBNFc5G7Lu+yk3deZZFN4zBjU
=sluw
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Making user patches globally available

[Ian Stakenvicius]

On 2012-04-15, at 5:03 AM, Ryan Hill  wrote:

> On Sun, 15 Apr 2012 01:35:40 -0700
> Zac Medico  wrote:
> 
>> On 04/15/2012 01:16 AM, Ryan Hill wrote:
>>> Right now we have support in some packages for user patches - those being
>>> patches dropped into /etc/portage/patches/pkgname/ - which are automatically
>>> applied.  Because this feature is implemented by epatch_user() in
>>> eutils.eclass, it is only available for ebuilds that inherit eutils and
>>> explicitly call epatch_user or inherit another eclass that calls it in an
>>> exported phase (eg. base).  The end result is a very inconsistent 
>>> experience,
>>> where user patches may or may not work not only on a package-by-package
>>> basis, but ebuild-by-ebuild.
>>> 
>>> Is there any reason why this couldn't just be done in the package manager,
>>> making user patches available for all ebuilds without code changes?
>> 
>> Funtoo has support for FEATURES=localpatch, which does the epatch_user
>> thing before src_prepare. I think it should really go after src_prepare,
>> in order to apply patches after those that src_prepare may apply
>> (avoiding possible conflicts).
> 
> I agree.
> 
>> The reason that Funtoo's FEATURES=localpatch applies patches before
>> src_prepare is that it's common for eautoreconf to be called inside
>> src_prepare, and applying patches after src_prepare can create a need to
>> call eautoreconf a second time.
> 
> Well that could waste a bit of time but is pretty much harmless, no?  And the
> existing usages of epatch_user (other than autotools-utils) don't eautoreconf
> anyways, nor should they in case the package doesn't use autotools.
> 
> 


the existing use of epatch_user allow you to put the call after current 
epatchez and before the eautoreconf call..   

I agree tho -- an automatic call to eautoreconf could be triggered by 
features=localpatch whenever there are patches and autotools.eclass is 
inherited.

also, any user patches applied could be cat'd to the build log, to allow for 
debugging 

Re: [gentoo-dev] Feature request: package.use.stable.mask and package.use.stable.force

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 26/04/12 06:03 PM, Andreas K. Huettel wrote:
> 
> Dear all,
> 
> I'd like to suggest we introduce the following very useful feature,
> as soon as possible (which likely means in the next EAPI?):
> 
> * two new files in profile directories supported,
> package.use.stable.mask and package.use.stable.force * syntax is
> identical to package.use.mask and package.use.force * meaning is
> identical to package.use.mask and package.use.force, except that 
> the resulting rules are ONLY applied iff a stable keyword is in
> use
> 
> Rationale: Often single features are "not ready for production
> yet", but the remaining package with that feature disabled would be
> a perfect candidate for stabilization. Right now this can be solved
> by * masking the useflag, which then makes the feature inaccessible
> even for ~arch * masking the useflag for exactly one package
> revision, which is hell to maintain * or introducing different
> package revisions with/without the useflag, which is also a mess.


I would think, personally, that masking the useflag on a per-package
basis would be better than this new feature -- it is more work as it
needs to be done for all the different ~arch packages the use flag
applies to, but it would mean that when a given ~arch version bump has
that feature ready one wouldn't lose the mask on the previous ~arch
versions.  It would also mean (i assume) that this flag would be
masked if that version went stable too (although in reality I would
expect this wouldn't ever occur).

There are potentially a lot of package entries to manage if this were,
say, a flag like 'introspection'..  however, i'm sure maintaining this
could be scriptable couldn't it?


> 
> Where this would (have been|be) useful: * we had for a long time
> different revisions of subversion with/without kde useflag *
> cups-1.4 had the infamous libusb backend triggered by USE=usb *
> cups-1.5 has optional systemd support via a systemd useflag, which
> pulls in non-stabilized systemd as dependency...
> 

I'm not sure that I'm following the cups examples here.  For cups-1.5
even if it were stable, if someone actually wanted to use systemd on
their system and unmasked/keyworded it (while running stable
everything else) I don't see why this would be an issue that would
need this new masking feature (unless IUSE="+systemd", which probably
shouldn't be the case anyways).

Ian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk+ara4ACgkQ2ugaI38ACPALZwD/bIk3GzOThs6P/2EkWn2DxvEY
XHQZVUvmc1dJBERmSiIA/3saDFCoK79S8fw+2Q9Myf9Lt6PdEc4u1j48QcDf+sKW
=XQ3/
-END PGP SIGNATURE-

Re: [gentoo-dev] Remove eclass/ChangeLog

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23/05/12 03:23 PM, hasufell wrote:
> On 05/20/2012 03:25 PM, Michał Górny wrote:
>> On Sun, 20 May 2012 15:33:11 +0300 Samuli Suominen 
>>  wrote:
> 
>>> ChangeLog entries missing for every autotools.eclass 
>>> modification today.
> 
>> I will repeat once again: autogenerate them.
> 
> 


Isn't one of the reasons the changelog is there, is so that eclass
changes can be committed with repoman and (with the newer repoman) the
- -m comment will automatically be added to the ChangeLog ??


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk+9Pn0ACgkQ2ugaI38ACPCtogEAh1/FLYMho2HaSyg7e6JDtwcW
UTAPNaD3WPFGyJbO/ZMA/0gh1Ale/msPdzlJyYBny6rDtCjkUNCAP2zwwk+KXV5R
=tdxA
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 24/05/12 01:13 PM, Kent Fredric wrote:
> On 25 May 2012 03:02, Ralph Sennhauser  wrote:
>> On Thu, 24 May 2012 16:40:02 +0200 Michał Górny
>>  wrote:
>> 
>>> d) Talk with github folks to add our repo as 'mirror'.
>> 
>> Can we keep the master on Gentoo hardware please.
> 
> Definitely.  But having a mirror on github will increase
> forkability, and will make it much faster for people to get started
> on contribution.
> 
> When the user has their tree up to how they want it, they can
> either send a pull request to another gentoo dev who also has a
> fork on github, or send a link to the commit via some medium ( bug
> tracker ? ) , and some dev can just add that as a remote, and
> merge/cherry-pick the commits they want..
> 


...is this something we (as the developer base) WANT non-dev's to be
able to do??  I would expect we'd want the tree to still be treated as
read-only-not-modifyable by the rest of the gentoo/linux community,
otherwise we're going to have a rather large mess on our hands
(multiple forks of the main tree != a uniform main tree + overlays,
the way it does now)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk++dWAACgkQ2ugaI38ACPBBpAD9EaJsSNXMS6bDbttJStVqghlO
Q46xkgPIgunriOLJhDoA/06HH/kgXd/Qrq/Ex0X3kV9nDmYqE0OmiFM1kVTfdVCD
=dcOs
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: OpenRC Networking Scripts

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 26/05/12 03:40 PM, William Hubbs wrote:
> All,
> 
> I realize this has been discussed and there are definite opinions
> about which method works well. So, I want to take a different
> approach.
> 
> Is there any interest in documenting and supporting newnet along
> side oldnet as opposed to killing newnet?
> 
> Newnet would consist of the "network" init script to set up your 
> loopback interface along with something like dhcpcd,
> networkmanager, or wicd (and wpa_supplicant for wireless
> interfaces) running in standalone mode to manage your other
> interfaces.
> 
> My understanding of the way newnet works is that the big advantage
> would come for workstations that have a simple network setup and
> where users would want hotplugged interfaces to just work.
> 
> Any thoughts?
> 
> William
> 


Just want to point out that my hotplugged interfaces work great with
oldnet.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/CPuMACgkQ2ugaI38ACPAAYgD/QUwTWo4ov++qtmsR8P5TQjQd
EngeAjncgIU5kMcyiqQA/0M4qfS0T3xnWwEU61GPr/YuDjRbeVhjM81gPveGxm3P
=otGU
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: OpenRC Networking Scripts

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27/05/12 10:56 AM, William Hubbs wrote:
> On Sun, May 27, 2012 at 10:49:07AM -0400, Ian Stakenvicius wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> On 26/05/12 03:40 PM, William Hubbs wrote:
>>> All,
>>> 
>>> I realize this has been discussed and there are definite
>>> opinions about which method works well. So, I want to take a
>>> different approach.
>>> 
>>> Is there any interest in documenting and supporting newnet
>>> along side oldnet as opposed to killing newnet?
>>> 
>>> Newnet would consist of the "network" init script to set up
>>> your loopback interface along with something like dhcpcd, 
>>> networkmanager, or wicd (and wpa_supplicant for wireless 
>>> interfaces) running in standalone mode to manage your other 
>>> interfaces.
>>> 
>>> My understanding of the way newnet works is that the big
>>> advantage would come for workstations that have a simple
>>> network setup and where users would want hotplugged interfaces
>>> to just work.
>>> 
>>> Any thoughts?
>>> 
>>> William
>>> 
>> 
>> 
>> Just want to point out that my hotplugged interfaces work great
>> with oldnet.
> 
> Actually they don't, because we don't make or remove the net.*
> symlinks in /etc/init.d for the hotplugged interfaces when the
> interfaces are added or removed.
> 
> William
> 

Although yes this is true, when I did my install I just made symlinks
for net.eth{0,1,2,3} and net.wlan{0,1}.  Once they are there, usage is
straight-forward and the iface scripts that I don't hotplug are never
started so there isn't any issue with them being there (on my systems
I don't specify all devices need to be up for 'net' to be up).

Although, as rumour has it udev is dropping the persistent-*.rules
soon so it might become difficult for me to configure my various
net.*'s in a consistent way.  But that's a side issue that'll affect
more than just hotplugging I expect.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/DoHYACgkQ2ugaI38ACPB62AEAoxWcOPJUBeWh/mJbcQ3ueITa
Fq0jCbLzVnMLVPX2OXQBAI/+/0ameFw24/0fGeCpSMTWCBe0iQajIAV1y2HETRsM
=aZDR
-END PGP SIGNATURE-

Re: [gentoo-dev] Should packages auto-eselect alternative implementation on removal?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/05/12 01:01 PM, Michał Górny wrote:
> ... In other words, removing a pager leaves system in a broken
> state. AFAICS, 'eselect pager' doesn't even support a system
> without pager -- it just fails miserably. So the user is either
> forced to install any pager provider, or remove the env.d file by
> hand.
> 
> Thus, I raise the following issues:
> 
> 1) eselect modules should probably support not only switching 
> implementations but disabling any as well. I'll open a bug for the
> editor module used here;
> 

Also, it may make sense to have the eselect module have its own update
default -- ie, either unset when the current selection disappears, or
choose an alternative (and could even have a default heuristic choice
for how that alternative will be chosen).  I suppose dev's might want
to control this per-package, but I expect that per-eselect-module
would be atomic enough to cover the vast majority of cases wouldn't it?


> 2) should all implementation providers call 'eselect ... update'
> in postrm()? That seems to be the most reasonable way of ensuring 
> the system is left in working state.

I concur on this.


> 3) how about semi-official eselect modules, like eselect-sh? I
> don't really see all shells depending on it; should the ebuilds
> check whether a particular eselect module is installed first?


This could be done fairly easily via an inherited eclass + an
eselect-module-identifier variable (as with the rest of the
potentially required functionality above).  If it's still up to the
package to RDEPEND on the eselect-module package directly, then the
eclass could fairly easily do nothing if it's not installed; otherwise
a variable to set required or optional would do the same (allowing
*DEPEND on the eselect modules could be moved to the eclass)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/GVkEACgkQ2ugaI38ACPAubwD9G0MA+2txBUXBI8lzAZu4ULzj
rkXcgNgP6FekLHMiKEEBAJNxNd5s/IoN9B00+CrpNn+SEWLalLVPMu3lzmg2zVTM
=ZH3A
-END PGP SIGNATURE-

Re: [gentoo-dev] Lastrite: net-libs/xulrunner

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/06/12 10:07 AM, Ulrich Mueller wrote:
>> On Wed, 06 Jun 2012, Samuli Suominen wrote:
> 
>> # Samuli Suominen  (06 Jun 2012) #
>> Vulnerable and no longer used by anything in tree wrt #403415 #
>> Removal in 30 days  
> Why a version dependent mask? There's nothing >2.0.1-r1 in the
> tree.
> 
> Ulrich
> 

Other distros are distributing xulrunner-10, I expect the mask is
there because gentoo might do so as well soon, if/when the need arises.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/PaGIACgkQ2ugaI38ACPD4NgEAqa4brrpI8MIwZZn5b/Z9HEU2
FpUTwn8cVQAs8kbZKd8A/ityigdTOoYv76fslXOV0KtLN+8sJRc7kcmixjSJoyzb
=atcw
-END PGP SIGNATURE-

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/06/12 03:00 PM, Pacho Ramos wrote:
> El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió:
>> On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos 
>> wrote:
 I would prefer, as a workaround, allow reverse deps to
 RDEPEND on glib:2.* instead. That way it would cover more
 cases when more than two slots are available
>>> 
>>> Well, per: 
>>> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b
>>>
>>>
>>> 
looks like "*" usage for SLOTs would be allowed :), or I am
>>> misinterpreting it?
>> 
>> It's not a wildcard.
>> 
> 
> But it looks like a valid usage for cases like glib vs. 
> dbus-glib/gobject-introspection I have exposed as example, and
> also allows us to keep "SLOT" over "ABI_SLOT" (at least for this
> case, not sure about others I could be missing now...)


How is the case of something like libpng going to be handled, where we
only support one API (and so only one SLOT)?  Either in the proposed
ABI_SLOT thing or when using slot operators?

For the slot-operator case, will every consumer of libpng be forced to
change their dep to libpng:= to ensure they get rebuilt when libpng
bumps from 1.5 to 1.6??
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Q/XsACgkQ2ugaI38ACPCxWQEAgkx7C2PBK/awXvfA3RFolZQD
2K7G7cBboDvDexn/JogA/0W/ke62zz7Mtk/i6WLATIaUYRQ+8ViK2Y4J8n4C3yVZ
=SQX9
-END PGP SIGNATURE-

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/06/12 03:23 PM, Pacho Ramos wrote:
> El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió:
>> It's close enough to ABI_SLOT that it would make more sense just
>> to use ABI_SLOT because it's more flexible.
> 
> In that case, I think it's clear we need ABI_SLOT ;) The problem is
> how to document it in a way people agree with including it for
> eapi5 :|

If there's too much resistance it could wait for EAPI=6 couldn't it?
Essentially we'd all just agree that these issues, which ABI_SLOT will
be needed to effectively resolve, will have to wait and we shouldn't
do vast tree-wide workarounds like SLOT every library in existence and
require all consumers to have ':=' slot operators on their deps.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/SUwwACgkQ2ugaI38ACPCWtQEArkrEsVYa7/tJ8UT1pDBhDhsJ
+jdMEsbJa++3bWat9TUA/1YoEaOp3cGShNDraFv+cLQl2Qf+hpz3K1AasJVstQwa
=Nqw/
-END PGP SIGNATURE-

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/06/12 08:45 AM, Davide Pesavento wrote:
> On Sun, Jun 10, 2012 at 2:25 PM, Ciaran McCreesh 
>  wrote:
>> On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico
>>  wrote:
>>> A dependency atom will have optional SLOT and ABI_SLOT parts.
>>> Using the dbus-glib depedency on glib:2 as an example [1], the
>>> dbus-glib dependency will be expressed with an atom such as
>>> dev-libs/glib:2:= and the package manager will translate that
>>> atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always
>>> used to distinguish SLOT deps, and ':=' is always used to
>>> distinguish ABI_SLOT deps. Is that syntax good?
>> 
>> Here's a nicer syntax: no ABI_SLOT variable, and SLOT="2/2.32".
>> Then you can do explicit :2/2.32 dependencies if you like, or :2
>> (which would match SLOT="2" or SLOT="2/anything"), or :2= (which
>> gets rewritten to :2/2.32=) or :2*. If an ebuild does SLOT="2",
>> it's treated as 2/2.
>> 
> 
> I was going to propose a very similar syntax, i.e. using a slash
> to separate the regular SLOT part from the new ABI part, so +1 for 
> Ciaran's proposal.
> 
> Thanks, Pesa
> 

This looks very promising -- then for libs where we only want to
support one API, we could still use SLOT=0 via (ie for libpng)
SLOT="0/1.5"

+1

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Um/YACgkQ2ugaI38ACPDuDwD9F0mLVsh1rwUufL2HCB0Jjl2b
KkNa5z9I4s6lDQmPdIoBAKlPBrtN4C87qFjeJRBkytJvRn8ZF82kSQ0R7ik3UPqc
=EYRI
-END PGP SIGNATURE-

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/06/12 06:49 PM, Brian Harring wrote:
> On Sun, Jun 10, 2012 at 01:25:55PM +0100, Ciaran McCreesh wrote:
>> On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico
>>  wrote:
>>> A dependency atom will have optional SLOT and ABI_SLOT parts.
>>> Using the dbus-glib depedency on glib:2 as an example [1], the
>>> dbus-glib dependency will be expressed with an atom such as
>>> dev-libs/glib:2:= and the package manager will translate that
>>> atom to dev-libs/glib:2:=2.32 at build time. So, ':' is always
>>> used to distinguish SLOT deps, and ':=' is always used to
>>> distinguish ABI_SLOT deps. Is that syntax good?
>> 
>> Here's a nicer syntax: no ABI_SLOT variable, and SLOT="2/2.32".
> 
> Hate the slash; just looks ugly to me (so starts the bikeshed).
> 
> Sans that naggle, notions fine however; not sure I'm a fan of
> people being able to specify the exact ABI they need from an ebuild
> while it's in source form, but may be of use for emul-* packages.
> 
> ~harring
> 

It's power will come from detection of the different SLOT= assignment
between ebuilds of a particular library package.  I don't forsee that
there is going to be very much usage of the '/[ABI]' part in *DEPEND.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/XX7QACgkQ2ugaI38ACPDo6QD/XqsVP0UWmLrzxwFF1f2W6UsM
aA3wM6aqYX+wc+uHGTAA/jk8jz6kCs5rEudSWWXYndg6LEKp1Rj+YC/C7tLlk9uW
=tDdT
-END PGP SIGNATURE-

[gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey all - I'd like to propose that enewuser forces updates to a user's
home dir and shell whenever it is called, so that if this changes with
new versions of an ebuild it is dealt with automatically rather than
having to modify them in pkg_postinst/pkg_setup directly.

Here's my proposed patch to user.eclass -- please note that I can't
conform the syntax for the darwin ('dscl') calls as I don't have
access and my googling did not provide an exact-match in terms of
usage.  The rest i'm highly confident will work based on the manpages
I was able to find.  If anyone has these platforms and can test/update
the calls, I would appreciate it.


- --- user.eclass 2011-12-19 14:38:34.0 -0500
+++ user.eclass.forcehomedir2012-06-13 11:54:26.0 -0400
@@ -230,24 +230,39 @@
for g in "${egroups_arr[@]}" ; do
dscl . merge "/groups/${g}" users "${euser}"
done
+   ### force updates of some user properties
+   dscl . change "/users/${euser}" home "${ehome}"
+   dscl . change "/users/${euser}" shell "${eshell}"
;;

*-freebsd*|*-dragonfly*)
pw useradd "${euser}" "${opts[@]}" || die
+   ### force updates of some user properties
+   pw usermod "${euser}" -d "${ehome}" || die
+   pw usermod "${euser}" -s "${eshell}" || die
;;

*-netbsd*)
useradd "${opts[@]}" "${euser}" || die
+   ### force updates of some user properties
+   usermod -d "${ehome}" "${euser}" || die
+   usermod -s "${eshell}" "${euser}" || die
;;

*-openbsd*)
# all ops the same, except the -g vs -g/-G ...
useradd -u ${euid} -s "${eshell}" \
-d "${ehome}" -g "${egroups}" "${euser}" || die
+   ### force updates of some user properties
+   usermod -d "${ehome}" "${euser}" || die
+   usermod -s "${eshell}" "${euser}" || die
;;

*)
useradd -r "${opts[@]}" "${euser}" || die
+   ### force updates of some user properties
+   usermod -d "${ehome}" "${euser}" || die
+   usermod -s "${eshell}" "${euser}" || die
;;
esac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/YuRAACgkQ2ugaI38ACPCCxgD/TUhHRThNOHOGoR04CwRwx+Nt
oEJy0MdknD0KDm/uT5oA/AiYZ9fDthJEmPyOgFra+BnWqLCkexvqz+K5SaoS1Pyw
=+xJb
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/12 01:19 PM, Michał Górny wrote:
> On Wed, 13 Jun 2012 12:00:16 -0400 Ian Stakenvicius 
>  wrote:
> 
>> +   ### force updates of some user properties + 
>> usermod -d "${ehome}" "${euser}" || die +   usermod 
>> -s "${eshell}" "${euser}" || die
> 
> I think usermod can handle multiple arguments.
> 

It can, but I figured it would be easier to debug if something failed,
if each modification was on the same line.  Easy to modify it to be a
one-liner, however (and iirc all but possibly dscl can do this in a
single call)


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/YzAsACgkQ2ugaI38ACPAz/AD8DI/5ZynrT/+0rDrgNGPM06l9
dUk/4JSiXKZuxxn7H4oBAL4eHwrPQXXrJWfYDY61QorFqhmVkl5oJdxS4is5WkQQ
=YoDC
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/12 02:18 PM, Mike Gilbert wrote:
> On 6/13/2012 12:00 PM, Ian Stakenvicius wrote:
>> Hey all - I'd like to propose that enewuser forces updates to a
>> user's home dir and shell whenever it is called, so that if this
>> changes with new versions of an ebuild it is dealt with
>> automatically rather than having to modify them in
>> pkg_postinst/pkg_setup directly.
>> 
> 
> Can you give an example of a case where modifying the home
> directory and/or shell is necessary? I don't really understand how
> this is useful.
> 
> Also, grobian raised a good point in that the sysadmin may have
> changed it manually. It might be better to ewarn and make the user
> deal with it.
> 

The best example at this moment is for a polkit update.  ssuominen can
give you the details.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y23oACgkQ2ugaI38ACPAnTAEAms2KIHwFJwa+fzyXKmnAL/UL
vAcMqAwwp2+A05NUWisA/i6JF4zAB+AVE7nrSDEUCH0DZcq84MBOBshfUlQ1xidD
=MrnI
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/12 02:09 PM, Fabian Groffen wrote:
> On 13-06-2012 12:00:16 -0400, Ian Stakenvicius wrote:
>> Hey all - I'd like to propose that enewuser forces updates to a
>> user's home dir and shell whenever it is called, so that if this
>> changes with new versions of an ebuild it is dealt with
>> automatically rather than having to modify them in
>> pkg_postinst/pkg_setup directly.
> 
> What if some admin purposely changed home or shell for a system
> account? Would be quite annoying if every update would reset that,
> wouldn't it?
> 
> 


I considered this case, and that it might be more appropriate to
duplicate 'enewuser' into a new call 'eforceuser' (or similar) which
could be used instead of 'enewuser' in cases when the currently
provided user settings should be forced.

I decided against this as it seems also to make sense that users
created by portage should be controlled by portage.

I suppose probably the best means of handling this would be to somehow
detect whether or not the current user settings are default and only
apply the updates if they are; however a means of doing that (which
would be transparent to the ebuild) is somewhat beyond my knowledge
and abilities.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y3LYACgkQ2ugaI38ACPCKKwEAsA2kiUEj2Cz5DyuKzlVUvqlq
9N7TH6cEUN7ahL6IIgoA/iiJRJ065vQguz5PmitWVugycdNhm/DCyGcL8j0abcgA
=zd5h
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/12 01:21 PM, Ian Stakenvicius wrote:
> On 13/06/12 01:19 PM, Michał Górny wrote:
>> On Wed, 13 Jun 2012 12:00:16 -0400 Ian Stakenvicius 
>>  wrote:
> 
>>> +   ### force updates of some user properties + 
>>> usermod -d "${ehome}" "${euser}" || die +   usermod
>>>  -s "${eshell}" "${euser}" || die
> 
>> I think usermod can handle multiple arguments.
> 
> 
> It can, but I figured it would be easier to debug if something
> failed, if each modification was on the same line.  Easy to modify
> it to be a one-liner, however (and iirc all but possibly dscl can
> do this in a single call)
> 
> 
> 

As a follow-up to this, I believe it may be possible that my
suggestion is incorrectly coded when considering cases where shell and
home are not specified.  IE, the updates should be called
individually, and should only be called if their respective variable
($ehome, $eshell) is actually set.

I will post an update after some testing.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y37gACgkQ2ugaI38ACPB+RgD/a4qmpDYsTDCsgvsFmBSMnS9h
CWID5XVVGTPduEcqKeQA/jvpFyDuEd4zh5pSe/fPinq7xLw5lufy+rXq8nxcRsJm
=UofV
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/12 02:45 PM, Ian Stakenvicius wrote:
> On 13/06/12 01:21 PM, Ian Stakenvicius wrote:
>> On 13/06/12 01:19 PM, Michał Górny wrote:
>>> On Wed, 13 Jun 2012 12:00:16 -0400 Ian Stakenvicius 
>>>  wrote:
> 
>>>> +   ### force updates of some user properties + 
>>>> usermod -d "${ehome}" "${euser}" || die +
>>>> usermod -s "${eshell}" "${euser}" || die
> 
>>> I think usermod can handle multiple arguments.
> 
> 
>> It can, but I figured it would be easier to debug if something 
>> failed, if each modification was on the same line.  Easy to
>> modify it to be a one-liner, however (and iirc all but possibly
>> dscl can do this in a single call)
> 
> 
> 
> 
> As a follow-up to this, I believe it may be possible that my 
> suggestion is incorrectly coded when considering cases where shell
> and home are not specified.  IE, the updates should be called 
> individually, and should only be called if their respective
> variable ($ehome, $eshell) is actually set.
> 
> I will post an update after some testing.

Oh, and the code also doesn't do anything as if the user exists
enewuser still returns before any processing is done.  :)


> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y4DkACgkQ2ugaI38ACPDe2QD7B+MeuP7MYzShbmaHMBxxQzMu
yerItXd85EU9rKCDHa8A/R3CAgN2sGJIR+LWPjmaegj5UTHToPK1OcKPMmU7JQcx
=vb7t
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: enewuser should force updates to shell and home

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/12 03:04 PM, Mike Frysinger wrote:
> 
> we have egetshell and egethome already.  thus it's fairly easy to
> detect the transition case.  if they installed the older version
> which set values that you now want to change: if has_version
> ' esetshell user /good/shell fi if has_version ' $(egethome user) == "/old/home" ]] ; then esethome user /new/home 
> fi -mike



This makes sense to me.  Until I can think of a nice way to detect a
change from the default settings set by a previous enewuser call, it
is probably best to require each ebuild to do the above based on their
specific need.

Patch/RFC rescinded.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y5dcACgkQ2ugaI38ACPB9gQD/T3xPVAFfQCPGSuutLx/JwBnk
NCV/v5fn76iAVM2vTNsA/jms8yh7v/n1R5WwcAxmw4Ong+y7ufUMDq4jDNE6jJa5
=+sgH
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: esethome

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/12 03:14 PM, Mike Frysinger wrote:
> 
> eset{home,shell} don't exist today, so you should implement them
> :) -mike

RFC - heavily based on enewuser.

- --- user.eclass   [some timestamp]
+++ user.eclass.esethome  [some other timestamp]
@@ -388,3 +388,63 @@
 }

 fi
+
+# @FUNCTION: esethome
+# @USAGE:  
+# @DESCRIPTION:
+# Update the home directory in a platform-agnostic way.
+# Required parameters is the username and the new home directory.
+# Specify -1 if you want to set home to the enewuser default
+# of /dev/null.
+# If the new home directory does not exist, it is created.
+# Any previously existing home directory is NOT moved.
+esethome() {
+   _assert_pkg_ebuild_phase ${FUNCNAME}
+
+   # get the username
+   local euser=$1; shift
+   if [[ -z ${euser} ]] ; then
+   eerror "No username specified !"
+   die "Cannot call esethome without a username"
+   fi
+
+   # lets see if the username already exists
+   if [[ ! -n $(egetent passwd "${euser}") ]] ; then
+   ewarn "User does not exist, cannot set home. skipping."
+   return 1
+   fi
+
+   # handle homedir
+   local ehome=$1; shift
+   if [[ -z ${ehome} ]] ; then
+   eerror "No home directory specified !"
+   die "Cannot call esethome without a home directory"
+   fi
+
+   if [[ ${ehome} == "-1" ]] ; then
+   ehome="/dev/null"
+   fi
+   einfo " - Home: ${ehome}"
+
+   # update the home directory
+   case ${CHOST} in
+   *-darwin*)
+   dscl . change "/users/${euser}" home "${ehome}"
+   ;;
+
+   *-freebsd*|*-dragonfly*)
+   pw usermod "${euser}" -d "${ehome}" || die
+   ;;
+
+   *)
+   usermod -d "${ehome}" "${euser}" || die
+   ;;
+   esac
+
+   if [[ ! -e ${ROOT}/${ehome} ]] ; then
+   einfo " - Creating ${ehome} in ${ROOT}"
+   mkdir -p "${ROOT}/${ehome}"
+   chown "${euser}" "${ROOT}/${ehome}"
+   chmod 755 "${ROOT}/${ehome}"
+   fi
+}

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/Y64wACgkQ2ugaI38ACPBZYQD9EzzmBDUon1YUNxaev5ONluAX
2GA32hOyvwGs2ylZPy8A/3RN8VNsa6XI++eHRdwjpsSZLw4sTVpa+fY2LZHSnWsh
=gLrd
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: esethome

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/12 04:51 PM, Mike Frysinger wrote:
> On Wednesday 13 June 2012 15:35:40 Ian Stakenvicius wrote:
>> --- user.eclass   [some timestamp] +++
>> user.eclass.esethome  [some other timestamp] @@ -388,3 +388,63
>> @@ }
>> 
>> fi + +# @FUNCTION: esethome
> 
> has to be inside the giant if block.  so put this above the "fi".
> 
>> +# @USAGE:   +# @DESCRIPTION: +# Update the home
>> directory in a platform-agnostic way. +# Required parameters is
>> the username and the new home directory. +# Specify -1 if you
>> want to set home to the enewuser default +# of /dev/null. +# If
>> the new home directory does not exist, it is created. +# Any
>> previously existing home directory is NOT moved. +esethome() { +
>> _assert_pkg_ebuild_phase ${FUNCNAME} + +   # get the
>> username +   local euser=$1; shift +   if [[ -z ${euser}
>> ]] ; then +   eerror "No username specified !" +
>> die "Cannot call esethome without a username" +   fi + +
>> # lets see if the username already exists +   if [[ ! -n
>> $(egetent passwd "${euser}") ]] ; then
> 
> "! -n" -> "-z" -mike


So outside of syntax issues like above, anyone have any issues with my
adding this to user.eclass ?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/bNaoACgkQ2ugaI38ACPAFRgEApwLkrsqSIW0nVK4l/dUTRzV9
ijEnbfa+BLc1skwfW4QA+gKgpmsz/K5VqXnVWyXocGqO98RYJL8lL3qm7k0Hs6uZ
=9i38
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: VOICEMAIL_STORAGE as a USE_EXPAND for net-misc/asterisk

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13/06/12 06:30 PM, Tony "Chainsaw" Vroon wrote:
> Good evening,
> 
> As per bug #421037, there is a demand to make multiple voicemail
> storage backends switchable within the ebuild. The USE_EXPAND
> mechanism would automatically provide an explanation of the
> selections being made (as opposed to overloading USE=odbc in what
> seems to me a non-obvious way). The dev manual suggests this is
> presented for discussion, so here we are. Thoughts?
> 
> Regards, Tony V.

I haven't used asterisk for a long time, but this makes a lot of sense
to me.  +1



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/bNmcACgkQ2ugaI38ACPDbUAD/XoQ0aQDp8NSFidzlP69ImpqA
X8D1UvMJrvxPOf8wUOEBALTaKaeo5eT27XPTtZE4MUHHDJnrsyHMraVC/dYlQuoM
=Hn8k
-END PGP SIGNATURE-

Re: [gentoo-dev] New global USE flag "gs" (app-text/ghostscript-gpl)

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14/06/12 07:58 PM, Peter Stuge wrote:
> Samuli Suominen wrote:
>> 9'ish consumers. I propose "Enable support for the PostScript
>> language"
> 
> Perhaps "ps" or "postscript" instead of the implementation-centric 
> "gs" ?
> 
> 
> //Peter
> 


I think based on the consumers described we should keep the flag as
'gs' as this is primarily for ghostscript-based support and not
generic postscript capability.

That said, there's only nine of them, and as I can't see that many
more packages suddenly including support for ghostscript I don't see
that much of a need in making this flag be global...?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/bOAYACgkQ2ugaI38ACPC9OwD/W0ofi+chYYZ+k5ABo+VfODHs
F/83jl30ru+iOakp/nkA/Rg+8H6wrNyR/1BAe78T2UfhgMEtGOQy16TA+UrmPrO6
=YpRu
-END PGP SIGNATURE-

Re: [gentoo-dev] New global USE flag "ps"

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14/06/12 10:43 PM, Samuli Suominen wrote:
> On 06/15/2012 05:02 AM, Mike Frysinger wrote:
>> On Thursday 14 June 2012 21:16:31 Samuli Suominen wrote:
>>> So how about renaming USE="gs" consumers to USE="ps" and making
>>> USE="ps" global flag with the proposed description?
>> 
>> merging is a good idea.  getting away from "ghostscript" is good.
>> i might suggest expanding "ps" to "postscript" though as "ps" is
>> a bit generic ... -mike
>> 
> 
> well, I admit I was sort of trying take the shorter road (less to
> rename :-)
> 
> so yeah, USE="postscript" it shall be unless someone objects...
> 
> - Samuli
> 

This makes sense globally, +1

As mentioned some packages (graphviz comes to mind also) will need to
keep 'gs' locally since it is used as a ghostscript-specific flag.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/bOMgACgkQ2ugaI38ACPBkmgD/W05LR/3OmEFmzba/x0YLjsP+
6UUzcPwxRbJ3ArjIza0A/1XgPGoecSrrqAKhLi2SiqyqpwolOw3MP+ol1Oa85/DP
=iQRE
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: esethome

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/06/12 09:27 AM, Peter Stuge wrote:
> Mike Frysinger wrote:
>>> +   # lets see if the username already exists +   if [[
>>> ! -n $(egetent passwd "${euser}") ]] ; then
>> 
>> "! -n" -> "-z"
> 
> Does the $() argument ever need to be double quoted, or do all 
> versions of bash actually have the string argument optional even 
> though that's not what the man page reads?
> 
> 
> //Peter


Ever?  Yes, but only if what is being returned can contain spaces (and
this matters in the way that it's used).  In the case of 'egetent
passwd', afaict no as it doesn't return anything with whitespace in it.

Examples -- this works:

$ bubba="test thing" ; if [ -n "$(echo $bubba)" ]; then echo OK; fi
OK

Example -- this fails:

$ bubba="test thing" ; if [ -n $(echo $bubba) ]; then echo OK; fi
bash: [: test: binary operator expected

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/bOioACgkQ2ugaI38ACPAUegD+JPzG4oX25QcqXYSfp/c2IE5o
aydKUHZonedILskm5UoA/2bnn2PMFh5lm1rXh7H4/2d9MQaghAUlCmMv0/XORQtW
=7fD+
-END PGP SIGNATURE-

Re: [gentoo-dev] About what would be included in EAPI5

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/06/12 09:37 AM, Pacho Ramos wrote:
> El sáb, 16-06-2012 a las 13:43 +0100, Ciaran McCreesh escribió:
>> On Sat, 16 Jun 2012 14:26:16 +0200 Pacho Ramos 
>> wrote:
>>> About suggesting new item (like forcing rebuilding of other
>>> packages as discussed some days ago and crosscompile support
>>> suggested by Tommy today), I guess we need to get them voted by
>>> the council?
>> 
>> No. You need to get a draft diff for PMS written, along with an 
>> implementation in a package mangler of your choice and proof that
>> it works in practice.
>> 
> 
> Umm, this way to work makes any suggestion for future eapis to be 
> accepted only if they come from people able to prepare that 
> implementation in the package manager their prefer and, then, be
> stalled more and more time :|
> 

This makes sense to me - the original idea can come from anyone, but
unless there is support by dev(s) that can maintain the package
manager(s) and are willing to implement the proposed change, these
ideas won't go anywhere anyways.  Council can't make anything be
implemented, after all.  Also, if there is a working test
implementation when the vote happens then it's a fairly quick process
to full implementation once the EAPI is approved.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/fM1cACgkQ2ugaI38ACPDJkAD+I1Y/4BSTz8u6QAIepvFj7Pks
HoKuSdhyEsZHhD9GGOUA/1qYM8uJ6SZBC3dfJnBQOpXo6ZLz3f7e4lbEIc1BXHbc
=td0e
-END PGP SIGNATURE-

Re: [gentoo-dev] About what would be included in EAPI5

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/06/12 12:18 PM, Ciaran McCreesh wrote:
> On Sat, 16 Jun 2012 17:24:22 +0200 Peter Stuge 
> wrote:
>> Ciaran McCreesh wrote:
 Could it work to make automatic signatures of imported ABI,
 and simply compare signatures when a provider package is
 updated?
>>> 
>>> No.
>> 
>> Can you say why?
> 
> There's no way for a program to work out what "the ABI" of
> something is (whatever that means), and there's even less of a way
> for it to know up-front.
> 

I believe what Peter might've been referring to would be some form of
hashing of each and every library that is installed by a package.
Just as a basic idea, one could probably (for instance) grab the
LTVERSION of a libtool-built library, store that along with the emerge
info, and link this same version when consumer ebuilds are built
against it; then if the signatures changes the consumer ebuilds that
were built against the (now incompatible) old signatures could be
triggered for a rebuild.

I'm not saying that this is a viable approach, simply describing a
theoretical way it could be implemented.

One of the "advantages" of going this way, though, is that it would
probably be EAPI-independent as everything would be done internally by
the PMS.  The primary disadvantages I see is that 1-getting "library"
signatures would be difficult, 2-many orders of magnitude of
additional preprocessing would be necessary to build the deptree,
3-there wouldn't be any viable way for developer-based intervention
when necessary.

Finally, the above is just an example; I don't want to discuss merits
of an approach like this or entertain possible implementations.


>>> Also, can we stop using the term "ABI" in reference to this
>>> please? It's misleading. Let's call them sub-slots instead.
>> 
>> I think ABI fits well though? The situation is that A DEPENDs on
>> B, and at some point B changes in a way that A must be rebuilt in
>> order to run - right?
>> 
>> The only reason that A wouldn't run anymore is that B's ABI
>> changed?
> 
> ABI has a fairly specific, technical meaning, which can be
> misleading in the general case. Is Python bytecode an ABI?
> 

Isn't Python bytecode an ABI, given that it's built or tied to a
particular version (major.minor) of python??  (i'm actually asking
here, i avoid python so I don't really know if a .pyc from say
python-2.5 will just work with python-2.7 or if the original script
would need to be recompiled)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/fOPMACgkQ2ugaI38ACPCnpQD9Eu8uT2NABFQpb1ym5GeWUs0L
SY+t0wWh6saGXyfVja8BAIYMB0Q21qukus/rH3gDdf98AZYgOiXA20tg+dQyHZ26
=grcA
-END PGP SIGNATURE-

Re: [gentoo-dev] About what would be included in EAPI5

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/06/12 12:24 PM, Ciaran McCreesh wrote:
> On Sat, 16 Jun 2012 17:16:34 +0200 Pacho Ramos 
> wrote:
>> I can try to check it if no maintainer shows more packages 
>> showing this stable API unstable ABIs issues
> 
> Please do. This is a fairly important point: if the number of
> affected packages is small, there's no point in introducing
> sub-slots.
> 

I don't know about that -- I think we still very much need sub-slots.
 There is still a rather important distinction here -- SLOTS are
currently used not to specify API, but to specify particular API
groups that developers of said package are willing to support being
installed (usually in parallel).  For cases when developers decide it
is not a good idea to support multiple APIs at a time (i go back to
libpng here as an example of this current practice), 'SLOT=0' is still
a valuable specification.  Sub-slots will allow the actual API to be
specified in this case (which as has been described will trigger
rebuilds of consumers when necessary, if consumers *DEPEND on 'pkg:0='
or whatever the exact syntax will be)

It's one thing for slot-operators in EAPI=5 to provide new tools to
ensure better dependency handling; it's something else to assume the
entire tree is going to be converted so that every package acting as a
dependency will have a SLOT= reflecting the true API version rather
than SLOT=0

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/fO/gACgkQ2ugaI38ACPBlNwD6Aw39lxsdGFSmHUqnzU+37A1P
Z4x5TAtIrFsk7qK4y80A/RFpvD3J4YL8xonLKDWsey14BsKgq1Yz3VD5wlyDKJFd
=FhFC
-END PGP SIGNATURE-

Re: [gentoo-dev] [RFC] Dynamic SLOTs

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/06/12 11:53 AM, Michał Górny wrote:
> On Sun, 17 Jun 2012 17:46:00 +0200 Thomas Sachau 
> wrote:
>>> 
>>> ... If I weren't using 32-bit libs, and now I want to compile
>>> 32-bit wine, I have to recompile most of my libraries for both
>>> ABIs. That is a no go for me.
>> 
>> So you want to build a 32bit package, which is depending on
>> 32bit libs, but want to do that without the needed dependencies?
>> Please tell me, how that works.
> 
> I'm trying to build a 32bit package and its 32bit dependencies.
> Your solution involves building a 32bit package and rebuilding all
> 64bit packages which happen to be its dependencies for no reason.

Wait, so a package will be re-emerged but only for the new ABI?  So
we're looking at partial package installing now?

Or is this going to make multi-ABI installs be more like the way
crossdev works, where each individual package supporting multiple ABIs
will be installed multiple times, independently?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/fQAEACgkQ2ugaI38ACPCtFwD7BzuNxk00HgBfK5zd9dOwhcPw
YJVvpXZR0AXtQyx46RQA/jR8Uqv1T99Tc+vhMWsGHLzfMDRR2DU8FlSFswQ2PG11
=eeDE
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Killing UEFI Secure Boot

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/06/12 05:33 AM, Richard Yao wrote:
> On 06/21/2012 04:08 AM, Duncan wrote:
>> Richard Yao posted on Wed, 20 Jun 2012 18:16:23 -0400 as
>> excerpted:
>> 
>>> 3. How does getting a x86 system to boot differ from getting a
>>> MIPS system or ARM system to boot? Does it only work because
>>> the vendors made it work or is x86 fundamentally harder?
>> 
>> I can answer this one.  x86 is harder at the bootloader stage,
>> but in turn easier, or perhaps simply different, at the kernel
>> and kernel device interface level.
>> 
>> Consider, most MIPS and ARM systems ship with a specific set of
>> basic devices, configured to use specific IO addresses, IRQs,
>> etc, and that's it, at least to get up and running (USB devices,
>> etc, may be able to be plugged in, but they're not normally
>> needed for boot).  If you've been keeping up with the kernel (say
>> via LWN, etc), this has been one of the big deals with the ARM
>> tree recently, as until now each "board" had its own hard-coded
>> kernel config directly in the tree, and it was getting 
>> unmanageable.  They're switching to "device tree", etc, allowing
>> the boot loader to feed the kernel a file with this information
>> at boot time, thus allowing a whole bunch of different boards to
>> boot off the same shipped kernel, while at the same time getting
>> the explosion of individual board files out of the kernel tree.
>> This is a BIG deal on ARM and similar embedded archs, but doesn't
>> affect x86 (either 32-bit or 64-bit) at all.
>> 
>> Meanwhile, on x86, the system must be prepared for end-user
>> switch-out of pretty much everything. memory, storage (consider
>> floppy, hard drive, optical disk either direct or el-torito, USB
>> stick, etc, all bootable and all end-user changable!), even
>> quantity and speed of CPUs, and the firmware BIOS (or
>> replacement) must cope with that and be able to boot off it.
>> Even back in the 386 era when everything was jumper-configured, 
>> users could still change pretty much everything out, other than
>> the mobo itself.   Now days, it's even MORE complex, as most of
>> these devices can be configured in dozens or hundreds of mode
>> combinations via "plug-n- pray", and they often don't /have/ a
>> default -- they **MUST** be so configured in ordered to be
>> operable for the intended use.  Sure, the BIOS CAN leave some of
>> it for the kernel to do, but other bits, not so much, as
>> otherwise, how does the kernel even get loaded -- the BIOS must 
>> pick one of the many boot options, configure it (as well as the
>> CPU and the system between storage and the CPU, storage chipset,
>> memory, etc) at least well enough to read in the boot loader
>> and/or kernel.  None of that's necessary on ARM, etc, because
>> (pretty much) everything there's a totally arbitrary-as-shipped
>> config, nothing to dynamically negotiate and get working before
>> the kernel or secondary bootloader (after the BIOS) can even
>> work!
>> 
> 
> A firmware replacement for the BIOS does not need to worry about
> floppy drives, hard drives, optical drives, usb devices, isa
> devices, pci devices and pci express drives, etcetera, because
> those live on buses, which the kernel can detect. It would need a
> device tree to inform the kernel of what buses are available, but
> that would be specific to a given board, rather than what is
> attached to it. If the end user makes hardware changes, the kernel
> should be able to handle that, with the exception of changes
> involving RAM, which I believe go into the device tree.

I take it the above statement is based on the kernel being directly
placed within the BIOS/firmware/nvram on the board, such that you
couldn't boot anything else but that kernel?  Otherwise I don't see
how you could get away with the BIOS not worrying about all those
devices..  IE, I don't forsee many general x86 users giving up their
ability to boot off usb stick or cdrom or pxe based on a boot-time
bios choice, or to boot windows or alternative linux kernels (which
could be located who knows where) at whim.  And I don't see how an
alternative BIOS would be able to provide this ability without dealing
with all the things Duncan mentioned...


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/jNvoACgkQ2ugaI38ACPD0WwD+LM1PrRtpHIrxEgWcOKKd85uU
7JAmad5qJ7ft0mO7QlIA/2esLqMEfWgiLYko/GoHOuIq01PS1ou9XoePUuOtfCsI
=CwME
-END PGP SIGNATURE-

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/06/12 03:05 PM, David Leverton wrote:
> Michał Górny wrote:
>> Hello,
>> 
>> A simple solution to a program long-unsolved. In GLEP form.
> 
> Just a couple of minor points/nitpicks:
> 
> [ Snip! ]
> 
> 2) It's not forbidden for package A to depend on an IUSE_RUNTIME
> flag of package B being disabled, but it's unlikely to be useful.
> To make this more concrete, a fictional but vaguely plausible
> example:
> 
> app-text/docmangler:
> 
> # links to poppler to handle PDFs, and can use Ghostscript for #
> PostScript support if available IUSE="postscript" 
> IUSE_RUNTIME="postscript" DEPEND="app-text/poppler" 
> RDEPEND="${DEPEND} postscript? ( app-text/ghostscript )"
> 
> app-misc/coolapp:
> 
> IUSE="doc" # if Ghostscript is installed, docmangler uses it for
> both # PostScript and PDF files, but Ghostscript misrenders our
> PDFs DEPEND="doc? ( app-text/docmangler[-postscript] )"
> 
> Here, the [-postscript] dep would force the user to disable that
> flag, but it wouldn't do much good because Ghostscript would still
> be installed.  This doesn't happen with regular USE flags because
> (if the ebuild is written correctly) disabling the flag removes the
> feature even if its dependencies happen to be installed.
> 
> Possible solutions:
> 
> a) automatically rewrite the dep as postscript? (
> app-text/ghostscript ) !postscript? ( !app-text/ghostscript ) b)
> forbid [-foo]-style deps for IUSE_RUNTIME flags (would also make 
> sense in that case to disallow them in !foo-style conditionals in
> the dependencies of the package itself, as that could cause similar
> paradoxes) c) don't address it in the spec itself, and require
> people to manually write the dep in the blocker form if it's
> required d) something else?
> 
> a) is pretty icky IMHO, especially if the flag pulls in multiple 
> packages.  I could live with either b) or c), but b) is less
> flexible and c) leaves a potential trap for the unwary.  Any
> opinions?
> 

I'd say (c) , since IUSE_RUNTIME is not an enforceable state of the
tree and if docmangler is used but fails when ghostscript is installed
anyways, then the DEPEND should specify this regardless of whether the
'postscript' flag (used by IUSE_RUNTIME) is set or whether ghostscript
is in the user's world file.





-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/jc+cACgkQ2ugaI38ACPCUOAD+ICKl69MUhUTRj+2HBQ0pNlvo
Bqa5/TmaD0oKIkLi+xgBAIGwynEBXC3dXsG7Amky0OiEUyen41kURybNLR8FIkT2
=jMZ4
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Killing UEFI Secure Boot

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/06/12 08:24 PM, Richard Yao wrote:
> On 06/21/2012 06:51 PM, Rich Freeman wrote:
>> we're a DISTRO - we integrate and ship what upstream gives us...
> 
> RHEL is a distribution, but I understand that RedHat does a great
> deal of upstream programming and is also upstream for some things.
> Do you consider it to be inappropriate for us to play a larger role
> in both upstream development and as upstream ourselves?
> 

As a gentoo developer in general?  Absolutely not.  Through discussion
on this list specifically?  possibly.  :)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/kbQEACgkQ2ugaI38ACPDCrAEAquDX0hrTUufGqXhSG2Cv+yLU
bmw3WpMa17OHSmbZ+3QA/Am2K80tHFGDA7uklTUm6Lxe8wynVRTNrmpD93qTlJ4R
=gO47
-END PGP SIGNATURE-

Re: [gentoo-dev] [pre-GLEP] Optional runtime dependencies via runtime-switchable USE flags

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 22/06/12 12:48 AM, Zac Medico wrote:
> On 06/21/2012 02:32 PM, David Leverton wrote:
>> Michał Górny wrote:
>>> But in the current form, the spec doesn't allow passing 
>>> IUSE_RUNTIME flags to has_version() so we're on the safe side
>>> :P.
>> 
>> True.  Do we want to keep it that restrictive?
> 
> Shouldn't has_version allow any atom that would be allowed in
> *DEPEND?

Technically it could, but the issue here would be what you are going
to do with a has_version check on an IUSE_RUNTIME dep -- the package
should do filesystem-identical installs no matter what status of
IUSE_RUNTIME flags, so whatever one would do with a has_version check
would have to not change any part of the build or installation.

I could see it being of use within pkg_configure(), though; ie, emerge
- --config pkg should then be able to reliably set up default configs
based on the runtime installs.   However, that's the only place I can
picture it being viable.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/kdmIACgkQ2ugaI38ACPBtsQEAs1Ak9JQnDFt4XuG/4ZfYGfH2
u92QpchtCGHhYbERx1wA/3AyghQuEv8WZ2iIfXoW9zWnelutj5fdqF4adSjMwf9x
=0XPN
-END PGP SIGNATURE-

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23/06/12 08:42 PM, Zac Medico wrote:
> On 06/10/2012 11:18 AM, Zac Medico wrote:
>> On 06/10/2012 05:25 AM, Ciaran McCreesh wrote:
>>> On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico
>>>  wrote:
 A dependency atom will have optional SLOT and ABI_SLOT parts.
 Using the dbus-glib depedency on glib:2 as an example [1],
 the dbus-glib dependency will be expressed with an atom such
 as dev-libs/glib:2:= and the package manager will translate
 that atom to dev-libs/glib:2:=2.32 at build time. So, ':' is
 always used to distinguish SLOT deps, and ':=' is always used
 to distinguish ABI_SLOT deps. Is that syntax good?
>>> 
>>> Here's a nicer syntax: no ABI_SLOT variable, and SLOT="2/2.32".
>>> Then you can do explicit :2/2.32 dependencies if you like, or
>>> :2 (which would match SLOT="2" or SLOT="2/anything"), or :2=
>>> (which gets rewritten to :2/2.32=) or :2*. If an ebuild does
>>> SLOT="2", it's treated as 2/2.
>> 
>> Yes, I prefer your syntax.
> 
> In portage-2.1.11.1 and 2.2.0_alpha112 I’ve added support for EAPI 
> “4-slot-abi”:
> 
> 
> http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/


Does
> 
anyone have a fork of the tree that's being converted to test
this new functionality?  If so I'd like to sign up.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk/oYYcACgkQ2ugaI38ACPBZ3QEAkXXOmiTdC/7Hgl84c2oSlwbM
5YNUbcgh6wI59FTCAboA/RGdo1YptVCvmHYlyvJ2VKNY98pq2g+FKhY1T7SAbrlo
=hXfd
-END PGP SIGNATURE-

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 25/06/12 01:58 PM, Zac Medico wrote:
> On 06/25/2012 06:03 AM, Ian Stakenvicius wrote:
>> On 23/06/12 08:42 PM, Zac Medico wrote:
>>> On 06/10/2012 11:18 AM, Zac Medico wrote:
>>>> On 06/10/2012 05:25 AM, Ciaran McCreesh wrote:
>>>>> On Sat, 09 Jun 2012 13:55:53 -0700 Zac Medico 
>>>>>  wrote:
>>>>>> A dependency atom will have optional SLOT and ABI_SLOT
>>>>>> parts. Using the dbus-glib depedency on glib:2 as an
>>>>>> example [1], the dbus-glib dependency will be expressed
>>>>>> with an atom such as dev-libs/glib:2:= and the package
>>>>>> manager will translate that atom to dev-libs/glib:2:=2.32
>>>>>> at build time. So, ':' is always used to distinguish SLOT
>>>>>> deps, and ':=' is always used to distinguish ABI_SLOT
>>>>>> deps. Is that syntax good?
>>>>> 
>>>>> Here's a nicer syntax: no ABI_SLOT variable, and
>>>>> SLOT="2/2.32". Then you can do explicit :2/2.32
>>>>> dependencies if you like, or :2 (which would match SLOT="2"
>>>>> or SLOT="2/anything"), or :2= (which gets rewritten to
>>>>> :2/2.32=) or :2*. If an ebuild does SLOT="2", it's treated
>>>>> as 2/2.
>>>> 
>>>> Yes, I prefer your syntax.
>> 
>>> In portage-2.1.11.1 and 2.2.0_alpha112 I’ve added support for
>>> EAPI “4-slot-abi”:
>> 
>> 
>>> http://blogs.gentoo.org/zmedico/2012/06/23/automatic-rebuilds-with-experimental-eapi-4-slot-abi/
>>
>>
>>
>>> 
Does
>> 
>> anyone have a fork of the tree that's being converted to test 
>> this new functionality?  If so I'd like to sign up.
> 
> That would be nice to have, but I haven't heard of anyone doing it
> yet.


Well, I am now.  If anyone wants to test, i'm going to make an attempt
to keep the following overlay in sync with the main tree within a
24-hour delay (excluding weekends).

git://git.overlays.gentoo.org/dev/axs.git

FYI, all the work subslotting the perl stuff doesn't work yet, so it's
probably best to wait a few days before trying it out.

Sorry, no means of bug reporting on any of this yet (ie, don't file on
b.g.o about it), but i'm in #-dev on freenode most weekdays.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/rYTgACgkQ2ugaI38ACPAOvwD/WBqDNCnCJLZw+2302SJOZzO4
cDYOcr3nNk5JeMVz1YAA/jrllZuqcl2skF0WBf4ku8Jb8dsTucddqB3SarxSBB25
=Efzw
-END PGP SIGNATURE-

Re: [gentoo-dev] Feature Request/RFC : "Elective" virtuals

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28/06/12 09:41 PM, Kent Fredric wrote:
> I was doing a fresh Gentoo install today, following the manual, and
> it appeared to me that the manual suggests to install a "logger"
> and a "cron", and gives some defacto suggestions.
> 
> However, the available packages that provide this facility(s) are
> not overly obvious from a portage standpoint.
> 
> The best index I can find presently for a list of things that
> provide these facilities are virtual/cron , and virtual/logger ,
> and only then by perusing the source.
> 
> And if you tell somebody to install "virtual/cron", you'll get the 
> first thing in the ||( ) list, not an elective choice of which to 
> install.
> 
> It makes sense to me that there are some circumstances, where it
> makes sense to, instead of simply picking the first match, present
> the user with the option of one of them ( somehow ).
> 
> ie:   emerge -pv virtual/cron  could, instead of the current
> behaviour of installing vixie-cron,show a list with the non-chosen
> alternatives:
> 
> What we presently get is this:
> 
> [ebuild  N ] sys-process/vixie-cron-4.1-r12  USE="pam -debug 
> (-selinux)" 0 kB [ebuild  N ]  virtual/cron-0  0 kB
> 
> Where it might be nice to instead give:
> 
> [ebuild  N ] sys-process/vixie-cron-4.1-r12  USE="pam -debug 
> (-selinux)" 0 kB [ebuild  ? ] sys-process/cronie-1.4.8
> USE="inotify pam" ( virtual/cron ) [ebuild  ? ]
> sys-process/dcron-4.5  44 kB ( virtual/cron ) [ebuild  ? ]
> sys-process/fcron-3.0.6-r1  USE="pam -debug (-selinux)"
> LINGUAS="-fr" 540 kB ( virtual/cron ) [ebuild  ? ]
> sys-process/bcron-0.09  57 kB ( virtual/cron ) [ebuild  N ]
> virtual/cron-0  0 kB
> 
> As a way to show that vixie-cron is being chosen as the default,
> but there are other things that can optionally provide that virtual
> too.
> 
> (* important: dependent children of the alternatives should not be 
> computed or displayed, as this will only add confusion, not to
> mention headaches, as all the above crons have blockers on each
> other to stop them being installed together )
> 
> This is the "Simplest" option I could think of that made it more
> "User facing" that these virtuals exist to provide a given feature
> using a mechanism of the users choice.
> 
> You could take this further and make an interactive choice system, 
> which was only presented in certain conditons, ie: if the ||( ) 
> condition was not already satisfied, or if the users command
> indicated they want to choose virtuals themselves:
> 
> emerge --virtuals=auto  # current behaviour emerge
> --virtuals=pick-missing # interactive choice only if the 
> conditionals are not already satisfied emerge
> --virtuals=pick-specified # interactive choice only for virtuals
> listed on the invocation line emerge --virtuals=pick-all #
> interactive choice every time
> 
> Theres possibly other avenues I haven't thought of that might also
> be useful.
> 
> The pick interface could be something like
> 
> virtual/cron  can be provided by one of the following 1)
> sys-process/vixie-cron (4.1-r12): Paul Vixie's cron daemon, a fully
> featured crond implementation 2) sys-process/bcron (0.09): A new
> cron system designed with secure operations in mind by Bruce
> Guenter 3) sys-process/cronie (1.4.8): Cronie is a standard UNIX
> daemon cron based on the original vixie-cron. 4) sys-process/dcron
> (4.5): A cute little cron from Matt Dillon 5) sys-process/fcron
> (3.0.6-r1): A command scheduler with extended capabilities over
> cron and anacron choice[1]:
> 
> *( list taken liberally from eix -c  )
> 
> Then the documentation could be updated to simply tell the user
> 
> emerge --virtuals=pick-specified virtual/cron virtual/logger
> 
> And they could then just use the defaults ( by pressing enter ),
> or choosing their favourite.
> 
> Also, perhaps "Virtuals" is a poor name for what mechanism I am 
> describing. There are potentially many things that want an
> elective process like this on many packages, but it seems a
> mechanism more prevalent in virtuals. Especially as this facility
> is mostly provided by the "USE" mechanism in most other places.
> However, in VIRTUALS where you have a list of mutually exclusive
> alternates, a long list of USE flags with one of them defaulted via
> IUSE seems bad.  Not to mention, the mechanism for displaying what
> each individual USE flag will get you is a bit messy at present. (
> Being, you have to invoke some other portage command, and this
> requires you finding applicable documentation for that command, to
> work out how to query what each individual USE flag means , and
> then run a different command for each package you want to consider
> to see its description )
> 
> 

The reason for the virtual itself is so that all of the various
packages that can satisfy the virtual will satisfy all the consumers
(rdeps) of that virtual.  It's not so much for providing a shortcut
for the user; I haven't c

Re: [gentoo-dev] About forcing rebuilds of perl modules

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/06/12 05:30 AM, Zac Medico wrote:
> On 06/30/2012 01:46 AM, Torsten Veller wrote:
>> * Ian Stakenvicius :
>>> FYI, all the work subslotting the perl stuff doesn't work yet, 
>>> so it's probably best to wait a few days before trying it out.
>> 
>> Perl modules have to be rebuilt if dev-lang/perl's useflags are 
>> changed.
>> 
>> That would make dev-lang/perl's SLOT depend on users USE flags 
>> settings which is forbidden. Or will it work for sub-slot part? 
>> SLOT="0/5.16(?ithreads:-ithreads)(?debug:-debug)"
> 
> Maybe this useflags synchronization thing is best managed with the
>  existing USE deps support? So, if something interacts with perls 
> ithreads and debug flags, its dependency should be something like 
> dev-lang/perl[ithreads=][debug=].

I think this makes a lot of sense too -- use-flag synchronization
would probably be best handled outside of SLOT, otherwise we'd have to
implement dynamic slots to get this properly supported.

Now, that being said, it might be worthwhile if perl-module was
expanded a bit in relation to the *DEPEND it adds -- having a
PERL_MODULE_USES var or something, that could automatically append to
IUSE (if necessary) and set the use-deps on dev-lang/perl, would make
this a fairly simple implementation I think.

Do all packages need to be rebuilt when some of these use flags
change?  Maybe auto-appending those particular flags (ithreads, debug)
to IUSE and putting them on the dev-lang/perl dep is all that'll be
needed, if this is the case.

- -

On an semi-related note, I have noticed that there are a fair number
of ebuilds in the tree that are using perl-module at EAPI=4 and have
'perl? (dev-lang/perl)' in *DEPEND, but are not setting
GENTOO_DEPEND_ON_PERL=no before their inherit (and so perl is ALWAYS a
dep).  I'm thinking of filing bugs against all of these...

- -

Finally, thanks for testing!!  I hope to improve the overlay a bit by
the middle of next week, including a script that'll patch /var/db/pkg
to simulate 4-slot-abi always existing (so one doesn't have to emerge
- -e @world to get their environment ready to test).

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/vM28ACgkQ2ugaI38ACPAXlAD+KvzYGYMaTbgYS3eT6ADGzhEv
4+ehZ4PQ+9fNEyBMpn8A/2GXQqWY9erx+Dd8FL/jwk8KbReJoMwfffPEWCe38rfW
=4DDP
-END PGP SIGNATURE-

Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/06/12 11:16 AM, Mike Frysinger wrote:
> On Saturday 30 June 2012 07:22:39 Zac Medico wrote:
>> On 06/30/2012 04:07 AM, Pacho Ramos wrote:
>>> I would like to discuss a bit more issues like: 
>>> https://bugs.gentoo.org/show_bug.cgi?id=423087
>>> 
>>> Even if there are "a lot" of packages that can cause this
>>> breakage when downgraded, I think it should be prevented and
>>> package managers shouldn't try to downgrade this kind of
>>> packages as they will later cause a total breakage. People is
>>> not supposed to know that downgrading some package system will,
>>> for example, have an unusable gcc.
>> 
>> It seems like a die in pkg_pretend would serve pretty well.
> 
> doing it on a per-ebuild basis doesn't make much sense.  a simple
> version compare (like we do in glibc as an exception to this rule
> because of its much wider implication) is incorrect: the new
> version might not introduce any new symbols compared to the old
> one, and even if it has, other packages might not have been linked
> against the new symbols. -mike

Instead of preventing downgrade wouldn't it make more sense to figure
out a way to force a rebuild on @system or @toolchain or whatever bits
are broken as soon as the downgrade occurs, rather than just making it
a one-way ticket?  If we could sort this out (and sub-slots may help
with this, but probably we'll need some extra work too) then we could
probably support switching from ~arch to arch at a whim..  Not
necessarily a bad goal.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/vNKcACgkQ2ugaI38ACPDDgQD/XhgB1G6rIYXuhR/EnJDLyfgL
NKfW6TifMcJr9wHFNooA/2RDkxOSFePAHy81IxGWfjvpb2wNw4b/IzDwK8u4hcAS
=Q3Wd
-END PGP SIGNATURE-

Re: [gentoo-dev] About trying to prevent downgrades of packages that cause system breakage

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/06/12 01:30 PM, Pacho Ramos wrote:
> El sáb, 30-06-2012 a las 13:17 -0400, Ian Stakenvicius escribió:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> On 30/06/12 11:16 AM, Mike Frysinger wrote:
>>> On Saturday 30 June 2012 07:22:39 Zac Medico wrote:
>>>> On 06/30/2012 04:07 AM, Pacho Ramos wrote:
>>>>> I would like to discuss a bit more issues like: 
>>>>> https://bugs.gentoo.org/show_bug.cgi?id=423087
>>>>> 
>>>>> Even if there are "a lot" of packages that can cause this 
>>>>> breakage when downgraded, I think it should be prevented
>>>>> and package managers shouldn't try to downgrade this kind
>>>>> of packages as they will later cause a total breakage.
>>>>> People is not supposed to know that downgrading some
>>>>> package system will, for example, have an unusable gcc.
>>>> 
>>>> It seems like a die in pkg_pretend would serve pretty well.
>>> 
>>> doing it on a per-ebuild basis doesn't make much sense.  a
>>> simple version compare (like we do in glibc as an exception to
>>> this rule because of its much wider implication) is incorrect:
>>> the new version might not introduce any new symbols compared to
>>> the old one, and even if it has, other packages might not have
>>> been linked against the new symbols. -mike
>> 
>> Instead of preventing downgrade wouldn't it make more sense to
>> figure out a way to force a rebuild on @system or @toolchain or
>> whatever bits are broken as soon as the downgrade occurs, rather
>> than just making it a one-way ticket?  If we could sort this out
>> (and sub-slots may help with this, but probably we'll need some
>> extra work too) then we could probably support switching from
>> ~arch to arch at a whim..  Not necessarily a bad goal.
>> 
> 
> The problem is that, in this kind of breakage, gcc breaks as soon
> as zlib is downgraded and, then, user cannot compile anything,
> needing to manually find missing zlib lib from any other
> distributions binaries, put it in the system and re-emerge zlib :|
> 

..but preserved-libs would keep that from happening wouldn't it?  ie,
the lib itself would stick around until gcc isn't using it anymore...

so it'd just be a matter of an interim issue until preserved-libs is
in stable portage ...  and i'm guessing something that would suffice
here is a blockage on downgrades of anything belonging to the contents
of /var/db/edb/{sys-devel/gcc,sys-libs/glibc}-[0-9]*/NEEDED ?

(apologies for the bad hack:)

cat /var/db/pkg/{sys-devel/gcc,sys-libs/glibc}-[0-9]*/NEEDED \
  |sed -e 's#^/[^ ]* ##' |sed -e "s/,/\n/g" |sort -u \
  |xargs equery b |awk '{print $1}' |sort -u \
  |sed 's/^/

[gentoo-dev] EAPI=4-slot-abi testing now a little easier

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey all -- so with Zac's help I've got a script now that will
significantly speed up testing of EAPI=4-slot-abi from my ('axs') overlay.

The script upgrades your system's portage db (/var/db/pkg) so that any
EAPI=4 atoms currently installed will be upgraded to their
EAPI=4-slot-abi equivalents in the overlay (if they exist).  This is
relatively safe as 4-slot-abi is a direct superset of EAPI=4 and so
pkg_{pre,post}rm should not be negatively affected.

The script is bash, using grep, sed and awk heavily; it's not pretty,
but it works.  The tricky bit is re-working *DEPEND entries, as they
first need to reflect the updated ebuild (the vast majority of these
changes is the addition of slots and/or slot-operators; i'm trying to
keep all other deps the same as what's in the tree's version of the
ebuild), and then determine each dependency's new SLOT (and sub-slot)
so that it can be substituted into the slot-operator part of the
*DEPEND atom.  If I knew python well enough, I could've written
something that uses portage-'s own internals for this, but i don't
so i didn't.  If anyone's bored and wants to re-write/make a new vdb
update script in python, i'd be more than happy to put it on the overlay!

I've opened bug 424429 to help track 4-slot-abi issues as well as
issues with my overlay in general.  Please do not file separate bugs.

Ian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/wkGgACgkQ2ugaI38ACPBxGwD8C6oNk8CdQeLsfGJe2bK48UH/
A5aCVbDeBFFxrCjqBqABAJXsf/4sdLKnAj56j3CUukvu5RR5TRXw6U8V0h+a16We
=yIP+
-END PGP SIGNATURE-

Re: Dependent conditional dependencies, ( was Re: [gentoo-dev] Future EAPI feature Request/RFC: ^^( ) for [RP]?DEPEND )

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 03/07/12 05:05 AM, Kent Fredric wrote:
> On 3 July 2012 20:24, Michał Górny  wrote:
>> 
>> --depclean?
> 
> eix Module-Metadata [I] perl-core/Module-Metadata Available
> versions:  ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9<--- not unmasked
> by --autounmask Installed versions:  1.0.6(15:59:00 06/26/12) 
> Homepage:http://search.cpan.org/dist/Module-Metadata/ 
> Description: Gather package and POD information from perl 
> module files
> 
> [I] virtual/perl-Module-Metadata Available versions:  ~1.0.3
> ~1.0.4-r2 ~1.0.5 1.0.6 (~)1.0.9-r1 <- Unmasked by --autounmask 
> Installed versions:  1.0.9-r1(09:37:51 07/02/12) Description:
> Virtual for Module-Metadata
> 
> perl-Module-Metadata-1.0.9.ebuild
> 
> RDEPEND="|| ( =dev-lang/perl-5.16* ~perl-core/${PN#perl-}-${PV} )"
> 
> It appears yes, --depclean *will* reap perl-core/* in this scenario
> ( portage 2.2.0_alpha114 )
> 
> Just I don't tend to use --depclean an awful lot. Usually, I don't 
> expect to have to use --depclean to avoid a somewhat "broken"
> system.
> 
>> 
>> Doesn't perl-cleaner handle perl upgrades for this? And the
>> tested ABI_SLOTs should help with that too.
> 


Just to add a note in here, since the perl stuff is one of the first
things I converted to 4-slot-abi, unfortunately, no it doesn't seem
that ABI slots are going to help with this.  Sub-slots will trigger
rebuilds of anything built against an older perl when it's upgraded,
but it seems to have no effect on any of the virtual/perl-* stuff.
The only effect it may have is giving the ability to specify perl
versions via slots instead of wildcard-versions (ie:
=dev-lang/perl-5.16* would become dev-lang/perl:0/5.16 )

Some of these perl virtuals have rather convoluted perl versions
(like, all 5.16, all 5.14, only 2 versions of 5.12, and a particular
version of 5.10), and so I don't think sub-slot deps will help the
situation here as i don't think we could align the sub-slot bumps by
feature set, at least not right now..

One thing that sub-slots ARE doing, though, is they are (as far as I
can tell) not triggering rebuilds for any installed packages that are
superseded (and therefore their virtual is now satisfied) by the newer
perl.  I realize this didn't occur before either, but I don't know if
perl-cleaner handled their removal or not (or if perl-cleaner actually
rebuilt them)?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/zClIACgkQ2ugaI38ACPDIPwEAkd6hlmoMQ4SRhvkttoyP11ih
EKoR+tUNaMEqeb87T34A/irG+h8tPolXKsJQtEoRKr5xIGvWDYT83LlmV4fbOwui
=Vf92
-END PGP SIGNATURE-

Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/07/12 07:29 AM, Peter Stuge wrote:
> Zac Medico wrote:
>>> I'd suggest a special ebuild phase to check for ABI
>>> changes, like the pre_pkg_preinst_abi_check phase
>>> suggested here:
>>> 
>>> https://bugs.gentoo.org/show_bug.cgi?id=192319#c20
>> 
>> I guess, that phase would detect ABI change and package
>> manager would know how to handle it by itself?
>>> 
>>> Yeah, it would be like a warning system,
>>> 
>>> And once we bump SLOT/ABI_SLOT, package manager would know
>>> about how to handle that situation and rebuild needed stuff?
> 
> Is it unrealistic to assume that upstream ABI providers will mark 
> their ABIs by using sonames correctly?
> 
> Maybe that is at least the common case, then ABI_SLOT could be set 
> automatically.
> 
> Maybe I'm too far ahead, and baby steps are better.
> 

Although we have a lot of this information available (which is why/how
@preserved-libs works, for instance), there is no way for portage to
know *prior to emerging the update* if abi has changed.  This is why
it needs to be specified in the ebuild somehow (and sub-slots via
4-slot-abi seem very capable of handling this)

That said, while experimenting with 4-slot-abi porting on my overlay,
usually I am just specifying the major (or sometimes major.minor)
version parts of the sonames, since that seems to make the most sense
usually.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/4Q2IACgkQ2ugaI38ACPBzagD/blTq3Dq1K9Yrv2PdxSirxwu7
POUSNlLr59x8jKaE2oYBAIS+mATPRj3vn1W/uB37ipLmbg76gbcr7LTqh6Mb7Unv
=VKuj
-END PGP SIGNATURE-

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

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/07/12 06:40 AM, Rich Freeman wrote:
> On Wed, Jul 11, 2012 at 4:27 AM, Duncan <1i5t5.dun...@cox.net>
> wrote:
>> Being able to choose not to run systemd at all?  If there's no
>> need to build systemd, than what it requires is irrelevant.
> 
> I think this discussion is getting sidetracked.
> 
> This didn't start out as a discussion about whether everybody
> should have to have systemd on their systems - the answer to that
> is no.
> 
> The question is whether we should have a virtual for udev.  Right
> now we're not sure how that is going to be packaged as far as
> systemd is concerned, so it is premature to make that decision.
> However, if we do decide to fork udev then that means we'd almost
> certainly need to have a virtual.  At that point we'd have two
> different udev implementations in the tree - the fork and the one
> that comes bundled with systemd.
> 
> Where things get dicey is if the two udev implementations start to 
> diverge and packages need to behave differently depending on which
> one is installed - that would become a bit of a mess.  Hopefully it
> won't come to that.
> 


..although it possibly could come to that, if the fork maintains
installation in /{bin,sbin,lib} while systemd-udev follows the
upstream move to /usr/{bin,sbin,lib}


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/9eUkACgkQ2ugaI38ACPAFiwD/fAERfjHE0kHItPuBnCqH+669
flblkcc4/rMkAOQk8GUA/3MKU1j374JmcF9omXDFDJcq4SEJszKNL3tJGjgs0i0v
=dahJ
-END PGP SIGNATURE-

[gentoo-dev] udev <-> mdev

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/07/12 11:40 PM, Walter Dnes wrote:
> On Wed, Jul 11, 2012 at 09:49:18AM -0400, Michael Mol wrote
>> Walter Dnes (very active over in gentoo-user) has put a lot of
>> work into testing and documenting mdev as an alternative for 
>> udev. There's been a good deal of success there, up to and
>> including it working with GNOME 2. The work's been documented on
>> the wiki: https://wiki.gentoo.org/wiki/Mdev
> 
> I'm now testing automount under mdev.  No GUI required.  I hope to 
> have a wiki page up soon.
> 
> As for GNOME and KDE, they're trying to become OS's in their own 
> right.  What can I say?  There are a lot of alternative desktop 
> environments and window managers.  That's my target.
> 

Out of curiosity, since mdev is (i assume) more than complete enough
to handle mounting, would it be possible to initially start with mdev
and then hand over control to udev (if there was a need for udev, that
is) , to avoid initramfs with separate /usr ?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+0x0ACgkQ2ugaI38ACPB1zwD/UTRcKHG91/q9RyovsvChaPWE
voF+oOAl5mE6A6hoN5UA/12KAC5XHModBZqNkWYuMqpB2q67t4fWHhp/w5lL7u7Z
=3uUp
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Output / End User Experience

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/07/12 12:17 AM, Ben de Groot wrote:
> On 12 July 2012 06:51, Zac Medico  wrote:
>> 
>> Here's another related bug report, specifically about the solving
>> the libxml2/qt-webkit/chromium conflict:
>> 
>> https://bugs.gentoo.org/show_bug.cgi?id=426222
>> 
>> --
> 
> Actually, there is another workable solution, and that is to set 
> USE="-gstreamer -icu" for qt-webkit.
> 
> Currently we enable gstreamer by default in the ebuild (as it is
> used for HTML5 audio/video, which is expected functionality in
> qt-webkit based web browsers etc.), but we are considering if we
> should perhaps not enable this by default.
> 

Would the conflict go away if the rdeps of qt-webkit (these browsers)
still had a use dep on gstreamer?  IE, do these browsers tend to be
installed even though the user's installed/installing chromium ?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+04gACgkQ2ugaI38ACPDRUAD+MgphaweWeoPKBrZEJRY3LsTK
pfBUoCujOvXgicioP4EA/18m849xCRC3lXrjF1fbKBurQuqt56zvk5HQ/kWbhAlC
=6EZF
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: udev-rules.eclass

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/07/12 01:01 AM, Ben de Groot wrote:
> On 12 July 2012 07:42, William Hubbs  wrote:
>> On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò
>> wrote:
>>> Il 11/07/2012 21:11, William Hubbs ha scritto:
 I am about to release udev-186-r1, which will move everything
 currently in /lib/udev to /usr/lib/udev.
>>> 
>>> Unless you're going to establish a symlink, please keep it
>>> under p.mask until everything is using some common code —
>>> otherwise things _will_ break.
>> 
>> Since multiple packages put things in /lib/udev, I'm not sure it
>> is possible to establish a symlink from /lib/udev to
>> /usr/lib/udev if that's what you mean; I'll look into it though.
> 
> Couldn't you, on udev upgrade, move everything in /lib/udev to 
> /usr/lib/udev, and then make the symlink? Seems fairly simple to
> me, but maybe I'm overlooking something?
> 

A symlink isn't a good idea as, iirc, the new udev still -reads- from
both /usr/lib/udev and /lib/udev ..  so it'd have two sources for the
exact same rules; could be an issue.

Given this, the way I see it all we need is a helper s.t. all installs
going forward put the rules into the right place according to the
installed udev (or maybe the installed virtual/device-manager) so that
ebuilds/packages dont need to worry about setting the paths
explicitly; and eventually as things progress all the rules in
/lib/udev will get cleaned out in favour of /usr/lib/udev ...  ?

We could always just forgo the helper and make all packages migrate
via a >=udev-186-r1 dep and setting the rules install paths explicitly
to /usr/lib/udev ...  the helper (to me) just makes this cleaner in
the ebuild..


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+1J0ACgkQ2ugaI38ACPAaRgEAuknxIx3LOgVniVsEqxrwWfnj
vNW5Zc/6/ZCn8QL+LZ8A/iepdgiZ7bmYtUb+Zj537o46z/prXP290q6oo/2DQy2j
=G32M
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: udev-rules.eclass

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/07/12 03:17 AM, Michał Górny wrote:
> On Thu, 12 Jul 2012 13:01:21 +0800 Ben de Groot 
> wrote:
> 
>> On 12 July 2012 07:42, William Hubbs 
>> wrote:
>>> On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò
>>> wrote:
 Il 11/07/2012 21:11, William Hubbs ha scritto:
> I am about to release udev-186-r1, which will move
> everything currently in /lib/udev to /usr/lib/udev.
 
 Unless you're going to establish a symlink, please keep it
 under p.mask until everything is using some common code —
 otherwise things _will_ break.
>>> 
>>> Since multiple packages put things in /lib/udev, I'm not sure
>>> it is possible to establish a symlink from /lib/udev to
>>> /usr/lib/udev if that's what you mean; I'll look into it
>>> though.
>> 
>> Couldn't you, on udev upgrade, move everything in /lib/udev to 
>> /usr/lib/udev, and then make the symlink? Seems fairly simple to
>> me, but maybe I'm overlooking something?
> 
> You are overlooking conflicts introduced through moving files
> without updating vardb.
> 

There were no vdb issues when baselayout-1 was migrated to
baselayout-2, and it rewrote a whackload of stuff iirc...

Updating vdb shouldn't be an issue here, as long as pkg_postinst
doesn't crash mid-stream.  Is the vdb common between package managers
or does each one have a different solution?



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+1XUACgkQ2ugaI38ACPBKdgD/S3jlct63PVIKE8UmHW4jEanZ
T2/lgnF/cUzTSlsyrEQA/iQWSvOcowsgI/r2VUlJLFpltNVea/f8pm5wKq5F4cjk
=HA5O
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage Output / End User Experience

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/07/12 07:41 AM, Ben de Groot wrote:
> On 12 July 2012 17:52, Rich Freeman  wrote:
>> On Thu, Jul 12, 2012 at 12:17 AM, Ben de Groot
>>  wrote:
>>> Actually, there is another workable solution, and that is to
>>> set USE="-gstreamer -icu" for qt-webkit.
>>> 
>>> Currently we enable gstreamer by default in the ebuild (as it 
>>> is used for HTML5 audio/video, which is expected functionality 
>>> in qt-webkit based web browsers etc.), but we are considering 
>>> if we should perhaps not enable this by default.
>> 
>> As discussed on the bug, this will likely help some, but it
>> doesn't help anybody who uses KDE or Gnome.
> 
> As far as I know the gstreamer useflag is only enabled in the
> gnome profile, not the kde one currently.
> 

How much Gnome stuff needs qt-webkit? I figured that gnome stuffs
would be much more likely to require webkit-gtk , yes?

So a KDE user, with USE="-gstreamer" , is most likely not going to run
into this issue yes?  And Gnome users that have webkit-gtk[gstreamer]
packages don't run into this issue with chromium anyways, right?

(i know there's always overlap as anyone can install anything, but i'm
thinking of the general scope of impact here)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+1m0ACgkQ2ugaI38ACPBgQwD8DuLYiLZv4LUAuW1VACqRW/av
npl1U7DXm8jqPM4l0B4BALR4FY+yUD824X2+UwbB6hAjEZrYpLSIQz2zINbUiLYK
=vYhV
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: udev-rules.eclass

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/07/12 10:19 AM, Michał Górny wrote:
> On Thu, 12 Jul 2012 09:47:33 -0400 Ian Stakenvicius
>  wrote:
>> Updating vdb shouldn't be an issue here, as long as pkg_postinst 
>> doesn't crash mid-stream.  Is the vdb common between package
>> managers or does each one have a different solution?
> 
> Yes, it is common because for many years people keep noticing it
> is common and using that. In other words, for many there is a
> failing attempt to stop relying on its format.
> 

..i'm not following this -- so it's common (ie, portage, paludis, etc
all use it) because it's always been there?

Anyways, if all the package managers do use it, then there isn't any
reason at this juncture to not handle this via an update to vdb.  If
in the future different package managers use something different, then
we'd need to have individual vdb-update scripts for each (differing)
pms, but unless I misread you this is currently a non-issue..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+4GQACgkQ2ugaI38ACPDP8QD9HPv+l8vFW7cm/xA5ksKhUUyD
xzOtVY93XLL3ArhqlYkBAJxi98IIk5qWib6BK7VckhQLwJVmmHO+xtDPFuhP78rU
=YIIr
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: udev-rules.eclass

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12/07/12 10:20 AM, Michał Górny wrote:
> On Thu, 12 Jul 2012 09:43:57 -0400 Ian Stakenvicius
>  wrote:
> 
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> On 12/07/12 01:01 AM, Ben de Groot wrote:
>>> On 12 July 2012 07:42, William Hubbs 
>>> wrote:
>>>> On Wed, Jul 11, 2012 at 10:57:42PM +0200, Diego Elio Pettenò 
>>>> wrote:
>>>>> Il 11/07/2012 21:11, William Hubbs ha scritto:
>>>>>> I am about to release udev-186-r1, which will move
>>>>>> everything currently in /lib/udev to /usr/lib/udev.
>>>>> 
>>>>> Unless you're going to establish a symlink, please keep it 
>>>>> under p.mask until everything is using some common code — 
>>>>> otherwise things _will_ break.
>>>> 
>>>> Since multiple packages put things in /lib/udev, I'm not sure
>>>> it is possible to establish a symlink from /lib/udev to 
>>>> /usr/lib/udev if that's what you mean; I'll look into it
>>>> though.
>>> 
>>> Couldn't you, on udev upgrade, move everything in /lib/udev to
>>>  /usr/lib/udev, and then make the symlink? Seems fairly simple
>>> to me, but maybe I'm overlooking something?
>>> 
>> 
>> A symlink isn't a good idea as, iirc, the new udev still -reads-
>> from both /usr/lib/udev and /lib/udev ..
> 
> Does it? I wasn't able to reproduce and wanted to start convincing
> Kay to let it do that...
> 
> 

..i was going by your statement, i guess i misread you (thought you
said that it did, not that it should)..  Sorry!

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAk/+4JAACgkQ2ugaI38ACPCJSgEAp8xI9d8dDO5G2l1lC/pYGT+c
P1rx1XWffLntT12AG94A/j2321qa6OeC+I8AXmK2N+CtWt1FMSzP250H7yMkB0CH
=MERT
-END PGP SIGNATURE-

Re: [gentoo-dev] multiple package moves into one

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/07/12 06:16 PM, Zac Medico wrote:
> On 07/15/2012 03:08 PM, Doug Goldstein wrote:
>> Is it valid to do something like:
>> 
>> move media-plugins/mytharchive media-plugins/mythplugins move
>> media-plugins/mythbrowser media-plugins/mythplugins move
>> media-plugins/mythgallery media-plugins/mythplugins move
>> media-plugins/mythgame media-plugins/mythplugins move
>> media-plugins/mythmovies media-plugins/mythplugins move
>> media-plugins/mythnews media-plugins/mythplugins move
>> media-plugins/mythweather media-plugins/mythplugins
> 
> No, that's not really how it's intended to be used. You'll probably
> have to put blockers in media-plugins/mythplugins to block all the
> old packages that install the same files.

Theoretically (i've done a quick test on this and it seems true) a
single-"!" blocker is enough that one package will on upgrade replace
all these others without user intervention being required (assuming
these packages aren't in @world, of course), and it won't cause file
collisions.

Unrelatedly curious, why the package merge?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAEG+cACgkQ2ugaI38ACPCz0QEAiuBnHl3Va2cHzUnUPT4eHFei
kJXPBEnrsMq7jLX2H8IA/20zKcaGh+SsyTzh0jMauiTeh7zF1+PwLpcgJSpH0YS+
=BLip
-END PGP SIGNATURE-

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

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/07/12 09:00 PM, Maxim Kammerer wrote:
> On Mon, Jul 16, 2012 at 3:30 AM, Duncan <1i5t5.dun...@cox.net>
> wrote:
>> Thinking in that direction does stimulate yet another idea, tho.
>> What about a squashfs root?  AFAIK squashfs is read-only at use
>> time, thus enforcing actually mounting something else to write
>> anything, eliminating many of the down sides of sticking with the
>> initial ramfs root, but it would allow the same flexibility in
>> terms of sticking whatever into it at create-time, while only
>> taking the memory necessary for what's actually stuck in it at
>> create-time.
> 
> It is possible, see: 
> https://github.com/mkdesu/liberte/blob/master/src/root/initrd/init 
> https://github.com/mkdesu/liberte/blob/master/src/etc/fstab
> 
> The setup above is somewhat different from what you have in mind 
> (SquashFS image is located on disk, and contains the complete live 
> filesystem, not just a skeleton), so mounting read-writable
> branches can be deferred to the regular post-initramfs services
> (such as localmount) — on the other hand, maybe you want to do the
> same (mount branches read-only in initramfs, and remount them
> read-write in an init.d service).
> 

...if going this route, why not simply not bother to pivot_root out of
the initramfs at all?  or pivot_root but only into a directory
structure still sitting in the initramfs?  As long as all non-root
bits are in separate storage, you can mount 'em all in the appropriate
place...


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAEHNAACgkQ2ugaI38ACPCbBgD+MCInpuQXjir37zFTn3ebJe30
dEWqqxihYox1+XrR7JYA/26jjkglGXZzxP0Kq17xuyoDBD8qnymAsziieDsMCMvN
=/C5P
-END PGP SIGNATURE-

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

[Ian Stakenvicius]

On 2012-07-17, at 7:07 PM, Olivier Crête  wrote:

> I'm sure most people can't
> even explain the difference between them.
> 

/sbin is for bins that only root should be able to run.  easy. :)

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

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/07/12 03:47 PM, Michael Mol wrote:
> On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés
>  wrote:
>> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol 
>> wrote:
>> 
>> The real benefit is that it allows you to mount any partition, if
>> the tools to mount it live in the same partition.
> 
> Certainly that's a benefit.
> 

...don't you mean, "if the tools to mount it live in the initramfs" ??

if the partition isn't mounted I don't see how the initramfs will
allow you to mount it using its own tools...
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHE3QACgkQ2ugaI38ACPDQBwD9HOn8skOvLhpPYuqCnH1Nuh7e
zefAwVaHDQQsz9vKVeYA/1utNcF2ROdeiHlMfvte4TGH42lo+NOjdM1Ml0wpU9b/
=5AMo
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/07/12 03:49 PM, Peter Stuge wrote:
> William Hubbs wrote:
>> /etc/init.d/foo stop start
>> 
>> would no longer work the way you might expect because there would
>> be no way to tell whether start is a command or an argument to
>> stop.
>> 
>> What are your thoughts about this change?
> 
> /etc/init.d/foo stop start
> 
> along with all other commands can work like before.
> 
> /etc/init.d/foo stop -- start
> 
> can pass start as an argument to the stop command.
> 
> 
> //Peter


I posted a response about this to the bug, but I don't see why, given
that all 'commands' are predefined anyways, the commandline couldn't
be parsed and split between commands..


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHFCkACgkQ2ugaI38ACPANyAEAnF7ngFvy/lcHPo0A4vEyN0zS
5QFTRmOiFG+GS8cRkyEBAL3ABkRD9M44sVHGs52ioctce+tsBSfLU9bawmBQuuJf
=dzvV
-END PGP SIGNATURE-

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

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/07/12 03:55 PM, Michael Mol wrote:
> On Wed, Jul 18, 2012 at 3:50 PM, Ian Stakenvicius 
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> On 18/07/12 03:47 PM, Michael Mol wrote:
>>> On Wed, Jul 18, 2012 at 3:25 PM, Canek Peláez Valdés 
>>>  wrote:
>>>> On Wed, Jul 18, 2012 at 2:18 PM, Michael Mol
>>>>  wrote:
>>>> 
>>>> The real benefit is that it allows you to mount any
>>>> partition, if the tools to mount it live in the same
>>>> partition.
>>> 
>>> Certainly that's a benefit.
>>> 
>> 
>> ...don't you mean, "if the tools to mount it live in the
>> initramfs" ??
>> 
>> if the partition isn't mounted I don't see how the initramfs
>> will allow you to mount it using its own tools...
> 
> I think you're replying to Canek. I took it to mean that having an 
> initramfs allows you to mount the very filesystems where you would 
> _traditionally_ expect to find the tools. E.g., being able to mount
> an encrypted /.
> 

Yeah i was..  i just wanted to re-emphasize the point that the tools
to mount it need to be on the initramfs (in whatever version or form
they were when the initramfs was built), and really have nothing to do
with them (including their current and possibly more up-to-date
version) living on said partition..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHFZUACgkQ2ugaI38ACPAiMAD/eWHxvaZPu1ikYN9ZeClsEWnB
pBDgfVPC0UTDeoUOVFcA+gKCmqa+lhs0x+arJhF7AZfWEbYb+jMK+bVxUVgfElR4
=O0O4
-END PGP SIGNATURE-

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

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/07/12 04:05 PM, Alec Warner wrote:
> [...] However lets say I have coreutils in / and coreutils in my
> initramfs. I upgrade coreutils from v1 to v2. Are you saying that
> you are too afraid to update coreutils in / and then also update it
> in the initramfs (probably by running $TOOL to copy coreutils from
> / to initramfs-root.)
> 
> I'm not suggesting that we necessarily do this automatically, just 
> that people claim 'the tools do not exist to do this now' when in
> fact it seems fairly straightforward to do.
> 
> I mean presumably you used $TOOL to build the initramfs once, so 
> running $TOOL again to generate a new initramfs probably should
> not screw you, provided you have control over the configuration of
> $TOOL.


IIRC, and unless this has changed recently (ie within the last year or
two), a genkernel-generated initramfs is built on specific versions of
all the tools that genkernel itself ensures is downloaded, ie, *NOT*
the same versions as are installed in your / , and often are actually
older.

You can, of course, change this via /etc/genkernel.conf for each tool.

..so in that particular case, one would want their initramfs
regenerated when genkernel gets upgraded (but after
/etc/genkernel.conf is etc-update'd)


If I remember my hearsay correctly, dracut does build the initramfs
from tools on / , though...?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHGFAACgkQ2ugaI38ACPCjlAD/Qin9JKK6SFAr/5G2vjgqJmau
BATFNwP/nbgtIb5i0rgA/jlEmZFBK9n14GOYzQxi3BJewGhRvi62WAHsX7EMQzDL
=HLZG
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: openrc init scripts taking command line arguments

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/07/12 04:09 PM, William Hubbs wrote:
> 
> The other approach, which is on the bug, still has this issue,
> e.g.
> 
> /etc/init.d/foo command1 arg1 arg2 command2 arg3 arg4 command3
> arg5
> 
> gets pretty ugly pretty quick. which arguments go with which
> commands is subject to interpretation.

..i don't see how...?  anything to the right of [command] but before
{[other-command],$END} is an argument to [command] ...

ie, the above would roll out to:

/etc/init.d/foo command1 arg1 arg2 && \
/etc/init.d/foo command2 arg3 arg4 && \
/etc/init.d/foo command3 arg5

(assuming subsequent commands do not execute if the previous one fails
now, which tbh I have no idea about)

It's not the most pretty syntax ever, but given i doubt it will be
humans running such a commandline I don't see the issue with this..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAHGZUACgkQ2ugaI38ACPCXNAD8DR8qHFOQnGCt2W+sOXYJDsXu
H6pnnFt09ssbuKjKHZwA/2pZxnGnXJTWGVdPySoIsJtr8Pe6Za9yeL4yQ0WHPocr
=G3H9
-END PGP SIGNATURE-

Re: [gentoo-dev] enewuser: home beloning $user:root inset of $user:$group

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/07/12 06:18 AM, Maxim Kammerer wrote:
> On Fri, Jul 20, 2012 at 11:32 AM, Michael Weber 
> wrote:
>> is it intentional behavior, that home directories created by
>> enewuser belong to $user:root (or pwd group) instead of
>> $user:$group ?
> 
> This seems like the result of a hasty bugfix to me: 
> https://bugs.gentoo.org/23627 
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.36&r2=1.37
>
>  Wrong group ownership shouldn't matter much, since ebuilds should 
> probably explicitly set home directory ownership / permissions
> with fowners / fperms anyway (in src_install()). However, that
> doesn't work due to: https://bugs.gentoo.org/396153
> 
> Having a switch for enewuser to skip creating home directory would 
> solve the issue for majority of usecases, but a request I opened
> was resolved as a duplicate of the bug above (which I don't expect
> to be resolved anytime soon): https://bugs.gentoo.org/395961
> 

enewuser won't create a home directory if you don't specify one (ie
it's set to /dev/null or it's unset).  Also, you can use 'esethome' to
set the home directory to an existing directory.  With both of these
options I don't think that a --do-not-create-homedir option is necessary.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAJd+YACgkQ2ugaI38ACPDmLgD8C/CifrMost6b5cYVZn3R+FnU
K3Qf6Tp85S/gSPT7fC0A/ikEDaKGQxqainhzWRfl0fyyb6MSRZphzcz+uwb+Y/1t
=yFDr
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: l10n.eclass

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/07/12 01:54 PM, Ciaran McCreesh wrote:
> On Fri, 20 Jul 2012 13:43:15 -0400 Alexandre Rostovtsev
>  wrote:
>>> If you dep upon foo[linguas_en(+)] and linguas_en isn't in
>>> IUSE, what happens?
>> 
>> Fatal error. If a package installs its translations implicitly
>> via gettext's rules depending on the value of LINGUAS at
>> configure time, then obviously other packages must rely on that
>> package having installed any particular translation.
> 
> Uh, the entire point of the (+) is that it's *not* a fatal error if
> you have a default.
> 

If this doesn't work (assuming foo provides whatever this package
needs it to have for linguas_en), then the dep is wrong in the first
place and either (+) shouldn't be set or the use-dep on foo shouldn't
exist to begin with.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAJq/4ACgkQ2ugaI38ACPDIrgEAlPMn/3pSM/GK3BbCozQgGpxc
9aSnmtIXlOsr7HZ7QcUA/1dbtqqt6B/ClgriFHvHcVpZEiz5QiQh6RJ2t4Mr5jgk
=ai7O
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: l10n.eclass

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/07/12 03:13 PM, Ciaran McCreesh wrote:
> On Fri, 20 Jul 2012 15:05:35 -0400 Ian Stakenvicius
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20/07/12 01:54
>> PM, Ciaran McCreesh wrote:
>>> On Fri, 20 Jul 2012 13:43:15 -0400 Alexandre Rostovtsev 
>>>  wrote:
>>>>> If you dep upon foo[linguas_en(+)] and linguas_en isn't in 
>>>>> IUSE, what happens?
>>>> 
>>>> Fatal error. If a package installs its translations
>>>> implicitly via gettext's rules depending on the value of
>>>> LINGUAS at configure time, then obviously other packages must
>>>> rely on that package having installed any particular
>>>> translation.
>>> 
>>> Uh, the entire point of the (+) is that it's *not* a fatal
>>> error if you have a default.
> 
>> If this doesn't work (assuming foo provides whatever this
>> package needs it to have for linguas_en), then the dep is wrong
>> in the first place and either (+) shouldn't be set or the use-dep
>> on foo shouldn't exist to begin with.
> 
> ...but (+) exists precisely because developers wanted a way of not 
> having fatal errors when using use dependencies. Non-defaulted use 
> dependencies are supposed to give errors if there's no match in 
> IUSE_EFFECTIVE, but unfortunately Portage chose not to make it as 
> strict as the Council-approved wording required.
> 

non-fatal doesn't work in this case, because in the situation you
described, the dep 'foo' -must- have linguas_en existing and enabled
to work.

IF foo doesn't -need- to have linguas_en existing and enabled to work,
ie, if linguas_en doesn't exist but foo installed the relevant bits
anyways, then foo[linguas_en(+)] is valid and works fine.

Otherwise, the dep specified is wrong and it SHOULD be a fatal error.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAJuqAACgkQ2ugaI38ACPApyQD/dtMj1l0KeJByIXXIhS+Y3Xst
pj2/eoQ7q1ze2vhfPgQBALA+UatwFysIXRuFCiXrVt4vK0OlMNa58GIRpsonzGMz
=cPuz
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: l10n.eclass

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/07/12 03:48 PM, Alexandre Rostovtsev wrote:
> On Fri, 2012-07-20 at 20:17 +0100, Ciaran McCreesh wrote:
>> On Fri, 20 Jul 2012 15:15:31 -0400 Alexandre Rostovtsev
>>  wrote:
 That's sensitive to old versions ebuilds being removed from
 the tree, so it's utterly unworkable.
>>> 
>>> I do not see why you think it's unworkable. Ebuilds already
>>> have dependencies that can be broken by removing an old
>>> version; if wombat depends on foo[bar], and you removed the
>>> only version of foo that had bar in IUSE, you broke wombat.
>>> Adding special LINGUAS handling would not change the fact that
>>> before deleting an ebuild, you need to verify that you did not
>>> render other ebuilds' dependencies unsatisfiable.
>> 
>> That's not how undefaulted use dependencies work. If wombat
>> depends upon foo[bar], it is an error if there is *any* version
>> of foo *ever* that doesn't have bar in IUSE_EFFECTIVE.
> 
> Very odd; AFAICT neither portage nor repoman treats that situation
> as an error. I am guessing that this is another case where paludis
> does things differently?

After discussion in #-dev I would tend to agree.  For instance, a dep
on app-cat/foo[flag(-)] resolves identically in portage to
app-cat/foo[flag]

(this means btw that the '(-)' only has meaning when using a negated
use dep, ie:  app-cat/foo[-flag(-)] does something useful, otherwise
it doesnt)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAJu3YACgkQ2ugaI38ACPA1ngD9FVbdMb+2jw/+yj/0NIQ28mdz
YYmXytaoefN0NaBM4bAA/jFmkgkcvrqbtQARbHUaqfFBgJHLVlM1cjk35KE+gKMS
=KZJc
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23/07/12 09:58 PM, Jorge Manuel B. S. Vicetto wrote:
> On 24-07-2012 01:33, Rich Freeman wrote:
>> On Mon, Jul 23, 2012 at 8:07 PM, Jorge Manuel B. S. Vicetto 
>>  wrote:
>>> 
>>> I propose to commit this news item in 2 or 3 days. Does anyone 
>>> have any comments about it?
> 
>> What action if any do you want Gentoo users to take.  If I read 
>> that news item the first question I'd have is where SHOULD I
>> keep those files?  Should I leave them alone?  Should I move
>> them?  Will anything bad happen either way?
> 
>> If the answer is that we're changing the defaults but plan to 
>> support the old way for a very long time, then spell that out. 
>> Otherwise you'll get a million people asking about it.
> 
> This is just a heads-up for Gentoo users that got used to find 
> make.conf and make.profile under /etc in stages, that these files
> will stop being there and will instead be under /etc/portage. So we
> are changing the defaults.


Given that this just affects new installs, is a news item (via
portage) a particularly good way to inform everyone?  I was wondering
if it'd make more sense to notify on the website and *definitely*
change the Handbook...

..and maybe include an '/etc/make.conf.moved' in the stage files for
the next 6 months which says the above?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAOoWkACgkQ2ugaI38ACPDT2gEAv2eTzurXYEjYFaUWE5bRhPrS
VDhg0hnxiYeCQl9XYPEBALClflgTBOAzOJIKItcOLgItZqrFxm1lGetvSfBUoT7P
=1WOb
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 24/07/12 07:39 AM, Fabian Groffen wrote:

> From a different angle, perhaps stage3s shouldn't include a
> default /etc/make.conf at all.  Would solve this issue nicely, and
> doesn't require a news item at all, IMO.
> 

Would that work?  We still need the CHOST set, don't we?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAOpDMACgkQ2ugaI38ACPC2IgEAkajZSviiK6MnrwUPbchWA9y/
S2o9KgY/B/ehN/bV4a4A/1E+qJXTF01LFuLV5h5ch8VB843rXBmzOqTIUosK2PmH
=KyGG
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 24/07/12 02:52 PM, Rick "Zero_Chaos" Farina wrote:
> On 07/24/2012 09:33 AM, Fabian Groffen wrote:
>> On 24-07-2012 09:24:03 -0400, Rich Freeman wrote:
>>> I guess this is a matter of opinion, but on Gentoo I don't
>>> think we're really at much risk of driving people away by
>>> OVER-communicating.  Our users are used to things changing and
>>> a certain level of fix-it-yourself, but if we know something is
>>> going to cause no end of questions it only makes sense to throw
>>> the users a bone once in a while.
> 
>> The way in which news items aggressively request your attention,
>> makes them something that should only be used if it's obvious
>> it's important for the user (e.g. postfix thing for postfix
>> users). This particular change seems more something for
>> -announce, note in the handbook, and something like the
>> suggestion of a file giving a nice hint.
> 
>> My impression is that the message is absolutely useless to the
>> majority of users on their *already installed* system, so don't
>> make everyone have to see the news item notice a couple of times
>> and run `eselect news read` just for this.
> 
> 
> While I completely understand where Fabian is coming from on all
> this I respectfully disagree.  Long term gentoo users do NOT read
> the handbook, ever.  I still install new systems with odd hacks
> that I picked up when gentoo was versioned 1.x and it pleases me, I
> don't care if those steps are not in the docs anymore or
> discouraged or whatever.  I've not even glanced at the handbook for
> years, yet I've installed gentoo on dozens of systems since the
> last time I did.

Right, but would a news item now (regarding Catalyst) for something
you do next month be particularily helpful, compared to a
'make.conf.moved' reminder file in /etc ?  Or maybe a make.conf
synlink to profiles/make.conf ?  Or something else within the stage
itself that makes it obvious that it's changed?

The main issue I see with this is that the news item isn't relevant to
what people have emerged or will emerge (except for the small
percentage that use catalyst, of course); and I expect that this will
cause more confusion and grief to the user base than help (even if the
news items says in big capital letters that nothing needs to change on
their current install)


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAPBJoACgkQ2ugaI38ACPBsmQD/brYvJa9PIi12mdfoUBmGkgD/
NCNN9IEiaTLm22MNl1AA/1HJp0Y+rCYdwLK31v20DYBd8V02erYxMtkUHt5P6elN
=D+wg
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: news item: changes to stages (make.conf and make.profile)

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 24/07/12 05:13 PM, Brian Harring wrote:
> On Tue, Jul 24, 2012 at 04:32:00PM -0400, Michael Mol wrote:
>> 
>> I've often seen cases like these handled by keeping a referenced
>> file where it's traditionally expected to be found, but leaving a
>> comment in that file explaining that the content of that file had
>> been moved to a new location, and the old location is
>> deprecated.
>> 
>> Would that work for a circumstance like this?
> 
> Not really, no- it would mean the PM would have to parse/merge both
>  locations, rather than just looking for the file in one of two
> spots.
> 
> ~brian
> 

...if the file was empty except for comments saying where the new
location is, there would be nothing to parse.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAP99QACgkQ2ugaI38ACPAMYgD9GVy2oqiSjbPO0+doxmM0bpyB
vR/sX4zgzcYCdXBW/5oBAJddUSALwz3aoWiL6T9SsADTDVrN7VFNyyRd9sXc6WAf
=MmwG
-END PGP SIGNATURE-

Re: [gentoo-dev] news item: changes to stages (make.conf and make.profile)

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 24/07/12 08:55 PM, Walter Dnes wrote:
> On Tue, Jul 24, 2012 at 11:42:31AM +0200, Ralph Sennhauser wrote
> 
>> man 5 portage about files in /etc/portage
>> 
>> make.conf The global custom settings for Portage. See
>> make.conf(5). If present, this file will over??? ride settings
>> from /etc/make.conf.
>> 
>> 
>>> 3. This news item is really useful, since the change has a
>>> potential to break automated builds.
>> 
>> We aren't discussing dropping support for the old locations here
>> but about makeing the new location the default.
> 
> This has the potential to cause problems for people who do things
> "the old way", and find that their settings in /etc/make.conf are
> not being applied.  Instead of a news item, maybe we should be
> looking at warnings and/or errors in "emerge"...
> 
> 1) If there is a /etc/make.conf, but no /etc/portage/make.conf,
> emerge should generate an ewarn message.  Is emerge smart enough to
> generate only one ewarn even though it's emerging umpteen
> packages?

I'm not sure that this one is particularly necessary, as the default
location is not changing according to the package managers.  It's only
changing according to the stage files that ppl use to install.

Once the package managers roll out -expecting- that make.conf should
be in /etc/portage/make.conf rather than /etc/make.conf, then yes this
should absolutely occur.  Right now (and reportedly for the forseeable
future) that is not the case.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAP+ecACgkQ2ugaI38ACPBMQgD/bXuNBSa2s5R7/T1Fb2uZ6cZW
+AmYjBjKZDiPMXYYL5sBAJf0mAxgYUETs+KKKk8QS4cTrxK3VvitW1k7yKCEE6zl
=YbES
-END PGP SIGNATURE-

Re: [gentoo-dev] Portage FEATURE suggestion - limited-visibility builds

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 31/07/12 10:55 AM, Michael Mol wrote:
> On Tue, Jul 31, 2012 at 10:48 AM, "Paweł Hajdan, Jr." 
>  wrote:
>> On 7/26/12 8:26 PM, Rich Freeman wrote:
>>> I've been messing around with namespaces and some of what
>>> systemd has been doing with them, and I have an idea for a
>>> portage feature.
>>> 
>>> But before doing a brain dump of ideas, how useful would it be
>>> to have a FEATURE for portage to do a limited-visibility build?
>>> That is, the build would be run in an environment where the
>>> root filesystem appears to contain everything in a DEPEND
>>> (including @system currently) and nothing else?
>> 
>> I was thinking about something similar too. In my opinion it's a
>> great feature. If/when there are any bugs to get this
>> implemented, please let me know.
>> 
>> A possible alternative implementation would be to make the
>> sandbox deny access to anything outside DEPEND. One totally crazy
>> idea to make that fast are extended attributes (portage would
>> record which package a file belongs to when merging the file).
>> Another possible solution is using a cache.
> 
> We already have the ability to run commands like 'equery b
> $somefile' to map a file back to a package, so the data for a
> filesystem helper should already be available in whatever database
> equery is using.
> 

Although that is true, it would be -WAY- too slow to generate said
list via equery/q* helpers; I think that's where the
extended-attributes and/or cache idea comes into play.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAX8jUACgkQ2ugaI38ACPAm8wEAlfvF3KgQi5ZsH7FbCfALxOn0
hF9Y+vhH8I5Ki0NUbAYA/0uDWlPlx2RIpK8Z7B8E/n//Fuii8ZFppVC440g3djjT
=/xMA
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Global Systemd USE Flag

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/08/12 02:57 AM, Duncan wrote:
> Jason A. Donenfeld posted on Thu, 09 Aug 2012 06:33:02 +0200 as
> excerpted:
> 
> Consider... five years ago was 2007. Android hadn't been released
> yet at this point in 2007 (November, according to the LWN 2007
> timeline I'm looking at [1]).  Nokia releases the N800.  KDE4 was
> yet to come out (January, 2008) altho the PR machine had been in
> full swing for awhile. Gnome3 was still a ways out.  GPLv3 is
> released and Bruce Perens among others predicts Linus and Linux
> will switch after kicking and screaming for a couple years.  Kernel
> 2.6.20-2.6.23.  Con Colivas quits the kernel, but eventually
> releases the brainfuck scheduler without attempting a mainline
> merge.  The MS/Novell agreement and controversy.  AMD announces 
> that it is opening up ATI graphics documentation.  SCO files for
> chapter 11 (which just now it's trying to convert to chapter 7)
> bankruptcy.  One- laptop-per-child XO goes into mass production.
> SAMBA gets access to the MS protocol docs...
> 

Yep, those were the days; it's been all down hill from there.. ;P
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlAjzDgACgkQ2ugaI38ACPAGDAD9G1aa7QecEzfBKG3nHsRj17gq
yOVJjTVcSCiNGneJM4kA/ifMmQBjvQuq/HUufEiOwfxZzW2qqqYRxD71g7UwFgMi
=0ecq
-END PGP SIGNATURE-

Re: [gentoo-dev] CWD-relative ROOT support in portage: misfeature?

[Ian Stakenvicius]

On 2012-08-17, at 11:00 PM, "Gregory M. Turner"  wrote:

> It has come to my attention that gentoo supports "relative" ROOT, which is to 
> say that, by design, portage will act as though (in bash terms):
> 
>  ROOT
> 
> equals
> 
>  "${PWD}/${ROOT}"
> 
> when (again in bash terms):
> 
>  [[ $ROOT != /* ]]
> 
> at the moment execution crosses the boundary between a non-portage program 
> and a portage program.  For example, I ran the following from a bash-prompt 
> with PWD=/tmp in a portage-2.2 ~amd64 environment:
> 
>  greg@fedora64vmw /tmp $ mkdir foo
>  greg@fedora64vmw /tmp $ ROOT=foo portageq envvar ROOT
>  /tmp/foo/
> 
> Question: do we really want this behavior?
> 
> I have reason to believe that almost nobody uses this feature (namely, 
> gcc-config and binutils-config are both broken under it for ages and nobody 
> filed a bug or fixed it: see bugzilla #431104).
> 
> Does /anybody/ use this feature?  If not, I'd suggest that the portage team 
> might ask itself whether the benefits of continuing to maintain it are 
> greater than the hassle and potential for error it facilitates.
> 
> Just my 2c,
> 
> -gmt


Sorry for the HTML response... am on the road.

I don't use the feature but I would fully expect said behavior. ie, going with 
the example above I would expect that I'd need   the / in front for the path to 
not be relative.






> 

Re: [gentoo-dev] rfc: OpenRC network provides revisited

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 24/08/12 03:58 PM, William Hubbs wrote:
> On Fri, Aug 24, 2012 at 01:50:14PM -0400, Alexandre Rostovtsev
> wrote:
>> On Fri, 2012-08-24 at 12:10 -0500, William Hubbs wrote:
>>> The second question this bug brings up is whether services
>>> should "need" or "use" net. Remember that the "need" dependency
>>> will try to run the needed service even if it is in init.d but
>>> not in a runlevel.
>> 
>> Presumably that depends on the service. If a daemon can deal
>> with network interfaces going up and down, then "use net" of
>> course makes more sense.
> 
> This user is running with pre-configured interfaces (root is nfs 
> mounted). The network interface configuration should not be touched
> by openrc.
> 
> If you look at his logs, one issue is that the "network" service
> is starting even though it isn't in a runlevel. I have made changes
> in git master so this will not be installed if you do not use the
> "newnet" use flag.
> 
> When network interfaces are pre-configured, our network scripts 
> shouldn't run at all, but they can be forced to run if other
> services have "need net" in their dependencies.
> 
> So my question is, should we change our services to "use net"
> instead of "need net"?
> 

No, we shouldn't.  "need net" is important and "use net" doesn't
suffice in many cases.

However, for a NFS-root system there's a way to either #1 make the
"net" service do nothing (or alternatively overwrite the previously
configured net with the exact same info -- but iirc the do-nothing
option works), and alternatively #2 make it so that "net" is provided
right away.

One thing, though, that i'm not certain of is How the different
runlevels interact -- ie if "net" is started (considered up) at
"boot", it should be (and i assume is, but could be wrong) "up" during
"default" or whatever other runlevel there is, right?  I know it was
with baselayout-1 (which i'm actually still running on my NFS-root
cluster).



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA4J6kACgkQ2ugaI38ACPAoigEAgi/Idi+tk/lmg597aVqJ+dKD
978sMNwUFnLD5GjTjM4A/1+xa5KmmF9b7SgOw0LFIdcBGByHCq8i3nd3HpgnGYhX
=FvL9
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: OpenRC network provides revisited

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 24/08/12 07:48 PM, William Hubbs wrote:
> On Sat, Aug 25, 2012 at 07:40:43AM +0900, hero...@gentoo.org
> wrote:
>> Besides, IMHO, we should avoid changing OpenRC's default
>> dependency too often. The solution for one user can be received
>> as a regression to others.
>> 
>> People file bugs saying "it worked for OpenRC-0.9 but not 0.10".
>> For devs, we know we just changed default value of something
>> perfectly configurable. But for that user, it is quite
>> discouraging to feel "something in OpenRC is still unstable".
> 
> Another thing to consider is, do the services we say "need net"
> really _NEED_ net?
> 
> If a service is a listener like sshd that isn't bound to a
> specific address by default and can deal with interfaces going up
> and down, I would guess that it doesn't. I am thinking that we can
> set up the depends for sshd as follows:
> 
> use net after net
> 
> That would make sure a net provider runs before sshd if one is in
> the runlevel, but allow sshd to start if one is not as well.
> 
> This would have to be tested on a case-by-case basis.
> 
> About changing default values, I think that if we have a good
> reason to change them, we should inform users and change them.
> 
> I think the advantage here is that it makes openrc run out of the
> box in more situations.
> 
> William
> 

I think this may again come down to the meaning of "net" -- in the
case where rc_depend_strict="no" then "net" just means that the
network interface infrastructure is up and running (ie net.lo); this
should be true and imo is required for something like ssh.  When "net"
goes beyond that and includes other interfaces (ie,
rc_depend_strict="yes") then the 'need net' might be a bit strict; on
the other hand if a user has things set up that way then it may very
well be for a reason (for instance, I tend to prefer that sshd is
started after my hotplugged iface is up and likewise goes down when
that iface disappears.  I don't see that happening with a "use net"
case when compared against a "need net".

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA4KMcACgkQ2ugaI38ACPCdxQD8DWD+LOJq1V5722MUkC2tvp0i
skFHngOAJNGFyW4q3gMBAJnXZ2TQE77MUjcbbWGbfXr71EBLVBcoy9vzcxHOK/Oj
=yO7o
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: OpenRC network provides revisited

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 25/08/12 11:53 AM, William Hubbs wrote:
> On Sat, Aug 25, 2012 at 03:19:24PM +0900, hero...@gentoo.org
> wrote:
>> If we set rc_provide="net" in rc.conf, the services that need net
>> can be tricked as we intended to.

This makes more sense to me as it's in the direction that seems more
logical -- make "net" be provided instantly, rather than forcibly
changing the dependency on each (or all) "net"-using service(s).


> 
> Setting rc_provide, rc_need, rc_use, etc in rc.conf is definitely
> not recommended. Remember that this affects all services on your
> system.
> 
> when you set rc_provide="net" in rc.conf, you are saying that every
> service on your system provides net.
> 
> William

rc_modules_provide="net" ?  rc_localmount_provide="net" ?  There are a
number of required services that could be used to assign "net" to..

(And i would think that this specification should occur in rc.conf
rather than a file in /etc/conf.d , simply because it's something (in
the case of NFS root, etc) that's akin to rc_depend_strict or rc_sys
in terms of its impact on the whole openrc configuration)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA5HkMACgkQ2ugaI38ACPDR5QEAkthP24HOhTZf+NwhgmjS
XGZFFAuYj6iG8j7CU2kBALwvt2dxmHLMNO96rMAx7w6uKw9Ggad4tKssNQu+ePq/
=HrBr
-END PGP SIGNATURE-

Re: [gentoo-dev] rfc: OpenRC network provides revisited

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 25/08/12 04:16 PM, William Hubbs wrote:
> 
> The bottom line here is: I don't think all of the services we have
> set up to "need net" in their default configuration should be set
> up that way. It would make OpenRC work out of the box for many
> more configurations. [ Snip! ] This is really more an idiology
> thing I guess, but I think if you are tweeking a specific service
> it should be done in the /etc/conf.d/service file. To follow the
> example above, to make a particular service provide net, it is
> better imo to put rc_provide="net" in /etc/conf.d/service.
> 
> If you want to change this in rc.conf, use the
> rc_[service]_[depend] variable instead of rc_[depend]. RC_[depend]
> in rc.conf will apply that dependency to *all* services on your
> system, including any new ones that get installed later, so be
> absolutely sure you know what you are doing if you use this.

I concurr with your analysis, just not your conclusions.  :)  I very
much like (and depend on, in certain cases) the way depends on the
'net' service are set now, and would prefer they stay that way.
Relatedly, since the only cases I'm aware of where it is desired for
this to change are cases such as NFS-roots or vm's/containers where
the 'net' service is up before openrc begins, to me this is a
system-wide effect and not something that should be tweaked
per-service.  To change the default and then require per-service
tweaks to get old behaviour back is imo not a particularly good idea.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA7axoACgkQ2ugaI38ACPDAfAD/YpiHpAp2tMDhqBm5V19KTmwU
BgavBXMATRcJeWETmV4A/1egNPg7i1pRpzWTLa7//Ano108rRQ9Ff9xZN01EBh1E
=N0n2
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28/08/12 10:35 AM, Mike Gilbert wrote:
> On Tue, Aug 28, 2012 at 4:06 AM, Michał Górny 
> wrote:
>> On Tue, 28 Aug 2012 06:26:02 +0200 Arfrever Frehtes Taifersar
>> Arahesis  wrote:
>> 
>>> 2012-08-28 00:19:28 Michał Górny napisał(a):
 +case ${EAPI:-0} in +   0|1|2|3|4) ;; +   *) die
 "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
 +esac
>>> 
>>> Please accept all EAPIs.
>> 
>> These are EAPIs which are allowed throughout the tree, sorry.
>> Feel free to ping Council about adding non-standard EAPIs to
>> eclasses.
>> 
> 
> Is the eclass likely to be incompatible with future EAPIs? If not,
> I think it is reasonable to remove this check.
> 

It's quite standard to have the above check in place; and since there
is no guarantee that new EAPIs *won't* break something, I think it
would be a good idea to leave this as-is.

Yes this will add a touch more work when it comes to bumping eclasses
to accept EAPI=5 or newer, but forcing a dev to check the eclass's
compatibility when a new EAPI rolls out is a good thing imo.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA82ToACgkQ2ugaI38ACPA4LQEAhoW6FtSwDqTdsV84XOjsibOp
TdM1B3sE8Gpp8WnfFhgA/3MvQy9oq+y/0U1cqMByiSAH4wN/12f0yuvGiWYD5pXf
=GQ4U
-END PGP SIGNATURE-

Re: [gentoo-dev] [PATCH] boost-utils.eclass -- for building against newest boost.

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28/08/12 10:43 AM, Michał Górny wrote:
> On Tue, 28 Aug 2012 10:10:01 +0200 Tiziano Müller
>  wrote:
> 
>> Am Dienstag, den 28.08.2012, 10:06 +0200 schrieb Michał Górny:
>>> On Tue, 28 Aug 2012 06:26:02 +0200 Arfrever Frehtes Taifersar
>>> Arahesis  wrote:
>>> 
 2012-08-28 00:19:28 Michał Górny napisał(a):
> --- /dev/null +++ b/gx86/eclass/boost-utils.eclass @@ -0,0
> +1,43 @@ +# Copyright 1999-2012 Gentoo Foundation +#
> Distributed under the terms of the GNU General Public 
> License v2 +# $Header: $ + +if [[ ! ${_BOOST_ECLASS} ]];
> then + +# @ECLASS: boost-utils.eclass +# @MAINTAINER: +#
> mgo...@gentoo.org
 
 It is better to copy list of maintainers from 
 gentoo-x86/dev-libs/boost/metadata.xml.
 
> +# @BLURB: helper functions for packages using Boost C++
> library +# @DESCRIPTION: +# Helper functions to be used
> when building packages using the Boost C++ +# library
> collection. + +case ${EAPI:-0} in +   0|1|2|3|4) ;; + *) die
> "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
> +esac
 
 Please accept all EAPIs.
>>> 
>>> These are EAPIs which are allowed throughout the tree, sorry.
>>> Feel free to ping Council about adding non-standard EAPIs to
>>> eclasses.
>>> 
> +inherit versionator + +# @FUNCTION:
> boost-utils_get_best_slot +# @DESCRIPTION: +# Get newest
> SLOT (major version) of Boost. +boost-utils_get_best_slot()
> { +   local pkg=dev-libs/boost +  local atom=$(best_version
> ${pkg}) + get_version_component_range 1-2 ${atom#${pkg}} 
> +} + +# @FUNCTION: boost-utils_get_includedir +#
> @DESCRIPTION: +# Get correct includedir for best Boost
> version. Outputs the sole path +# (without -I). 
> +boost-utils_get_includedir() { + local
> slot=$(boost-utils_get_best_slot) +   has "${EAPI:-0}" 0 1 2
> && ! use prefix && EPREFIX= + +   echo -n
> "${EPREFIX}/usr/include/boost-${slot/./_}" +}
 
 There needs to be a way to specify maximal accepted slot of
 Boost. Examples of some possibilities: *
 BOOST_MAX_SLOT="1.49" global variable * '--max 1.49'
 arguments for boost-utils_get_* functions
>>> 
>>> I'd rather wait with that till Tiziano expresses his opinion.
>>> I think the policy ought to be 'always prefer newest version'
>>> but I guess that's hard with boost.
>>> 
>> 
>> one of the points of having a slotted boost (besides solving the 
>> rebuild when API/ABI breakages occur) is that a package may also
>> use an older boost slot (currently it only would make sense if
>> we'd backport the glibc-2.16 patches but that's a different
>> story). So I'd prefer if we'd have a BOOST_MAX_SLOT variable.
> 
> Do we want to support using random old versions of boost then or
> just the newest supported SLOT? If the latter, we could get away
> without using best_version, and just request devs to depend on
> specific boost slot then.
> 

IIRC from comments on IRC, the idea with boost is that "newest
available" is what is recommended to be used, but obviously "newest
supported by ebuild" would take precedence, if a package can't be
built against a newer boost.

Otherwise why would we bother to slot in the first place?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA82acACgkQ2ugaI38ACPAc0gD+Ohokg0d6MAikZfLsyenyBnb6
PMIRVUI3VtHXcOz1cG4BALV9qTK1qSSUnNenRjjJxktdZ0f1Jatb69R+x9JXVM2m
=cIfW
-END PGP SIGNATURE-

Re: [gentoo-dev] Any official position from Gentoo about systemd, mdev and udev-static ?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28/08/12 11:47 AM, Rich Freeman wrote:
> On Tue, Aug 28, 2012 at 11:35 AM, Sylvain Alain
>  wrote:
>> Hi everyone, I don't want to start a flamewar on that subject,
>> but I would like to know if there's any official position about
>> the current situation.
> 
> There is not.  But thanks for starting the flamewar just the same.
> :)
> 

SYSTEMD OR DEATH!!!

..err..

UDEV FREEDOM FOREVER!!!

...

(that about covers it, yeah?  so we can all move on now?)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA86t4ACgkQ2ugaI38ACPBuHQD9FsdNxrjY6UTTpHkp81IkSrcl
z0HaPLKC9Ju1orRaQQgA/10Yn29tSt54yc8ieftOeAK2v9+rX4rbl17cLKy+TYOL
=86v4
-END PGP SIGNATURE-

Re: [gentoo-dev] EAPI usage

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/08/12 08:37 AM, Michael Mol wrote:
> On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber 
> wrote:
> 
> [snip]
> 
>>> Developers have only a limited amount of time, and this will
>>> eat into it.  The result is likely to not be new shiny ebuilds
>>> that use the new EAPIs, but rather old rusty ones that still
>>> use the old EAPI but also which contain other bugs, since they
>>> don't get touched at all (since touching them triggers the new
>>> policy).
>> 
>> You dont need to touch the old ebuild, but if you are touching it
>> for example a version bump, a bug fix etc you should be able to
>> do the EAPI bump as long as you have done the ebuild quizzes ;)
> 
> I'm a proxy maintainer. Meaning I haven't done these quizzes.
> Heck, I've never even seen them. I catch bug reports, come up with
> a solution and pass it back to Markos, who then decides whether or
> not to put it in and give feedback.
> 
> How would this impact me?
> 

If you are rewriting a full ebuild as your solution, and the ebuild
you start with is EAPI<4 , then Markos would appreciate it if you
changed the ebuild to be EAPI=4 (or whatever the latest EAPI is) in
addition to the fix.  Otherwise, just do what you do and Markos
"should" bump the ebuild to EAPI=4 when he applies your fixes.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA/Y1gACgkQ2ugaI38ACPCq1wEAowuUqEMzAj1vFXFrE0fkOkEi
gt4rKXXuCCxgb0h11WABAKsMa/7OI2dqX/JA6eXSYOAfsdm5vI7IUCY4MirLlT6s
=jwzi
-END PGP SIGNATURE-

Re: [gentoo-dev] EAPI usage

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/08/12 08:30 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber 
> wrote:
>> 
>> EAPI 0 is more readable than EAPI 4? No benefit for maintainer?
>> No benefit for user who wants to read the ebuild? Realy?
> 
> Then why make it a policy?
> 

("Realy?" in the above specifies the statement was sarcastic)

> If as you say there is a benefit to the maintainer, then you won't 
> have to hit them over a head for noncompliance.  Just point out
> that newer EAPIs make things easier, and they'll happily use the
> new EAPIs if they agree.  If they don't agree, who cares?
> 
> You don't need a policy to tell somebody to do something in their
> own interest.  The main reason for policy is to get people to do
> things that are in the interests of others.
> 


The primary benefit to the policy that dev's should bump EAPI when
bumping ebuilds is so that older inferior EAPIs can be deprecated and
eventually removed from the tree.

Take, for example, the sub-slot and slot-operator support that will
hopefully be applied as part of EAPI=5 -- when this is integrated
across the tree, there will be little to no purpose for revdep-rebuild
and/or @preserved-libs.  But this tree-wide integration would never
happen if said policy didn't exist, ie, I think this is a good example
of "interests of others".

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA/ZNEACgkQ2ugaI38ACPAthAD/XDwdxGj/cDprcFUtPUtklPaU
6KbooOamqxFJrfVxMbgBAJ56bQ+TYrYQ+eSvV+38bknCsp1+bKWfwXa1GxSERJha
=iaCP
-END PGP SIGNATURE-

Re: [gentoo-dev] EAPI usage

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/08/12 09:04 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 8:58 AM, Ian Stakenvicius 
> wrote:
>> If you are rewriting a full ebuild as your solution, and the
>> ebuild you start with is EAPI<4 , then Markos would appreciate it
>> if you changed the ebuild to be EAPI=4 (or whatever the latest
>> EAPI is) in addition to the fix.  Otherwise, just do what you do
>> and Markos "should" bump the ebuild to EAPI=4 when he applies
>> your fixes.
> 
> And if he doesn't have time to do that, he'll just go ahead and
> ignore your bug and users can make do without the fix.  :)
> 
> Rich
> 

I think you may miss the meaning of "should".  It's not the same as
"must".  IE, when bug or security fixes happen, i'm pretty sure it's
still OK to apply those (even when bumping the ebuild) as soon as
possible even though the ebuild isn't EAPI=4.

The idea here is to not let old EAPI's sit around in the tree forever,
not to halt all maintenance.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA/ZX8ACgkQ2ugaI38ACPCUWQD/azjLKkv6Mpa1tLuupSuOM5AZ
O1y83kdzWAYqeU/4tZAA/i/+8kEhOf76UDxm3f8K1AhOxQp7GUg/mO2MBRStdln+
=hM58
-END PGP SIGNATURE-

Re: [gentoo-dev] EAPI usage

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/08/12 09:14 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius 
> wrote:
>> 
>> The primary benefit to the policy that dev's should bump EAPI
>> when bumping ebuilds is so that older inferior EAPIs can be
>> deprecated and eventually removed from the tree.
> 
> What is the benefit from removing the old EAPIs?

Simpler eclasses is the first thing that comes to mind.  Consistency
in the way the dependency tree is built would be another (when newer
EAPIs address such things, that is)

> 
> Simply bumping an ebuild to EAPI=5 doesn't even guarantee that
> either of those features would be used anyway.

..although this could technicaly be true, I think most developers
would assume that bumping EAPI doesn't mean changing the EAPI variable
from whatever to 5 and that's it; the "bump" should involve
integrating any applicable features that the new EAPI offers.

> 
> If there is a benefit from some specific practice, then let's
> adopt it.  However, I don't think that is the same as just bumping
> EAPIs for their own sake.
> 
> When there is a benefit to adopting a new EAPI of course
> maintainers should try to take advantage of it.  If there are
> specific changes we want to try to make tree-wide let's try to do
> that too.  But, why bump ebuilds from 0 to 1 to 2 to 3 to 4 to 5
> when your only example of an end-user benefit would have been
> achieved if we just bumped from 0 to 5 in one step?


We used to have a policy that the oldest EAPI that implements all
features needed for an ebuild is the one that should be used.  Now (as
of when EAPI=4 was made official i think?) it's the reverse -- the
newest (official) EAPI is the one that should be used.  All this
policy change suggestion scarabeus provided is doing, is recommending
that developers bump EAPI when they bump their ebuilds, as compared to
only when writing new ones (which is all the current policy would
require us to do).

if you want another example, i'm sure end-user benefits would have
ensued if many existing packages that die in pkg_setup were bumped to
EAPI=4 right away and their checks moved to pkg_pretend.  Examples
prior to EAPI=4 are irrelevent as the policy was different then.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA/a6sACgkQ2ugaI38ACPBO5wD+JSBmTT3j0MFc1GMjIDatRLnV
J7Oj3rQWjS3GKpU8pQgBALsVg7R1QGGjETv0KS3j9yxBlflr4PlKECboVXqoRupL
=+zxo
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 31/08/12 10:56 AM, Alexis Ballier wrote:
> Michał Górny  wrote:
>> 
>> I believe that the more important direction here is to make 
>> development *easier*, not harder. Adding the same DEPENDs over
>> and over again to every single package is at least frustrating.
>> Similarly frustrating would be if those 'reduced systems' had to
>> rebuild gcc every time they wanted to compile something... oh
>> wait, they would have to bootstrap it every time.
>> 
> 
> you would achieve it better by adding pkgconfig to DEPEND in 
> eutils.eclass than putting it in @system since in the latter case
> it would also be a RDEPEND of everything basically
> 

And realistically that's where the DEPEND should be anyways, IMO --
appended by the eclass where the function is that uses it.  If this
means prune_libtool_files() gets separated out of eutils and put in
its own eclass (so that all the eutils inheritors don't suddenly need
virtual/pkgconfig unnecessarily), then so be it.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBA0rMACgkQ2ugaI38ACPB8dgD8CsXPJvPDjI3111dXT/z+gGUM
q8wTmMYqR2zVJasZMJQA/25de5bSofnwk4fXlCwPEFJ3Tu9rtCFRAx+q95oGFkad
=GWHe
-END PGP SIGNATURE-

Re: [gentoo-dev] EJOBS variable for EAPI 5?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 31/08/12 11:27 AM, Alexandre Rostovtsev wrote:
> On Fri, 2012-08-31 at 15:45 +0100, Ciaran McCreesh wrote:
>> On Fri, 31 Aug 2012 10:21:15 +0200 Ulrich Mueller
>>  wrote:
>>> Coming back to this old topic [1]. Is there still consensus
>>> that we should have such an EJOBS variable? (It shouldn't be
>>> called JOBS because this name is too generic, see the old
>>> discussion.) Then we could add it to EAPI 5.
>>> 
>>> Ulrich
>>> 
>>> [1] 
>>> 
>>
>>
>>> 
If we're doing this, do we tell users to stop setting MAKEOPTS for
>> EAPIs 5 and greater? Do we change the name of MAKEOPTS for EAPIs
>> 5 and greater instead? Do we put fancy code in the package
>> mangler to deal with it?
> 
> Users typically set MAKEOPTS systemwide in /etc/make.conf. If EJOBS
> will have no effect for  not be advising users to stop using MAKEOPTS until the whole tree
> has migrated to EAPI5. And if EJOBS will be recognized by a future
> version of portage for all EAPIs, then we still should allow
> MAKEOPTS because some users may want to use --load-average.
> 
> Changing the name of MAKEOPTS in >=EAPI5 makes no sense. First,
> because it's a standard environment variable used by gnu make.
> Second, because having 3 different settings for parallel building
> (EJOBS, MAKEOPTS, and "MAKEOPTS_EAPI5") would be insane.
> 
> Fancy code in the package manager would be the way to go IMHO.
> Ulrich's message contains a reasonable description of the
> algorithm.
> 
> -Alexandre.

I think, if i read the previous response to this correctly, that the
suggestion isn't the removal of MAKEOPTS, but simply that the '-j'
specification currently set in MAKEOPTS should instead be set in EJOBS
in everyone's make.conf.  This would then be appended to MAKEOPTS (for
all EAPI) -and- be used for non-make build systems (for EAPI>=5) alike.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBA4YUACgkQ2ugaI38ACPD96gD+Pu9f9SVG//0yhioO0LGP/W8o
sIGpiMFIEddXvhUsDAwA/0EJkZF8jrN7zmt/LdZy3nlCGKTIkPNxp5ukUGDDWIJB
=Dlem
-END PGP SIGNATURE-

Re: [gentoo-dev] EJOBS variable for EAPI 5?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 31/08/12 12:08 PM, Ian Stakenvicius wrote:
> On 31/08/12 11:27 AM, Alexandre Rostovtsev wrote:
>> On Fri, 2012-08-31 at 15:45 +0100, Ciaran McCreesh wrote:
>>> On Fri, 31 Aug 2012 10:21:15 +0200 Ulrich Mueller 
>>>  wrote:
>>>> Coming back to this old topic [1]. Is there still consensus 
>>>> that we should have such an EJOBS variable? (It shouldn't be 
>>>> called JOBS because this name is too generic, see the old 
>>>> discussion.) Then we could add it to EAPI 5.
>>>> 
>>>> Ulrich
>>>> 
>>>> [1] 
>>>> <http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml>
>>>
>>>
>>>>
>
>>>> 
If we're doing this, do we tell users to stop setting MAKEOPTS for
>>> EAPIs 5 and greater? Do we change the name of MAKEOPTS for
>>> EAPIs 5 and greater instead? Do we put fancy code in the
>>> package mangler to deal with it?
> 
>> Users typically set MAKEOPTS systemwide in /etc/make.conf. If
>> EJOBS will have no effect for > should not be advising users to stop using MAKEOPTS until the
>> whole tree has migrated to EAPI5. And if EJOBS will be recognized
>> by a future version of portage for all EAPIs, then we still
>> should allow MAKEOPTS because some users may want to use
>> --load-average.
> 
>> Changing the name of MAKEOPTS in >=EAPI5 makes no sense. First, 
>> because it's a standard environment variable used by gnu make. 
>> Second, because having 3 different settings for parallel
>> building (EJOBS, MAKEOPTS, and "MAKEOPTS_EAPI5") would be
>> insane.
> 
>> Fancy code in the package manager would be the way to go IMHO. 
>> Ulrich's message contains a reasonable description of the 
>> algorithm.
> 
>> -Alexandre.
> 
> I think, if i read the previous response to this correctly, that
> the suggestion isn't the removal of MAKEOPTS, but simply that the
> '-j' specification currently set in MAKEOPTS should instead be set
> in EJOBS in everyone's make.conf.  This would then be appended to
> MAKEOPTS (for all EAPI) -and- be used for non-make build systems
> (for EAPI>=5) alike.
> 


..hit send to soon...

So if users stick with setting -j in MAKEOPTS, then in EAPI=5 and
above this would only affect make-based builds; for parallel
compilation in non-make builds they would need to convert to using
EJOBS for EAPI=5 and above, otherwise those build systems will compile
serially instead of in parallel.





-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBA4jQACgkQ2ugaI38ACPAFrAEArp7MM5w4Mv/TLKb058HzB9oN
NtQeSVoCQ8X5PuxjjJ0BAKbTJXEkLlZ0hMr09RyTKzK0XtdQq6cf2fbeFFgFb5eV
=+vtW
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: prune_libtool_files() and pkg-config dependency

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 31/08/12 12:12 PM, Fabian Groffen wrote:
> On 31-08-2012 18:08:12 +0200, Michał Górny wrote:
>> And for a reasonable Gentoo toolchain, pkg-config is a must-have.
>> At least since we deprecated and are seriously fighting libtool.
> 
> what?

deprecated libtool = deprecated the installation of libtool's .la
files unless absolutely necessary



-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBA5YEACgkQ2ugaI38ACPBdKwD/VBUh3YujIN6gTAQD1NkWGij0
NHQbKrTeqTZV5i7S7IQBAJwCvgNuJgFRioAUMJrFfwQvNO7xEbt+hFXCtLM1zWtf
=ognq
-END PGP SIGNATURE-