Re: [gentoo-dev] Why adding python3_8 to Gentoo sucks?

[Ian Stakenvicius]

On 2019-11-13 4:16 p.m., Michał Górny wrote:

[ Snip! ]


Can automation help with this at all, or is automation being used 
already?


Also to clarify, is the issue here the way that we specify python 
versions syntactically in all of the ebuilds in the repo, or is it 
just the way the dependency graph and compatibility of packages 
against a new python variant pan out?

Re: [gentoo-dev] Packages up for grabs due to samba project being disbanded

[Ian Stakenvicius]

On 2019-03-27 4:25 p.m., Michał Górny wrote:
> On Wed, 2019-03-27 at 12:18 -0700, Matt Turner wrote:
>> On Wed, Mar 27, 2019 at 10:04 AM Michał Górny  wrote:
>>> The samba project will most likely be disbanded shortly.  While
>>> the current project members may stay as fallback maintainers,
>>> the following packages (being part of the Samba stack) would really use
>>> new, dedicated maintainers:
>>
>> I understand disbanding projects when they're really just the old
>> "herd" concept, but this actually looks like a coherent set of
>> packages that a project should maintain. I don't see a bug about
>> disbanding samba. What's the rationale?
> 
> The project's developers are no longer interested in maintaining those
> packages, and we're checking if people would be interested in some of
> them.  It's better to have a few disjoint maintainers than no
> maintainers at all.
> 

Some of those are separate, but most of those packages really need to
stay together, they all even come from the same upstream source...  I
don't know if disbanding the project is a good idea for that one.
These packages at minimum all need to be maintained together:

net-fs/samba
sys-libs/talloc [#]
sys-libs/tdb [#]
sys-libs/tevent [#]
sys-libs/ldb
net-misc/smbc




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Unmasking >=media-video/ffmpeg-4.0

[Ian Stakenvicius]

On 2018-11-06 11:21 a.m., Alexis Ballier wrote:
> On Tue, 6 Nov 2018 11:09:17 -0500
> Rich Freeman  wrote:
> 
>> On Tue, Nov 6, 2018 at 10:57 AM Alexis Ballier 
>> wrote:
>>>
>>> On Tue, 06 Nov 2018 17:08:22 +0200
>>> Mart Raudsepp  wrote:
>>>  
 It is not GStreamer fault that ffmpeg breaks API and ABI without
 parallel installability, much less so the distro maintainers of
 it. If you/upstream don't make it parallel installable, then this
 is what you get.  
>>>
>>> Are you, seriously, suggesting this is the solution to all problems
>>> here ?
>>>  
>>
>> It isn't the only solution, but it is one sane upgrade path.  You
>> can't expect everybody to update their software overnight when the API
>> changes.  That means you have to support the old API for a while when
>> you introduce a new one, otherwise you end up with some software that
>> doesn't work with the old version, and some software that doesn't work
>> with the new version.
> 
> 
> These days, only symbols/constants that have been deprecated (and
> marked as such) for a couple of releases are removed. This means people
> see warnings for more than one year before seeing them gone for good.
> The problem here is not "overnight changes" but rather consumers not
> paying attention to those warnings, or worse, nobody ever seeing those
> because it's unmaintained.
> 

But we aren't upstream most of the time, and if upstreams are pegging
their ffmpeg to a single version they don't bother to try the newer
one to find out the errors.  Take Kodi, v17.x is pegged to no newer
than ffmpeg-3.3.x as I recall, and has been blocking even v3.4's
installation for the year'ish it's been in the gentoo repo.

So this "people see warnings" thing, it really doesn't apply, unless
you (A) have the desire and resources to build and maintain a patch
for upstream, and (B) have an upstream with the desire and resources
to support more than the one version of ffmpeg for a given release
set.  Both, IMO, are in very short supply.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Adding USE=udev to linux profiles

[Ian Stakenvicius]

On 2018-07-24 1:55 p.m., Dennis Schridde wrote:
> Am Dienstag, 24. Juli 2018, 19:15:19 CEST schrieb Ian Stakenvicius:
>>
>> This is getting a little scary as to what is overriding what, within a
>> repo.
> 
> I also tried to untangle this in my email from Sat, 21 Jul 2018 14:45:12 +
> 

Yeah I did see that after posting my message; I believe both of our
lists align.


> 
>> Lets take a look at what we -can- do right now:
>>
>> (a) use flag can be set globally by the repo
>> (b) ebuild IUSE can set (and unset?) a flag's state
>> (c) make.defaults and package.use from the profile (that generally is
>> defined within the gentoo repo) sets/unsets a flag's state
>> (d) make.conf sets/unsets a flag's state
>> (e) /etc/portage/package.use sets/unsets a flag's state
>> (f) {,package.}use.{mask,force} from the profile overrides a-e
>> (g) /etc/portage/profile/{,package.}use.{mask,force} overrides f
>>
>> That's a lot of possible state overriding.
> 
> I, too, would hope that at some point later, independently of this 
> discussion, 
> the algorithm for determining what use flags are active for a certain package 
> could be simplified.
> 

I don't think the process needs to be simplified much more than this;
each layer above has its purpose.  However I do very much want to
caution on making it more complicated, especially with the addition of
syntax that allows setting or ignoring useflag state changes in a way
that will jumble up these layers.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Adding USE=udev to linux profiles

[Ian Stakenvicius]

On 2018-07-22 1:52 p.m., Michael Orlitzky wrote:
> 
> [...]
> 
> It looks to me like *within (sub)profiles*, a USE="-foo" should undo
> USE=foo, rather than adding "-foo" to the list of tokens that get pushed
> down via USE_ORDER.
> 


...except that we often want the sub-profile containing "-foo" to not
only undo +foo from a parent profile BUT ALSO unset +foo from IUSE.
IE, the way "-jit" is set globally in hardened profiles.

Though you do bring up an interesting point -- as portage may be the
only one doing it this way, I wonder what happens with other PMs...




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Adding USE=udev to linux profiles

[Ian Stakenvicius]

On 2018-07-21 9:33 a.m., Rich Freeman wrote:
> On Sat, Jul 21, 2018 at 5:33 AM Zac Medico  wrote:
>>
>> Sure, why not? So ^flag would mean that the flag state propagates from
>> the settings in IUSE.
> 
> Presumably this could be overridden in subsequent profiles, or
> /etc/portage.  That is, one profile might set a flag, and another
> profile could unset it, and then the final one could re-set it.
> 
>> It's also conceivable that we could add a way for
>> profiles to modify the effective IUSE defaults, via new operators in
>> package.use or by introducing a new file such as package.use.default.
> 
> That makes sense, or the syntax could be available in the ebuild.  I
> imagine the better approach to take would depend on the nature of the
> incompatibility.
> 

This is getting a little scary as to what is overriding what, within a
repo.

Lets take a look at what we -can- do right now:

(a) use flag can be set globally by the repo
(b) ebuild IUSE can set (and unset?) a flag's state
(c) make.defaults and package.use from the profile (that generally is
defined within the gentoo repo) sets/unsets a flag's state
(d) make.conf sets/unsets a flag's state
(e) /etc/portage/package.use sets/unsets a flag's state
(f) {,package.}use.{mask,force} from the profile overrides a-e
(g) /etc/portage/profile/{,package.}use.{mask,force} overrides f

That's a lot of possible state overriding.

Now as I understand it, the issue here is that there is no way in (d)
to undo what is done in (c) on a global per-flag basis, ie, from
make.defaults, such that IUSE(b) is honored, correct?

What if we just split (c) so that make.defaults (c1) and package.use
(c2) are applied independently?  That way (d) is meant to override
(c1), and (e) is meant to override (c2), and if an end-user wants IUSE
to take priority over (c1)+(d) they can change USE_ORDER accordingly?

I believe with wildcards, that in (e) we can set global flag overrides
still via an atom (like "*/*::gentoo [flag]") in
/etc/portage/package.use, correct?  So we end-users would still have
the ability to define global state of a flag with a single line even
if IUSE was prioritized above make.defaults+make.conf

Note that I'm not suggesting we change the default value of USE_ORDER
right now, only that if we split 'defaults' into 'makedefaults' and
'packagedefaults' that end-users could set it up themselves a lot more
easily by changing their own USE_ORDER default.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] EAPI 7 in Portage needs YOU!

[Ian Stakenvicius]

On 2018-02-19 07:19 PM, Michael Lienhardt wrote:
> 
> 
> Il 19/02/2018 20:38, Michał Górny ha scritto:
>> W dniu pon, 19.02.2018 o godzinie 21∶32 +0200, użytkownik Mart Raudsepp
>> napisał:
>>> On Mon, 2018-02-19 at 18:34 +0100, Ulrich Mueller wrote:
 It is explained in section 8.2.4:
 https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-88.2.4
>>>
>>> Maybe I missed this, but a real world use case example would be nice,
>>> maybe someone feels a harder itch to scratch then :)
>>>
>>
>> The original use case was for providers-like thingies, e.g.:
>>
>>    ||= ( ffmpeg:0= libav:0= )
>>
>> That said, I'd personally prefer doing that with proper USE_EXPAND
>> and REQUIRED_USE enforcing but this has been rejected.
>>
> 
> So, if I understand correctly, the ||= group is an "or" that must be
> resolved in the same way in the DEPEND and RDEPEND dependencies, right?
> 
> The documentation does not specify how this group interacts between
> different ebuilds.
> I guess there is no interaction, but just to be sure, let consider the
> following corner-case example:
>  - a package A has RDEPEND=||= ( ffmpeg:0= libav:0= ) while another
> package B has DEPEND=ffmpeg
>  - the solver choose libav to solve the dependency of the first
> package and ffmpeg to solve the second, removing ffmpeg afterward
>  - will package A break?
> 
> Michael Lienhardt


I don't think interaction with other ebuilds is necessarily important,
or at least, not any different as what occurs with a package manager
decides to do something with the bound atom.  Using your example of
pkg-A built with libav:0= bound:

1- ffmpeg is merged (lets ignore that ffmpeg blocks libav for now) --
this wouldn't change anything regarding pkg-A as it is currently
merged, but if pkg-A is re-emerged for whatever reason then I believe
the package manager needs to decide according to the rules to build
against ffmpeg.

2- libav is unmerged -- pkg-A is broken.  It's likely up to the PM
implementation what to do here.  In the case of portage, and the
libav-unmerge being a soft-blocker, I believe the behaviour would be
to trigger a re-emerge of pkg-A which would then through standard
dependency resolution decide that it will now depend on ffmpeg.An
alternative would be to upgrade the soft-blocker to a hard-blocker
since pkg-A is bound to libav:0= and so it can't be resolved
automatically.  A manual unmerge likely should trigger something about
pkg-A too but even in portage's case the user can do that and break
dependencies, so it's not obvious to me what would be done.

Now, since ffmpeg and libav do block eachother, the switch from one to
another would trigger both of these cases which IMO would mean portage
would therefore rebuild pkg-A after ffmpeg is emerged (and libav would
be unmerged before ffmpeg is merged).  And the multi-ebuild
interaction that you speak of would simply force ffmpeg as a hard
dependency in resolution, triggering the soft-block and therefore the
rebuild.

EAPI7 is TL;DR for me right now but I assume that it doesn't specify a
required action for "package broken"?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] EAPI 7 in Portage needs YOU!

[Ian Stakenvicius]

On 2018-02-19 12:34 PM, Ulrich Mueller wrote:
>> On Mon, 19 Feb 2018, Michael Lienhardt wrote:
> 
>>> 2. ||= (binding any-of) dep groups.
> 
>> I don't understand what this group means, and the PMS-7 is
>> unclear as well: "binding-any-of A binding-any-of group, which
>> has the same format as the any-of group, but begins with the
>> string ||= instead." Is it a "or", like the "any-of" group, but
>> with a different behavior at compiling/linking time?
> 
> It is explained in section 8.2.4: 
> https://dev.gentoo.org/~ulm/pms/7-draft/pms.html#x1-88.2.4
> 
> Ulrich
> 


Could we get some clarification/confirmation on this language?:


> In addition, for runtime dependencies, indicates that the package
> will break unless a matching package corresponding to the first
> immediate child element (in order of listing) installed as a
> build-time (DEPEND) dependency is available


...if I am reading this right, this means that the list of atoms is
iterated through first->last, and as soon as one is found to be
available at build-time, it chosen as the one that this package is
bound to and after that the package will be considered broken if it
doesn't exist/is later removed?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] News Item: Portage Dynamic Deps

[Ian Stakenvicius]

On 2018-01-22 05:28 AM, Andreas K. Huettel wrote:
> Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico:
>>
>> According to Gentoo policy, future ebuild dependency changes need to be
>> accompanied by a revision bump in order to trigger rebuilds for users.
>> Therefore, you should only need to use --changed-deps=y for a single
>> deep @world update. After that, if you encounter installed packages with
>> outdated dependencies in a future deep @world update, then you should
>> report it as a bug.
> 
> Did you come up with a solution how to handle eclass-generated dependency 
> changes then?
> 
> I'd loathe to have to do identical revision bumps for, say, all perl-
> module.eclass consumers...
> 

Based on what I'm seeing in perl-module.eclass now I don't think this
is an issue -- first, perl isn't slotted; second, perl doesn't specify
${PV} information in the eclass.  If it started to do either of these,
then yes revbumps are going to start being necessary..




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Open Build Service

[Ian Stakenvicius]

On 14/11/17 02:33 AM, Peter Volkov wrote:
> On Tue, Nov 14, 2017 at 4:47 AM, Samuel Bernardo
> >
> wrote:
> The only feature that would be useful for now is emerge obtaining the
> 
> precompiled binary packages to install in containers/VMs from http
> rather than nfs[1].
> 
> 
> Samuel, probably I miss something but this should work out of box:
> https://wiki.gentoo.org/wiki/Binary_package_guide#Web_based_binary_package_host
> 
> Or do you mean something else?
>  

I would mirror Peter's concern here -- if you use a "build box" system
to generate binary packages with FEATURES="buildpkg", then the
consumer systems that would use FEATURES="getbinpkg" will fetch the
binary packages with the same standard fetch mechanisms as they do for
distfiles (http, https, ftp) based on the value of PORTAGE_BINHOST in
make.conf.  There shouldn't be any need for NFS from the portage
(emerge) perspective.


To the project in general:

You may want to look into the tindeboxing projects for your basis -- I
think those might get you closer to a fully automated package building
system than working up from catalyst alone.

The biggest issue you will have with doing these types of builds,
though, is dealing with the various use flag differences that various
consumer systems may have.  From what little I've played with binary
builds, if you want to offer binpkg's for an entire system set you
pretty much have to synchronize all use flags across all systems.  So
a realistic deployment will essentially require (a) adherence to a
specific set of static profiles, or (b) a nearly-infinitely-growing
number of build profiles that match each permutation of global and
per-package use flag settings that your consumers would have.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected

[Ian Stakenvicius]

On 28/09/17 10:23 AM, Thomas Deutschmann wrote:
> Hi,
> 
> sounds like we should convert to prune_libtool_files usage from
> ltprune.eclass.
> 
> However, the eclass says
> 
>> # Discouraged. Whenever possible, please use much simpler:
>> # find "${D}" -name '*.la' -delete || die
> 
> So this would need clarification.
> 
> 

*.la shouldn't be matching *.dll.a , this seems like a globbing error
if that find command is what's being used.  Maybe we've just been
erroneously not escaping the '.' in the find command??




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] autotools.eclass: automatically move configure.in to configure.ac

[Ian Stakenvicius]

On 11/06/17 04:02 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 11.06.2017 kell 13:08, kirjutas William Hubbs:
>> On Sun, Jun 11, 2017 at 07:14:52PM +0300, Mart Raudsepp wrote:
>>> Ühel kenal päeval, P, 11.06.2017 kell 11:12, kirjutas William
>>> Hubbs:
 On Sun, Jun 11, 2017 at 05:35:53PM +0200, Kristian Fiskerstrand
 wrote:
> On 06/11/2017 05:24 PM, David Seifert wrote:
>>> We can always patch the eclass at that point if that is
>>> still a
>>> big
>>> concern, but I fundamentally agree with William on this,
>>> starting
>>> point
>>> should be fixing it upstream, so can start with a tracking
>>> bug
>>> on
>>> affected packages.
>>>
>>
>> Here's a deal: you can start filing + fixing them.
>>
>
> The [tracker] is already started, it was determined to add QA
> warning
> with info on filing upstream bugs in [bug 426262] and the
> proper
> solution is again iterated in [bug 546614], so its not like
> this is
> a
> new approach that is being suggested, but sure, we should all
> file
> bugs
> when we encounter them.
>
> References:
> [tracker] https://bugs.gentoo.org/show_bug.cgi?id=530632
>
> [bug 426262]
> https://bugs.gentoo.org/show_bug.cgi?id=426262
>
> [bug 546614]
> https://bugs.gentoo.org/show_bug.cgi?id=546614

 It seems that the proper fix to this, even for a package that
 won't
 do
 the fix upstream is to use WANT_AUTOCONF in the ebuild to force
 the
 version of autoconf you need.
>>>
>>> No. It appears you don't know how WANT_AUTOCONF works.
>>
>>  
>>  From the eclass:
>>
>> # @ECLASS-VARIABLE: WANT_AUTOCONF
>> # @DESCRIPTION:
>> # The major version of autoconf your package needs
>>
>> That leads me to believe that you can set WANT_AUTOCONF="someversion"
>> in your ebuild and your package will use that version of autoconf.
>>
>> If that's wrong, it needs to be fixed and that's a different bug
>> entirely, but it doesn't change my position on adding this particular
>> change to autotools.eclass.
> 
> It is the major version, as documented. Yes, it could specify what
> these valid versions currently are, as they really are:
> 
> none
> 2.1
> 2.5
> latest
> 
> Currently latest equals 2.5 and is the default.
> 
> In practice, none means not to add an autoconf atom to DEPEND (even
> with the default AUTOTOOLS_AUTO_DEPEND=yes) - if ebuild/eclass
> inheriting autotools.eclass handles its own exact autoconf depend atom
> (eautoconf will get called in eautoreconf regardless). Only main tree 
> consumer of this appears to be gtk-sharp-module.eclass that adds its
> own autoconf/automake atoms when needed, because eautoreconf is
> conditional by variables used by that eclass and it needed autoconf
> 2.61 or newer, not just 2.59.
> 
> 2.1 means autoconf:2.1
> 
> 2.5 and latest currently means >=autoconf-2.59
> 
> Patches welcome to documentation, I suppose.
> 
> 
> It is usually a bad sign if you need to change it away from latest for
> some reason in the ebuild and ideally they'd all be the default
> (latest).
> 
> There was no configure.ac before autoconf-2.50, only configure.in, and
> thus a warning doesn't make sense. The real warning here is the need
> for WANT_AUTOCONF=2.1
> 

I'm not seeing the issue with what William's suggesting -- if the
configure.in is non-trivial to just rename in the ebuild, then setting
WANT_AUTOCONF=2.1 would seem to me to be the correct course of action.
 If there's a package that has a configure.in but also needs
autoconf:2.5, well, that seems messed up and likely should be fixed in
the ebuild (or upstream) too.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Of death and prerm

[Ian Stakenvicius]

On 30/08/17 10:04 AM, Michael Orlitzky wrote:
> On 08/30/2017 09:46 AM, Ian Stakenvicius wrote:
>>
>> For adding this to FEATURES and RESTRICT, are we moving into PMS
>> modification territory?  And if so, is this something we want to do
>> just for this?
>>
> 
> The new RESTRICT value would need a PMS update, but the "just for this"
> part is where it gets good. The only reason I need it is for a reference
> implementation of the idea that needs it, to determine if the idea is
> any good or not.
> 
> It would be a lot of trouble to go through just to find out that my
> proposal is junk.
> 

Oh, well, a patch to portage (or an unofficial EAPI for testing) just
to evaluate your proposal wouldn't be a big deal I expect, if indeed
this is the direction to go.

I wonder though, per the original idea, wouldn't it make more sense to
allow uninstallation to continue and just very verbosely
warn/log/document what the package removal didn't do, so that it can
be done later by hand as needed?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Of death and prerm

[Ian Stakenvicius]

On 30/08/17 09:40 AM, Ulrich Mueller wrote:
>> On Wed, 30 Aug 2017, Michael Orlitzky wrote:
> 
>>> This rather sounds like a case for package manager support with
>>> some property like RESTRICT="uninstall".
> 
>> Would it still be possible to override with
>> I_KNOW_WHAT_I_AM_DOING=yes then?
> 
> No. If this was to be implemented in Portage, I think the canonical
> way to override it would be via some token like "force-uninstall"
> in FEATURES (which can be specified on the command line too).
> 
> Ulrich
> 

For adding this to FEATURES and RESTRICT, are we moving into PMS
modification territory?  And if so, is this something we want to do
just for this?

(it might well be if all of this is for a proposal to extend future
EAPI anyways, I haven't been paying attention)




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

[Ian Stakenvicius]

On 08/08/17 01:23 PM, William L. Thomson Jr. wrote:
> On Tue, 8 Aug 2017 19:11:18 +0200
> Kristian Fiskerstrand  wrote:
> 
>> it can already be controlled through env files.
> 
> I was thinking it might, but having used them to skip other hooks. I
> was thinking they could not be used as such for binary packages. Have
> you confirmed such is possible?  Could you provide a link or example?
> Thanks!

I'm not sure explicitly about environment files, but it's an option to
emerge.  For instance, I've added this to my EMERGE_DEFAULT_OPTS to
ensure none of the following are built:

--buildpkg-exclude "virtual/* sys-kernel/*-sources dev-perl/* perl-core/*"





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ian Stakenvicius]

On 10/07/17 04:47 PM, William L. Thomson Jr. wrote:
> On Mon, 10 Jul 2017 15:36:11 -0500
> Ben Kohler  wrote:
>>
>> If you want dependencies checked, use the correct option which checks
>> them.  This takes significantly longer than -C, as it's significantly
>> more complex to check for.
>>
>> As far as I can tell, you are literally asking for -C to behave like
>> -c, when you could just be using -c instead.
> 
> No I simply want warnings like that exist for profiles and set packages.
> 
> Also more information when attempting to remove a package that is not
> removed.
> 

OK, well, as Ben said it's not feasible to make -C act like -c due to
the performance hit involved and due to the purpose of the command itself.

It likely is feasible and may well make sense to add a message to the
-c output that states that packages in the provided list aren't
removed because they are dependencies.  You should open up a bug for
that against portage and let the portage dev's sort it out.







signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] mingw-w64 crossdev prefix?

[Ian Stakenvicius]

On 18/05/17 12:08 AM, Marty Plummer wrote:
> On Thu, May 18, 2017 at 06:46:24AM +0300, Alon Bar-Lev wrote:
>> Hi,
>> You can emerge crossdev and then run crossdev -t x86_64-w64-mingw32 or
>> crossdev -t i686-w64-mingw32
>> Alon
>>
> I'm aware of that, using it. Its simply the fact that its fairly broken
> for mingw-w64, and requires quite a lot of hackage to get going.
> 
> What I'm suggesting is the creation of a profile that should handle this
> sort of thing for you semi-automatically. Something like the
> prefix/windows, but meant more for toolchains. it seems that beber's
> portage tree at git.meleeweb.net/gentoo/portage.git already has a setup
> similar to what I envision already.
> 

There isn't a whole lot that's broken about it actually -- the main
issue is that the default 'embedded' profile doesn't allow all of the
variable overrides in it that are necessary for the crossdev to work
properly.  See bug http://bugs.gentoo.org/487310

The crossdev that's created will provide all the necessary profile
overrides to allow you to emerge the things you want, and of course
compile your own things as well.  There's no need for a special prefix
(or 'prefix/*' profile) in order to support this, IMO, once the
embedded profile permits the overrides necessary to the ARCH, ELIBC,
and KERNEL variables that the crossdev tool already sets.







signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: gcc-6.x status inquiry

[Ian Stakenvicius]

On 03/05/17 02:42 PM, William Hubbs wrote:

On Wed, May 03, 2017 at 02:00:26PM -0400, Ian Stakenvicius wrote:

On 03/05/17 01:58 PM, Luca Barbato wrote:

On 5/3/17 6:43 PM, William Hubbs wrote:

Hey all,

I am asking about this because I have been asked to look into
packaging software that has a specific requirement for >=gcc-6 in order
to build [1].


As I said few times, we should dump gcc-5 sooner than later and any
software that does not build with gcc-6 should be p.masked and dropped
from the tree if there isn't a nice fix for it.


Just a heads-up, that p.mask list would happen to include firefox and
thunderbird right now.
  
  So if we don't p.mask those, is them breaking with gcc-6 still enough

  to keep gcc-6 out of ~? If not, I definitely +1 what lu_zero said,
  let's add ~keywords to gcc-6.

  William



No, i'm good with keywording gcc-6 still.  I'm just not Ok with 
firefox and tbird and others being p.masked for removal simply because 
they don't build.


Also its worth noting that the gcc-6.3 build failure is apparently not 
absolute, there are people that have built mozilla stuff fine with 6.3

Re: [gentoo-dev] Re: gcc-6.x status inquiry

[Ian Stakenvicius]

On 03/05/17 01:58 PM, Luca Barbato wrote:

On 5/3/17 6:43 PM, William Hubbs wrote:

Hey all,

I am asking about this because I have been asked to look into
packaging software that has a specific requirement for >=gcc-6 in order
to build [1].


As I said few times, we should dump gcc-5 sooner than later and any
software that does not build with gcc-6 should be p.masked and dropped
from the tree if there isn't a nice fix for it.


Just a heads-up, that p.mask list would happen to include firefox and 
thunderbird right now.

Re: [gentoo-dev] eclass-manpages are now versioned (snapshotted)

[Ian Stakenvicius]

On 24/03/17 11:19 AM, Michał Górny wrote:

Hi, everyone.

With a little delay I would like to announce that the eclass-manpages
package is now properly versioned, starting this Tuesday. Most
importantly, this means that users will no longer have to periodically
rebuild the package in order to get the correct set of manpages --
instead, the package will be upgraded in the regular motion.

The versioned packages use archived snapshots of eclass files. Those who
prefer the old mechanism can decide to unmask (via
package.accept_keywords) the live ebuild (-*).

While at it, I would like to encourage developers to create new
snapshots and bump the package themselves whenever they commit eclass
changes that could require updating the documentation. The ready command
set is provided in the ebuild. For completeness, I will paste it here:

  mkdir eclass-manpages-$(date +%Y%m%d)
  cp "$(portageq get_repo_path / gentoo)"/eclass/*.eclass 
eclass-manpages-$(date +%Y%m%d)/
  tar -cf eclass-manpages-$(date +%Y%m%d).tar eclass-manpages-$(date +%Y%m%d)
  xz -9e eclass-manpages-$(date +%Y%m%d).tar
  scp eclass-manpages-$(date +%Y%m%d).tar.xz dev.gentoo.org:public_html/dist/

Then copy the ebuild and update your name in SRC_URI ;-).



This looks great!

To help manage this a little bit, what are people's thoughts on having 
the generation be a bit more automated?  I'm thinking running the 
generator once per day, comparing the result against the previous 
day's result (and aborting if it's the same), and them bumping the 
package that way?


Having a single point of generation would prevent two people doing it 
at the same time because of changes to different eclasses..  Not that 
eclasses change -that- much, but..

Re: [gentoo-dev] How to deal with package forks?

[Ian Stakenvicius]

On 09/03/17 10:34 AM, Michał Górny wrote:
> The second group (patch sets) is more unclear. AFAICS some people argue
> that packages with major patch sets applied should be distinguished by
> separate package names. Others see that applying them via USE flags is
> easier.
> 
> Separate packages are used e.g. for different kernel patch sets. This
> has the following advantages:
> 
> 2a1. more clear distinction between base and patched version,
> 
> 2a2. cleaner when patch sets imply major changes, e.g. when some
> of the USE flags apply to patched version only,
> 
> 2a3. the packages can be bumped independently, without worrying that
> the patch set has not been updated yet.
> 
> A single package with USE flags is used e.g. for openssl (hpn patch
> set), bitcoincore (ljr patch set). This has the following advantages:
> 
> 2b1. available patches are cleanly exposed via USE flags,
> 
> 2b2. multiple patch sets can be combined in a single package,
> 
> 2b3. usually there is less work for the package maintainer.
> 
> 
> The third group (dead package forks) is most unclear to me, especially
> that those kinds of forks frequently continue using the original package
> name.
> 
> The advantage of treating the fork as a continuation of the original
> package is that it requires no effort from users, and is clear from
> keywording/stabilization perspective. However, it means that users
> suddenly start using a package from different upstream -- but then, does
> it differ much compared to when upstream developers change?
> 
> Using separate packages would clearly indicate that we're switching to 
> a fork. However, usually this would mean inventing a custom package name
> (like 'xarchiver-ib'), and somehow informing users about the switch. For
> stable packages, we'd also have to figure out some reasonable way to
> suggest the upgrade first to ~arch users, then to stable.
> 

I think for both of these cases, developer discretion is required to
choose the correct path.  For the large-patchset case, it depends for
instance if the patchset is just adding major features not included
upstream or if it's significantly changing the regular operations of
the package (almost as if it should be a fork) -- the bitcoin example
may (can't confirm as i haven't looked) fall into the latter case,
while USE=experimental on gentoo-sources definitely falls into the
former IMO.

Similarly for the dead-fork case -- x11-misc/slim is my example on
this one, as the original upstream has died twice since I started
maintaining that package and most recently I've essentially taken over
the package and become its upstream (at least for gentoo; it's unclear
what other distros are using but all of the various forks that seem to
be out there are more out-of-date than mine).  Back to the point, the
change in fork on the x11-misc/slim package in this case just ensures
continuity; I expect there are other packages where the new generation
arising from the previously dead upstream warrants a whole new name,
especially if this fork has adopted a new or revised name.  I expect
we likely SHOULDN'T diverge from upstream naming in these cases unless
there's a really good reason to do so, but at the same time if there's
a fork that has become a de-facto new upstream I expect it's safe to
use that directly without any form of rename or possibly even end-user
notification.

It's the maintainer's responsibility to ensure the package works as
expected and pick up the pieces whenever it doesn't, which can (often)
mean maintaining large patchsets that take forever to integrate
upstream (if ever).  Although I think most of those tend to be
build-system related rather than code related, it's all sort of within
the same overall scope.  We do have a loose (or is it firm?) policy to
avoid deviation from the upstream experience as much as possible in
gentoo-repo packages, so as long as said experience is maintained from
the end-user perspective I think the maintainer's choice is fine.

Of course, when packages are proxy-maintained things can get a little
more difficult as more often than not we don't really have a de-facto
gentoo maintainer, so maybe in those cases a clear policy or guidline
of what proxy-maint will and won't accept should be defined.







signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Eix and deps up for grabs

[Ian Stakenvicius]

Hey all - since I have never really been maintaining these properly
and as the last commits to these packages have been from other devs,
its time for the metadata to properly reflect this.  If anyone's
interested, could you please take up these packages?

app-portage/eix
app-shells/push
app-shells/quoter




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

On 07/02/17 12:00 PM, Rich Freeman wrote:
> On Tue, Feb 7, 2017 at 10:14 AM, Ian Stakenvicius <a...@gentoo.org> wrote:
>> On 07/02/17 08:27 AM, Michael Orlitzky wrote:
>>>
>>> The thread wasn't about discouraging IUSE defaults, rather to decide
>>> when they are appropriate. You cannot omit "pkginternal" from USE_ORDER,
>>> because you will break all of the packages whose defaults are either
>>> critical to the package, or prevent a REQUIRED_USE conflict.
>>>
>>
>> OK, can we all decide out of this thread, that if any package is
>> enabling critical functionality via IUSE-defaults (or rather, IUSE
>> defaults alone), that this be addressed through package.use.force in
>> profiles OR through removal of the flag?
> 
> No.
> 

Do we need to define "critical functionality" first, then?


>>
>> That at least seems like a positive first step to helping address
>> Michael's concerns, and should generally help all end-users.
>>
> 
> It only helps users who want to manually enable every single feature
> they use with an otherwise-minimal configuration.

Actually the way I see it, it helps support a USE="-*" case by not
disabling something that, although enabled via IUSE-defaults, probably
shouldn't be a flag (or should only be disable'able on certain
platforms or profiles)

Example -- USE="jit" on mozilla packages (prior it to being removed
completely, that is, which started with 51.0).  That flag was
IUSE-default-enabled, but realistically it should have probably been
package.use.force'd except on platforms (ia64,etc) and profiles
(hardened) where it doesn't work or provide what is expected from
users of those profiles.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

On 07/02/17 08:27 AM, Michael Orlitzky wrote:
> 
> The thread wasn't about discouraging IUSE defaults, rather to decide
> when they are appropriate. You cannot omit "pkginternal" from USE_ORDER,
> because you will break all of the packages whose defaults are either
> critical to the package, or prevent a REQUIRED_USE conflict.
> 

OK, can we all decide out of this thread, that if any package is
enabling critical functionality via IUSE-defaults (or rather, IUSE
defaults alone), that this be addressed through package.use.force in
profiles OR through removal of the flag?

That at least seems like a positive first step to helping address
Michael's concerns, and should generally help all end-users.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

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

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

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

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





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

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

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

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





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

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

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

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





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

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

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

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





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

Responding here instead of the first time it was posted, just 'cause.

On 02/02/17 06:35 PM, james wrote:
> "
> I'm not saying that we should have a minimal experience out-of-the-box,
> only that the base profile should result in an effectively-minimal set
> of USE flags. Adding IUSE defaults is essentially adding defaults to the
> base profile."


Yes.  More specifically, it's adding these defaults without setting
the flags globally, thereby not introducing system-wide defaults
across all packages but only those that make sense on a per-package
basis for that package to operate properly.

IMO this is the effectively minimal-set of use flags we should have.
All of these flags can be easily overridden for a more minimalist, and
IMO they should definitely attempt to avoid any REQUIRED_USE like
conflicts (that is, two packages collide because their IUSE-defaults
make dependencies conflict).  But no less than that should be what the
base package provides, IMO.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Guidelines for IUSE defaults

[Ian Stakenvicius]

> On Feb 2, 2017, at 9:11 AM, Michael Orlitzky  wrote:
> 
> IUSE defaults are used in a few different ways:
> 
>  1 To ensure that critical functionality is enabled.
> 
>* Example: force the "unix" module for apache.
> 

This is not what IUSE defaults are for, this should be done with 
package.use{,.stable}.{mask,force} in profiles.  If functionality is critical 
then there (A) shouldn't be a use flag, or (B) shouldn't be a way for USE= in 
make.conf to disable it.

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

[Ian Stakenvicius]

On 01/02/17 10:39 AM, William Hubbs wrote:
> 
> I thought about autotools. I'm not really fond of its syntax, and I've
> been told that, to use autotools correctly, I would need to start
> generating manual release tarballs again because I would need to put the
> autotools generated cruft in them.


Well, #1, you should do that anyways.  But, #2, no you don't -need- to
have autoconf already run inside the tarball if you really don't want
to; it's convention but there are projects that don't.  Also, #3,
doing this is as easy as running 'make dist' when you have an
autotools build system, so generating said tarballs for release may
actually be -easier- than what you're doing now.





signature.asc
Description: OpenPGP digital signature

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

[Ian Stakenvicius]

On 01/02/17 09:43 AM, William Hubbs wrote:
> On Wed, Feb 01, 2017 at 01:18:42PM +0100, Michał Górny wrote:
>> W dniu 30.01.2017, pon o godzinie 14∶04 -0600, użytkownik William Hubbs
>> napisał:
>>> All,
>>>
>>> I have been looking at the meson build system [1] [2], and I like
>>> what I
>>> see.
>>>
>>> I have opened an issue on OpenRC's github wrt migrating OpenRC to the
>>> meson build system [3].
>>>
>>> As I said on the bug, the downside is the addition of py3 and ninja
>>> as
>>> build time dependencies, but I think the upside (a build system where
>>> we don't have to worry about parallel make issues or portability)
>>> outweighs that.
>>>
>>> What do folks think here?
>>
>> On behalf of systemd team, I would like to officially contradict any
>> rumors that those ideas are in any way caused by systemd team. OpenRC
>> developers are shooting their own feet of their own choice.
> 
> I don't even know what this is about. I have said nothing about systemd
> or any other package like that.
> 

Pre-emptive strike is all.  We all know systemd gets blamed for
everything. :D





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fwd: Cron <gmirror@dipper> /usr/local/bin/pidlock -s rsync-gen /bin/bash /usr/local/bin/mastermirror/rsync-gen.sh

[Ian Stakenvicius]

On 26/01/17 06:48 PM, Doug Freed wrote:
> This is the email I get when a Manifest is missing DIST entries; it's
> more verbose than it needs to be, but I'd rather have more than less.
> In this particular case, the developer that made the bad commit likely
> had something they were working on in sys-cluster/torque added to the
> git index (ie, they did git add), and then needed to make an unrelated
> change, and didn't stash their changes beforehand.  You should always
> check 'git status' output before running repoman commit and/or git
> commit.  It's probably best to check before you start on a change, and
> then you can 'git stash -u' right away (the -u includes untracked
> files, which is useful if your in progress change is adding something
> new), and then after you've committed the change you wanted to get
> done right away, you can 'git stash pop' to get back to the state you
> were in before.
> 

A maintainer/committer directed email would definitely help with this,
yes; otherwise maybe an RSS feed we could subscribe to would be more
fitting than list emails?

The problem was definitely me, however i'm not sure what I messed up
in this particular case.  What I had done was 'git reset *' and 'git
checkout -- *' within sys-cluster/torque/ to trash all of the
non-committed work.  I'll definitely be more careful in the future.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tinfo flag

[Ian Stakenvicius]

On 07/12/16 05:40 AM, konsolebox wrote:
> On Wed, Dec 7, 2016 at 5:16 PM, Michał Górny  wrote:
>> On Wed, 7 Dec 2016 16:16:45 +0800
>> konsolebox  wrote:
>>
>>> On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny  wrote:
 On Tue, 6 Dec 2016 20:11:34 -0600
 William Hubbs  wrote:

> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote:
>> On Tue, Dec 6, 2016 at 4:15 PM, Michał Górny  wrote:
>>> On Tue, 6 Dec 2016 12:54:26 -0500
>>> Mike Gilbert  wrote:
>>>
 On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  
 wrote:
> Please consider promoting the use of tinfo flag in packages that
> depend on sys-libs/ncurses so that they would synchronize properly
> with sys-libs/ncurses[tinfo].

 I would rather see the tinfo USE flag removed from ncurses.
>>>
>>> vapier doesn't consider this QA violation a QA violation.
>>>
>>> https://bugs.gentoo.org/487844
>>
>> Perhaps QA could take some action then?
>>
>> Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor 
>> solution.
>
> 
> Our policies are in the dev manual, so please cite the violation there.
> If you can't, this is not a qa violation, so please don't call it one.
> 
>
> I don't see a problem with the use flag and suggest updating the other 
> ebuilds.

 The flag randomly changes ABI, breaking all reverse dependencies.
 Please tell me this is a good practice.
>>>
>>> And there you had just proven that the ncurses package is installed in
>>> two modes, showing that a flag like tinfo is needed to represent them.
>>> It's not the ncurses package's fault.  It's the depending packages'
>>> responsibility to properly adapt to it.
>>
>> Packages are not intelligent beings, so they can't have responsibility.
> 
> Of course.
> 
>> Package maintainers have. You can't expect people to spend a lot of
>> time updating a lot of packages every time a new ABI-breaking flag is
>> suddenly introduced in a core package, if it's not even clear if it
>> going to stay long-term.
> 
> So you're suggesting to wait and keep things [partly] broken until
> then.  Why not fix things first then remove the [-tinfo] feature when
> everything no longer needs it instead.  This is even just a one-time
> solution, and is not much different with the massive number of
> pkg-config patches currently being implemented among ebuilds.  (Again,
> I'm not exactly liking the use of pkg-config.   I'd rather have a
> simple export since it's good enough, easier to implement, less
> compromising with the source, and is more universal.)
> 

Here's the thing -- ncurses provides all functionality regardless of
whether it's split into two libs (libncurses+libtinfo) or not.  So
what this flag is really doing is providing the capability of linking
to just part of ncurses instead of all of it, if a project desires.
And projects(binary ones at that) are doing this, which is why we have
some deps that require the tinfo flag to be enabled currently.

There is only one instance of a dependency atom that requires the
tinfo flag to be disabled, and that package is an old game whos build
system and ebuild is flawed in this regard.  All others are fine with
the flag being enabled so far as I can tell (and if they're not then
it's a bug that needs to be addressed anyhow).

SO, in summary, it would seem to make sense (since anything prebuilt
will work as-is, and anything compiled will be built to work with it)
to remove the tinfo flag but force libtinfo to be built and installed
-- simply make it non-optional.  Additionally, we can set
SLOT="0/6tinfo" which will trigger subslot rebuilds to ensure anything
that may need to be rebuilt to link to both libncurses and libtinfo
will be rebuilt when the tinfo-IUSE-less version gets installed.

We not only have a solution that'll address the
ABI-break-on-USE-change issue, but also a migration path that will be
transparent to users via a -uDN @world.  I call that a win-win.  The
only thing we lose is the easy ability to build an all-in-one
libncurses.  So if there is an actual need for that which we have yet
to find, this is an official request for comments to let us know.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tinfo flag

[Ian Stakenvicius]

On 05/12/16 06:13 AM, konsolebox wrote:
> Hi,
> 
> Please consider promoting the use of tinfo flag in packages that
> depend on sys-libs/ncurses so that they would synchronize properly
> with sys-libs/ncurses[tinfo].
> 
> It could be as simple as:
> 
> IUSE="tinfo"
> 
> RDEPEND="sys-libs/ncurses[tinfo=]"
> 
> pkg_setup() {
> use tinfo && export LDFLAGS="-ltinfo ${LDFLAGS}" LIBS="-ltinfo ${LIBS}"
> }
> 
> The last line can be changed/enhanced, depending on the package.
> 
> It helps keep binaries consistent even if sys-libs/ncurses[-tinfo]
> gets recompiled to sys-libs/ncurses[tinfo], because they are forced to
> be recompiled.  This is better than hard-coded dynamic workarounds.
> 

Should this message perhaps have been directed to a particular set of
developers or package maintainers rather than everyone on this list?

I'm not sure what our stance is on propagating USE flags to rdeps when
the package itself doesn't care (except due to the --libs output
changing from pkg-config).  I feel that adding tinfo to IUSE the way
it's suggested here might be the only technical solution right now,
but at the same time it seems like something that might be better
suited to something that should be addressed through other mechanisms
in a future-EAPI...

Note in particular though that the pkg_setup example ISN'T imo a good
idea -- rather, pkg-config should be used, as it will return the
appropriate --libs output whether ncurses is built with USE=tinfo
enabled or not.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

[Ian Stakenvicius]

> On Dec 5, 2016, at 5:01 AM, Ciaran McCreesh  
> wrote:
> 
> On Sun, 4 Dec 2016 18:47:48 -0800
> Daniel Campbell  wrote:
>> Compliance with what? If others desire Quickbook support, they can
>> make a tool to convert from ledger. There's no good reason for a
>> non-profit, libre software organization to use and depend on
>> proprietary software. Did nobody learn a lesson from BitKeeper?
> 
> Have you checked that the people hosting Gentoo's infrastructure don't
> use any proprietary software anywhere inside their building either? Most
> cleaning companies use a closed source staff scheduling program. It
> would be a terrible violation of the social contract if Gentoo depended
> upon that.
> 

Fortunately Gentoo does not require any cleanliness standards be met at all.  
Otherwise I couldn't be a dev. :P

That is a fairly important distinction here, I think.  If we start using or 
relying on Quickbooks then we are locking into that proprietary 
platform--getting all the historical financials out of Quickbooks and into 
another tool is intentionally hard (I assume--I know it's near impossible with 
Sage).  We are not requiring or accountant to use open tools though, if they 
want to import our data into Quickbooks to do their work, that's up to them, as 
long as we still have the result we need from them.

Re: [gentoo-dev] Uppercase characters in package names

[Ian Stakenvicius]

On 02/12/16 01:31 PM, Ciaran McCreesh wrote:
> On Fri, 2 Dec 2016 13:24:29 -0500
> Mike Gilbert  wrote:
>> On Fri, Dec 2, 2016 at 1:10 PM, Ciaran McCreesh
>>  wrote:
>>> On Fri, 2 Dec 2016 13:02:48 -0500
>>> Mike Gilbert  wrote:  
 The devmanual states:

 The name section should contain only lowercase non-accented
 letters, the digits 0-9, hyphens, underscores and plus characters.
 Uppercase characters are strongly discouraged, but technically
 valid.

 https://devmanual.gentoo.org/ebuild-writing/file-format/index.html


 Why are uppercase characters strongly discouraged?

 Wouldn't it make sense to follow upstream's naming convention?  
>>>
>>> What's upstream's naming convention for Firefox?
>>
>> I have no idea. What's your point?
> 
> That naming conventions are generally complicated and a mess, and that
> no-one wants to have to remember whether it's firefox, Firefox, or
> FireFox.
> 

It's also more convenient at the consone to just type everything
lowercase.  I expect that's the primary reason it's discouraged.






signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Revision bumps vs git commits atomicity

[Ian Stakenvicius]

On 02/12/16 10:32 AM, Dirkjan Ochtman wrote:
> On Fri, Dec 2, 2016 at 4:14 PM, Andrew Savchenko  wrote:
>> What about the following forkflow:
>> - version bump first with minimal changes required, but without
>> pushing commit to the tree;
>> - make each logical change as a separate commit without revision
>> bumps and without pushing stuff to the tree (of course repoman
>> scan/full is required as usual for each commit);
>> - well test package after the last commit (that it builds with
>> various USE flag combinations, old and new functionality works fine
>> and so on);
>> - fix any problems found and only afterwards push changes to the
>> tree.
>>
>> This way users will see only foo-1.0 -> foo-1.1 change in the tree,
>> while git will still retain each logical change as a separate
>> commit, which will make future maintenance and debugging much
>> easier.
>>
>> Of course a separate git branch may be used as well, but using
>> branches for each half-a-dozen set of commits looks like an
>> overkill to me.
>>
>> Thoughts, comments?
> 
> Sounds sensible to me, possibly to the point of not having to spell it
> out? (As in, I don't see the mentioned policies as necessarily
> conflicting.)
> 
> Cheers,
> 
> Dirkjan
> 

If it matters, it may make sense to adhere to the order of operations
presented above more precisely.  For instance, I tend to do all of the
minor changes first and then revbump the ebuild (usually because I'm
adjusting these changes over a few days and then evaluate if it needs
a revbump once it's done).




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 17/11/16 03:50 PM, Michał Górny wrote:
> On Thu, 17 Nov 2016 15:07:32 -0500
> Ian Stakenvicius <a...@gentoo.org> wrote:
>>
>> OpenRC's init scripts all do that already, more or less.  tmpfiles.d
>> *.conf files are not used for this purpose -- definitely not by
>> OpenRC, and most likely also not by upstream packages.
> 
> So do you expect all eix users to have to run an init script for eix to
> be able to use it?
> 

They already do -- said init script is called tmpfiles.setup and as
you already know it's a requirement due to /var/cache/eix needing to
be portage:portage and exist despite there not being a guarantee of
/var/cache being preserved.


>>> The whole point of the eclass is to provide a reasonable way to combine
>>> both without having to do the same thing twice. That is, create
>>> the directory in postinst and install a tmpfiles.d entry to make it
>>> possible to recreate it on boot.  
>>
>> I thought the reason for the eclass was so that when a package is
>> installed, you don't need to reboot or otherwise trigger manually your
>> system's tmpfiles.d processing to have it do the first-run process
>> with the new *.conf file?
> 
> Yes. That is, to have the temporary directories/files created and/or
> permissions set without having to reboot your system. Or to do that
> manually in the ebuild, when you're already installing a well-defined
> file that explains how to do that.

Right -- I presume that said file is usually being provided by
upstream, rather than the package maintainer, though?  Because there
should be very few instances so far as I know that gentoo dev's would
need to create tmpfiles.d *.conf files as part of their packaging efforts.


>>> If someone is not using OpenRC or systemd, he doesn't need tmpfiles.d
>>> implementation more than to run postinst.   
>>
>> Sure he does.  eix needs it to ensure files exist in /var/cache/ , for
>> instance.  dhcpd needs it to ensure /var/lib/dhcpd/dhcpd.leases exists
>> and has the correct permissions.  Neither of those has got anything to
>> do with openrc's needs at boot time.  Whether it's openrc or a fork of
>> upstart or some strange busybox-only script or whatever init/rc system
>> that's used, opentmpfiles provides the capability of processing these
>> tmpfiles.d *.conf files and can be triggered at boot time to do it (or
>> via cron, or with it being started as a daemon maybe later I presume)
> 
> You're missing the point. A purely minimal OpenRC-free system with no
> volatile filesystems doesn't require any specific action at boot. It's
> perfectly happy with the directories created by ebuild. Why would you
> require the user of that system to install a tool he won't be using
> anyway?

When you say 'volatile filesystems' I assume then you're ignoring FHS
paths where there are no persistence guarantees?  Just because there's
no tmpfs doesn't mean there's no volatility..


> 
>>> After postinst, the directory
>>> is created and the user is happy. However, if he uses OpenRC, then
>>> OpenRC will make sure the directory disappears on next boot.
>>>
>>> So why should ebuild add dependencies to solve a limitation caused by
>>> OpenRC?  
>>
>> This would be because opentmpfiles is its own project now rather than
>> something shipped as part of (or even needed by) openrc.  And so, it's
>> now a runtime dep *when and only when* not processing the tmpfiles.d
>> *.conf file is going to make the package fail at runtime, internally
>> and intrinsically to the package itself (not to its init script or any
>> other init/rc related thing).
> 
> Are you going to expect all packages with init scripts to depend
> on OpenRC now, because your common-assumed use case requires the init
> script to do something? Should we also make them depend on systemd at
> the same time for completeness? And possibly on bash, vim, etc. so that
> all those extra files get really used.
> 

No.  That would be unnecessary as there is, afaik, the requirement of
SOME sort of init or rc system in @system already right?

The thing is, in THIS case, OpenRC upstream is washing their hands of
it.  Which means, its up to the new package that actually -does- the
processing to install an init script that calls itself (which makes
sense) if openrc is booted.  All fine and dandy except:

#1, we should have something other than the end-user's @world to make
sure this is installed (hence RDEPEND on it in packages that need it
to be run) because openrc isn't apparently going to depend on it,

#2 we need to somehow reconcile the fact that if systemd is installed
despite openrc being booted, there still won't be any init scripts
because the virt

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 17/11/16 02:42 PM, Michał Górny wrote:
> On Thu, 17 Nov 2016 14:10:28 -0500
> Ian Stakenvicius <a...@gentoo.org> wrote:
> 
>> On 17/11/16 01:49 PM, Michał Górny wrote:
>>> On Thu, 17 Nov 2016 19:46:41 +0100
>>> Michał Górny <mgo...@gentoo.org> wrote:
>>>   
>>>> On Thu, 17 Nov 2016 10:02:25 -0500
>>>> Ian Stakenvicius <a...@gentoo.org> wrote:
>>>>  
>>>>> On 17/11/16 01:03 AM, Michał Górny wrote:
>>>>>> On Wed, 16 Nov 2016 14:21:41 -0600
>>>>>> William Hubbs <willi...@gentoo.org> wrote:
>>>>>>   
>>>>>>> On Wed, Nov 16, 2016 at 01:04:11PM -0500, Ian Stakenvicius wrote:  
>>>>>>>> On 16/11/16 12:03 PM, William Hubbs wrote:
>>>>>>>>> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote: 
>>>>>>>>>
>>>>>>>>>> On 16/11/16 10:08 AM, William Hubbs wrote:
>>>>>>>>>>> opentmpfiles will be updated to install the service scripts which
>>>>>>>>>>> will be run when OpenRC boots a system. There is nothing for
>>>>>>>>>>> it to do if systemd is used to boot the system.
>>>>>>>>>>>
>>>>>>>>>>> William
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But there is something to do if openrc is used to boot the system and
>>>>>>>>>> systemd is the package providing tmpfiles.d processing via the 
>>>>>>>>>> virtual.
>>>>>>>>>
>>>>>>>>> The providers (opentmpfiles and systemd) will not block each other, so
>>>>>>>>> the only way this will happen is if you have openrc and systemd
>>>>>>>>> installed then forcefully remove opentmpfiles. I think you would not
>>>>>>>>> want to do that until you are ready to migrate to booting with 
>>>>>>>>> systemd.
>>>>>>>>>
>>>>>>>>> William
>>>>>>>>> 
>>>>>>>>
>>>>>>>> I think I'm having a hard time getting across the issue here...:
>>>>>>>>
>>>>>>>> 1 - we will have a virtual/tmpfiles that will bring in EITHER systemd,
>>>>>>>> or opentmpfiles.
>>>>>>>>
>>>>>>>> 2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles)
>>>>>>>>
>>>>>>>> 3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will
>>>>>>>> need to depend on virtual/tmpfiles in order to make sure that the
>>>>>>>> system has something installed that will process them at boot-time.
>>>>>>>> 
>>>>>>>  
>>>>>>>  Yes, this will be handled by an RDEPEND in the eclass.  
>>>>>>
>>>>>> This is a wrong presumption. The eclass needs the virtual only for
>>>>>> pkg_postinst(). While RDEPEND is how we solve this now, it will no
>>>>>> longer be necessary in a future EAPI.
>>>>>>   
>>>>>
>>>>> This makes sense to me as well -- which means every package that
>>>>> installs tmpfiles.d/ files should properly RDEPEND on the virtual on
>>>>> its own when the functionality arisen from those tmpfiles.d files is
>>>>> non-optional.
>>>>
>>>> No, that's now what I meant.
>>>>
>>>> The eclass needs the virtual to create temporary directories once,
>>>> in pkg_postinst(). Period. That's how far it is concerned.
>>>>
>>>> If user wants to use a volatile filesystem or any other more complete
>>>> tmpfiles.d processing, he needs to use a init that supports that. Which
>>>> means either OpenRC with tmpfiles or systemd. Ebuild has nothing to do
>>>> with this.  
>>>
>>> One more thing. I still believe openrc should RDEP on tmpfiles by
>>> default since openrc is mounting a few standard locations
>>> (like /var/run) as tmpfs by default.
>>>   
>>
>> OpenRC isn't using tmpfiles.d *.conf files to do that (although it
>> could).  I didn't realize t

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 17/11/16 01:49 PM, Michał Górny wrote:
> On Thu, 17 Nov 2016 19:46:41 +0100
> Michał Górny <mgo...@gentoo.org> wrote:
> 
>> On Thu, 17 Nov 2016 10:02:25 -0500
>> Ian Stakenvicius <a...@gentoo.org> wrote:
>>
>>> On 17/11/16 01:03 AM, Michał Górny wrote:  
>>>> On Wed, 16 Nov 2016 14:21:41 -0600
>>>> William Hubbs <willi...@gentoo.org> wrote:
>>>> 
>>>>> On Wed, Nov 16, 2016 at 01:04:11PM -0500, Ian Stakenvicius wrote:
>>>>>> On 16/11/16 12:03 PM, William Hubbs wrote:  
>>>>>>> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote:  
>>>>>>>> On 16/11/16 10:08 AM, William Hubbs wrote:  
>>>>>>>>> opentmpfiles will be updated to install the service scripts which
>>>>>>>>> will be run when OpenRC boots a system. There is nothing for
>>>>>>>>> it to do if systemd is used to boot the system.
>>>>>>>>>
>>>>>>>>> William
>>>>>>>>>  
>>>>>>>>
>>>>>>>> But there is something to do if openrc is used to boot the system and
>>>>>>>> systemd is the package providing tmpfiles.d processing via the 
>>>>>>>> virtual.  
>>>>>>>
>>>>>>> The providers (opentmpfiles and systemd) will not block each other, so
>>>>>>> the only way this will happen is if you have openrc and systemd
>>>>>>> installed then forcefully remove opentmpfiles. I think you would not
>>>>>>> want to do that until you are ready to migrate to booting with systemd.
>>>>>>>
>>>>>>> William
>>>>>>>   
>>>>>>
>>>>>> I think I'm having a hard time getting across the issue here...:
>>>>>>
>>>>>> 1 - we will have a virtual/tmpfiles that will bring in EITHER systemd,
>>>>>> or opentmpfiles.
>>>>>>
>>>>>> 2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles)
>>>>>>
>>>>>> 3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will
>>>>>> need to depend on virtual/tmpfiles in order to make sure that the
>>>>>> system has something installed that will process them at boot-time.  
>>>>>  
>>>>>  Yes, this will be handled by an RDEPEND in the eclass.
>>>>
>>>> This is a wrong presumption. The eclass needs the virtual only for
>>>> pkg_postinst(). While RDEPEND is how we solve this now, it will no
>>>> longer be necessary in a future EAPI.
>>>> 
>>>
>>> This makes sense to me as well -- which means every package that
>>> installs tmpfiles.d/ files should properly RDEPEND on the virtual on
>>> its own when the functionality arisen from those tmpfiles.d files is
>>> non-optional.  
>>
>> No, that's now what I meant.
>>
>> The eclass needs the virtual to create temporary directories once,
>> in pkg_postinst(). Period. That's how far it is concerned.
>>
>> If user wants to use a volatile filesystem or any other more complete
>> tmpfiles.d processing, he needs to use a init that supports that. Which
>> means either OpenRC with tmpfiles or systemd. Ebuild has nothing to do
>> with this.
> 
> One more thing. I still believe openrc should RDEP on tmpfiles by
> default since openrc is mounting a few standard locations
> (like /var/run) as tmpfs by default.
> 

OpenRC isn't using tmpfiles.d *.conf files to do that (although it
could).  I didn't realize tmpfiles.d processing had any direct
relationship or association with tmpfs mounts though (other than it
helps solve the issue of files and dirs disappearing after reboots, of
course).

Part of the point of the virtual (and the reason for the init script
arguments in this thread) is that it makes this functionality not tied
to an init/rc system anymore -- that is:

- systemd will just do it, if its used as init
- systemd if installed can be used to do it from openrc/other-init
- opentmpfiles can be used to do it from openrc/other-init

The part where I see the ebuild coming into play here is for all of
the packages that currently install .conf files into
/usr/lib/tmpfiles.d/ (like apache, libvirt, etc. etc).  If those
packages are doing so explicitly because they non-optionally expect
systemd-tmpfilesd or opentmpfiles to do what's been specified (and
will fail otherwise), then this is an actual RDEPEND for those
packages whether they use the eclass or not.

You are right, though -- we avoid a whole bunch of this if openrc just
RDEPENDs on the virtual and all other packages just assume there is
support for tmpfiles.d processing in whatever init/rc system is used.
However that seems to not be where things are going (at least from
WilliamH's perspective)






signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 17/11/16 12:22 PM, William Hubbs wrote:
> On Thu, Nov 17, 2016 at 10:02:25AM -0500, Ian Stakenvicius wrote:
>> On 17/11/16 01:03 AM, Michał Górny wrote:
>>> On Wed, 16 Nov 2016 14:21:41 -0600
>>> William Hubbs <willi...@gentoo.org> wrote:
>>>
>>>> On Wed, Nov 16, 2016 at 01:04:11PM -0500, Ian Stakenvicius wrote:
>>>>> On 16/11/16 12:03 PM, William Hubbs wrote:  
>>>>>> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote:  
>>>>>>> On 16/11/16 10:08 AM, William Hubbs wrote:  
>>>>>>>> opentmpfiles will be updated to install the service scripts which
>>>>>>>> will be run when OpenRC boots a system. There is nothing for
>>>>>>>> it to do if systemd is used to boot the system.
>>>>>>>>
>>>>>>>> William
>>>>>>>>  
>>>>>>>
>>>>>>> But there is something to do if openrc is used to boot the system and
>>>>>>> systemd is the package providing tmpfiles.d processing via the virtual. 
>>>>>>>  
>>>>>>
>>>>>> The providers (opentmpfiles and systemd) will not block each other, so
>>>>>> the only way this will happen is if you have openrc and systemd
>>>>>> installed then forcefully remove opentmpfiles. I think you would not
>>>>>> want to do that until you are ready to migrate to booting with systemd.
>>>>>>
>>>>>> William
>>>>>>   
>>>>>
>>>>> I think I'm having a hard time getting across the issue here...:
>>>>>
>>>>> 1 - we will have a virtual/tmpfiles that will bring in EITHER systemd,
>>>>> or opentmpfiles.
>>>>>
>>>>> 2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles)
>>>>>
>>>>> 3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will
>>>>> need to depend on virtual/tmpfiles in order to make sure that the
>>>>> system has something installed that will process them at boot-time.  
>>>>  
>>>>  Yes, this will be handled by an RDEPEND in the eclass.
>>>
>>> This is a wrong presumption. The eclass needs the virtual only for
>>> pkg_postinst(). While RDEPEND is how we solve this now, it will no
>>> longer be necessary in a future EAPI.
>>>
>>
>> This makes sense to me as well -- which means every package that
>> installs tmpfiles.d/ files should properly RDEPEND on the virtual on
>> its own when the functionality arisen from those tmpfiles.d files is
>> non-optional.
> 
> Doesn't that bring into question the need of RDEPEND in the
> eclass itself since it doesn't have a pkg_postinst function? I could
> remove the rdepend from the eclass and add the following to the
> documentation of the tmpfiles_process function:
> 
> # Warning: Be sure that you rdepend on virtual/tmpfiles if you use this
> # function in your ebuild.
> 
> William
> 

No I don't think so.  The eclass uses these tmpfiles.d-processing
commands in order to do its work, so therefore it needs to make sure
the tools are there.  As mgorny said earlier this RIGHT NOW means
putting it in RDEPEND, but in a Future-EAPI it won't be RDEPEND but
instead some other *DEPEND.

Likewise, I don't think it's pertinent to inherit the eclass in order
to ensure system runtime support of tmpfiles.d processing -- there's
nothing to say that the eclass won't disappear in a year or two after
all (because, say, the tmpfiles.d daemon starts using inotify and
instantly processes any newly installed files, hypothetically)





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 17/11/16 01:03 AM, Michał Górny wrote:
> On Wed, 16 Nov 2016 14:21:41 -0600
> William Hubbs <willi...@gentoo.org> wrote:
> 
>> On Wed, Nov 16, 2016 at 01:04:11PM -0500, Ian Stakenvicius wrote:
>>> On 16/11/16 12:03 PM, William Hubbs wrote:  
>>>> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote:  
>>>>> On 16/11/16 10:08 AM, William Hubbs wrote:  
>>>>>> opentmpfiles will be updated to install the service scripts which
>>>>>> will be run when OpenRC boots a system. There is nothing for
>>>>>> it to do if systemd is used to boot the system.
>>>>>>
>>>>>> William
>>>>>>  
>>>>>
>>>>> But there is something to do if openrc is used to boot the system and
>>>>> systemd is the package providing tmpfiles.d processing via the virtual.  
>>>>
>>>> The providers (opentmpfiles and systemd) will not block each other, so
>>>> the only way this will happen is if you have openrc and systemd
>>>> installed then forcefully remove opentmpfiles. I think you would not
>>>> want to do that until you are ready to migrate to booting with systemd.
>>>>
>>>> William
>>>>   
>>>
>>> I think I'm having a hard time getting across the issue here...:
>>>
>>> 1 - we will have a virtual/tmpfiles that will bring in EITHER systemd,
>>> or opentmpfiles.
>>>
>>> 2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles)
>>>
>>> 3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will
>>> need to depend on virtual/tmpfiles in order to make sure that the
>>> system has something installed that will process them at boot-time.  
>>  
>>  Yes, this will be handled by an RDEPEND in the eclass.
> 
> This is a wrong presumption. The eclass needs the virtual only for
> pkg_postinst(). While RDEPEND is how we solve this now, it will no
> longer be necessary in a future EAPI.
> 

This makes sense to me as well -- which means every package that
installs tmpfiles.d/ files should properly RDEPEND on the virtual on
its own when the functionality arisen from those tmpfiles.d files is
non-optional.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 16/11/16 09:19 PM, Mike Gilbert wrote:
> On Wed, Nov 16, 2016 at 8:41 PM, Rich Freeman <ri...@gentoo.org> wrote:
>> On Wed, Nov 16, 2016 at 6:45 PM, Ian Stakenvicius <a...@gentoo.org> wrote:
>>> On 16/11/16 06:25 PM, William Hubbs wrote:
>>>> On Wed, Nov 16, 2016 at 06:19:28PM -0500, Ian Stakenvicius wrote:
>>>>> > [...]
>>>>> Then we're back to the exact same issue.  opentmpfiles won't be
>>>>> installed if systemd is installed, so the scripts won't get installed.
>>>>
>>>>  Why not? we can just add opentmpfiles to the pdepend of systemd the
>>>>  same way udev-init-scripts is.
>>>
>>> Wait, so you're going to require systemd have a PDEPEND on
>>> opentmpfiles, so that OpenRC doesn't need to have one, when it's
>>> openrc that needs the script files that opentmpfiles installs??
>>>
>>
>> I agree, this doesn't make sense.
>>
>> If systemd-tmpfiles can work when systemd isn't running I could see an
>> argument for having systemd install init.d scripts to run it (it seems
>> strange, but it wouldn't be so strange if it weren't bundled).  Of
>> course you still run into a collision with opentmpfiles if both are
>> installed at once, unless they use different script, or the init.d
>> scripts can run either and are installed in a split package.
> 
> Either of these options seem reasonable to me.
> 
> It's possible (though unlikely) that someone would install systemd
> simply for unadulterated udev and tmpfiles support. I'm happy to
> install init scripts to support that.
> 

Unfortunately, I think the best means of handling this would still be
an init-scripts package the same as we do for udev, that both systemd
and opentmpfiles would depend on -- the sole reason being, that this
package could easily the appropriate scripts to the boot and sysinit
runlevels when installed, and that may prove difficult to sort out via
openrc virtual services.

tmpfiles.setup is easy enough to do via 'need' or 'want' in depend
sections, but tmpfiles.dev has to have a 'before dev', which means
sysinit, and I'm not sure if a service in 'default' can trigger
something to be started in sysinit via a 'need' or 'want' dep.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 16/11/16 06:25 PM, William Hubbs wrote:
> On Wed, Nov 16, 2016 at 06:19:28PM -0500, Ian Stakenvicius wrote:
>> On 16/11/16 06:16 PM, William Hubbs wrote:
>>> On Wed, Nov 16, 2016 at 06:09:59PM -0500, Ian Stakenvicius wrote:
>>>> On 16/11/16 03:21 PM, William Hubbs wrote:
>>>>>
>>>>> I can make the service scripts call the systemd-tmpfiles service if it
>>>>> is available or if not call the opentmpfiles implementation.
>>>>>
>>>>> I'm not sure whether it is worth having a separate package for the
>>>>> service scripts in this case.
>>>>
>>>> That would depend on where the service scripts are sitting, I guess --
>>>> do you mean here that openrc will keep its current tmpfiles.dev and
>>>> tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
>>>> RDEPEND or PDEPEND on virtual/tmpfiles ?
>>>
>>> No, those scripts will be removed from OpenRC. If you grep through
>>> OpenRC, you will see that once they are removed, they are never actually
>>> referred to by any other services that are part of OpenRC.
>>>
>>> The scripts will be put in opentmpfiles and that ebuild will install
>>> them.
>>>
>>> William
>>>
>>
>> Then we're back to the exact same issue.  opentmpfiles won't be
>> installed if systemd is installed, so the scripts won't get installed.
>  
>  Why not? we can just add opentmpfiles to the pdepend of systemd the
>  same way udev-init-scripts is.
> 
>  William
> 

Wait, so you're going to require systemd have a PDEPEND on
opentmpfiles, so that OpenRC doesn't need to have one, when it's
openrc that needs the script files that opentmpfiles installs??




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 16/11/16 06:16 PM, William Hubbs wrote:
> On Wed, Nov 16, 2016 at 06:09:59PM -0500, Ian Stakenvicius wrote:
>> On 16/11/16 03:21 PM, William Hubbs wrote:
>>>
>>> I can make the service scripts call the systemd-tmpfiles service if it
>>> is available or if not call the opentmpfiles implementation.
>>>
>>> I'm not sure whether it is worth having a separate package for the
>>> service scripts in this case.
>>
>> That would depend on where the service scripts are sitting, I guess --
>> do you mean here that openrc will keep its current tmpfiles.dev and
>> tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
>> RDEPEND or PDEPEND on virtual/tmpfiles ?
> 
> No, those scripts will be removed from OpenRC. If you grep through
> OpenRC, you will see that once they are removed, they are never actually
> referred to by any other services that are part of OpenRC.
> 
> The scripts will be put in opentmpfiles and that ebuild will install
> them.
> 
> William
> 

Then we're back to the exact same issue.  opentmpfiles won't be
installed if systemd is installed, so the scripts won't get installed.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 16/11/16 03:21 PM, William Hubbs wrote:
> 
> I can make the service scripts call the systemd-tmpfiles service if it
> is available or if not call the opentmpfiles implementation.
> 
> I'm not sure whether it is worth having a separate package for the
> service scripts in this case.

That would depend on where the service scripts are sitting, I guess --
do you mean here that openrc will keep its current tmpfiles.dev and
tmpfiles.setup scripts?  If that's the case wouldn't openrc need to
RDEPEND or PDEPEND on virtual/tmpfiles ?







signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 16/11/16 12:03 PM, William Hubbs wrote:
> On Wed, Nov 16, 2016 at 10:14:02AM -0500, Ian Stakenvicius wrote:
>> On 16/11/16 10:08 AM, William Hubbs wrote:
>>> opentmpfiles will be updated to install the service scripts which
>>> will be run when OpenRC boots a system. There is nothing for
>>> it to do if systemd is used to boot the system.
>>>
>>> William
>>>
>>
>> But there is something to do if openrc is used to boot the system and
>> systemd is the package providing tmpfiles.d processing via the virtual.
> 
> The providers (opentmpfiles and systemd) will not block each other, so
> the only way this will happen is if you have openrc and systemd
> installed then forcefully remove opentmpfiles. I think you would not
> want to do that until you are ready to migrate to booting with systemd.
> 
> William
> 

I think I'm having a hard time getting across the issue here...:

1 - we will have a virtual/tmpfiles that will bring in EITHER systemd,
or opentmpfiles.

2 - openrc will NOT depend on opentmpfiles (nor virtual/tmpfiles)

3 - Applications that install stuff into /usr/lib/tmpfiles.d/ will
need to depend on virtual/tmpfiles in order to make sure that the
system has something installed that will process them at boot-time.

GIVEN THIS, if a system has both systemd and openrc installed (that
is, they dual-boot), then virtual/tmpfiles will NOT bring in
opentmpfiles, and so if opentmpfiles is the only package that installs
init scripts then openrc won't trigger any processing of
/usr/lib/tmpfiles.d/* at bootup in this situation.

Just because systemd is installed doesn't mean it's the actual init in
use.  We deal with this with virtual/udev via udev-init-scripts, and
we will need -some sort- of similar situation here.  This case needs
to be addressed, and be done WITHOUT requiring the end-user to add
opentmpfiles to @world by hand.

I think, given the opentmpfiles and the systemd tmpfiles commands and
arguments can differ, it would likely make more sense to have a
virtual service in openrc (that is, keep tmpfiles.dev and
tmpfiles.setup as virtuals) and have opentmpfiles and systemd both
install init scripts for their respective implementation that will
provide each of those in openrc.  The alternative would be to make a
tmpfiles-init-scripts package that will contain a single set of
scripts that'll call either the opentmpfiles or the systemd-tmpfiles
implementation at runtime depending on what is available.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 16/11/16 10:08 AM, William Hubbs wrote:
> On Wed, Nov 16, 2016 at 08:57:57AM -0500, Ian Stakenvicius wrote:
>> On 15/11/16 02:56 PM, Mike Gilbert wrote:
>>> On Tue, Nov 15, 2016 at 2:51 PM, Ian Stakenvicius <a...@gentoo.org> wrote:
>>>> On 15/11/16 02:42 PM, Michał Górny wrote:
>>>>> On Tue, 15 Nov 2016 13:57:14 -0500
>>>>> Ian Stakenvicius <a...@gentoo.org> wrote:
>>>>>
>>>>>> On 15/11/16 12:56 PM, William Hubbs wrote:
>>>>>>> OpenRC itself doesn't install any tmpfiles.d files, and my plan is to
>>>>>>> make sure virtual/tmpfiles and opentmpfiles go stable at the same time
>>>>>>> the new OpenRC does, along with at least one package that uses them.
>>>>>>>
>>>>>>> This will also definitely be covered in the upstream OpenRC news.
>>>>>>>
>>>>>>> WRT OpenRC pulling it in, it isn't a build or runtime dependency of
>>>>>>> OpenRC, and it may not even be needed in some cases, so I'm not sure how
>>>>>>> much sense it makes from the OpenRC level to pull it in or which type of
>>>>>>> dependency to use for it.
>>>>>>
>>>>>> I'm with William on this.  As long as the packages that install items
>>>>>> (init scripts, whatever) that -do- need tmpfiles.d support depend on
>>>>>> virtual/tmpfilesd, this will ensure it's installed regardless of
>>>>>> whether or not openrc depends on the virtual directly.
>>>>>
>>>>> The ebuilds are going to only need a pkg_*-time dependency on the tool.
>>>>> While this means RDEPEND at the moment due to our dependency class
>>>>> limits, we may have a proper dependency type for it in EAPI 7. In this
>>>>> case, the PM will be allowed to unmerge opentmpfiles as soon
>>>>> as the package is installed.
>>>>>
>>>>
>>>> The EBUILDS, yes.
>>>>
>>>> This tool isn't just for ebuilds though, it's also for managing
>>>> tmpfiles.d processing at boot time as well as (i assume) via
>>>> continuous daemon-like operation for the services that install files
>>>> into /usr/lib/tmpfiles.d/ (apache, libvirtd, lvm2, mysql, samba are
>>>> just a few that I have on my own system right now) when systemd isn't
>>>> installed.
>>>>
>>>> Or am I wrong on this?  It'd seem odd that we would go through this
>>>> just to make a tool for ebuilds to use, if non-systemd systems aren't
>>>> going to use it at boot time as well...
>>>
>>> Right; if the functionality is being stripped out of OpenRC, it will
>>> definitely need to remain installed and provide init.d scripts for
>>> processing at boot time.
>>>
>>
>> Right, so we're back to how will we deal with the init scripts for
>> openrc?  I agree that the virtual suffices, and that openrc doesn't
>> need tmpfiles.d processing and so likely shouldn't depend on the
>> virtual.  But the init scripts need to be there in some form or another.
> 
> opentmpfiles will be updated to install the service scripts which
> will be run when OpenRC boots a system. There is nothing for
> it to do if systemd is used to boot the system.
> 
> William
> 

But there is something to do if openrc is used to boot the system and
systemd is the package providing tmpfiles.d processing via the virtual.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 15/11/16 02:56 PM, Mike Gilbert wrote:
> On Tue, Nov 15, 2016 at 2:51 PM, Ian Stakenvicius <a...@gentoo.org> wrote:
>> On 15/11/16 02:42 PM, Michał Górny wrote:
>>> On Tue, 15 Nov 2016 13:57:14 -0500
>>> Ian Stakenvicius <a...@gentoo.org> wrote:
>>>
>>>> On 15/11/16 12:56 PM, William Hubbs wrote:
>>>>> OpenRC itself doesn't install any tmpfiles.d files, and my plan is to
>>>>> make sure virtual/tmpfiles and opentmpfiles go stable at the same time
>>>>> the new OpenRC does, along with at least one package that uses them.
>>>>>
>>>>> This will also definitely be covered in the upstream OpenRC news.
>>>>>
>>>>> WRT OpenRC pulling it in, it isn't a build or runtime dependency of
>>>>> OpenRC, and it may not even be needed in some cases, so I'm not sure how
>>>>> much sense it makes from the OpenRC level to pull it in or which type of
>>>>> dependency to use for it.
>>>>
>>>> I'm with William on this.  As long as the packages that install items
>>>> (init scripts, whatever) that -do- need tmpfiles.d support depend on
>>>> virtual/tmpfilesd, this will ensure it's installed regardless of
>>>> whether or not openrc depends on the virtual directly.
>>>
>>> The ebuilds are going to only need a pkg_*-time dependency on the tool.
>>> While this means RDEPEND at the moment due to our dependency class
>>> limits, we may have a proper dependency type for it in EAPI 7. In this
>>> case, the PM will be allowed to unmerge opentmpfiles as soon
>>> as the package is installed.
>>>
>>
>> The EBUILDS, yes.
>>
>> This tool isn't just for ebuilds though, it's also for managing
>> tmpfiles.d processing at boot time as well as (i assume) via
>> continuous daemon-like operation for the services that install files
>> into /usr/lib/tmpfiles.d/ (apache, libvirtd, lvm2, mysql, samba are
>> just a few that I have on my own system right now) when systemd isn't
>> installed.
>>
>> Or am I wrong on this?  It'd seem odd that we would go through this
>> just to make a tool for ebuilds to use, if non-systemd systems aren't
>> going to use it at boot time as well...
> 
> Right; if the functionality is being stripped out of OpenRC, it will
> definitely need to remain installed and provide init.d scripts for
> processing at boot time.
> 

Right, so we're back to how will we deal with the init scripts for
openrc?  I agree that the virtual suffices, and that openrc doesn't
need tmpfiles.d processing and so likely shouldn't depend on the
virtual.  But the init scripts need to be there in some form or another.

Can we make the virtual install the init.d scripts?  I know it's not a
true virtual in that case but still..

Or will opentmpfiles install the current set of scripts while systemd
will install a systemd-specific set of scripts for openrc to use?
That could work, and likely makes sense as the calling commands and
possibly arguments will differ...





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 15/11/16 02:42 PM, Michał Górny wrote:
> On Tue, 15 Nov 2016 13:57:14 -0500
> Ian Stakenvicius <a...@gentoo.org> wrote:
> 
>> On 15/11/16 12:56 PM, William Hubbs wrote:
>>> OpenRC itself doesn't install any tmpfiles.d files, and my plan is to
>>> make sure virtual/tmpfiles and opentmpfiles go stable at the same time
>>> the new OpenRC does, along with at least one package that uses them.
>>>
>>> This will also definitely be covered in the upstream OpenRC news.
>>>
>>> WRT OpenRC pulling it in, it isn't a build or runtime dependency of
>>> OpenRC, and it may not even be needed in some cases, so I'm not sure how
>>> much sense it makes from the OpenRC level to pull it in or which type of
>>> dependency to use for it.
>>
>> I'm with William on this.  As long as the packages that install items
>> (init scripts, whatever) that -do- need tmpfiles.d support depend on
>> virtual/tmpfilesd, this will ensure it's installed regardless of
>> whether or not openrc depends on the virtual directly.
> 
> The ebuilds are going to only need a pkg_*-time dependency on the tool.
> While this means RDEPEND at the moment due to our dependency class
> limits, we may have a proper dependency type for it in EAPI 7. In this
> case, the PM will be allowed to unmerge opentmpfiles as soon
> as the package is installed.
> 

The EBUILDS, yes.

This tool isn't just for ebuilds though, it's also for managing
tmpfiles.d processing at boot time as well as (i assume) via
continuous daemon-like operation for the services that install files
into /usr/lib/tmpfiles.d/ (apache, libvirtd, lvm2, mysql, samba are
just a few that I have on my own system right now) when systemd isn't
installed.

Or am I wrong on this?  It'd seem odd that we would go through this
just to make a tool for ebuilds to use, if non-systemd systems aren't
going to use it at boot time as well...




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tmpfiles virtual

[Ian Stakenvicius]

On 15/11/16 12:56 PM, William Hubbs wrote:
> On Tue, Nov 15, 2016 at 05:56:27PM +0100, Michał Górny wrote:
>> On Tue, 15 Nov 2016 09:49:22 -0600
>> "Dustin C. Hatch"  wrote:
>>
>>> On 2016-11-14 23:09, Michał Górny wrote:
 On Mon, 14 Nov 2016 18:23:10 -0600
 William Hubbs  wrote:
   
> Hi all,
>
> I have been working on splitting the tmpfiles functionality out of
> OpenRC [1], and I believe the new package is about to enter the tree.
>
> OpenRC itself doesn't need this package to boot since it doesn't use
> tmpfiles.d files, but other software does need it.
>
> This brings up a couple of questions.
>
> Since we now will have two different ways to process tmpfiles, is
> virtual/tmpfiles appropriate, with the default being opentmpfiles?  

 Yes. Virtual will allow us to control list of supported implementations
 easily. We can also use it to control different versions of tmpfiles
 format.
   
> Once opentmpfiles is in the tree and stable, should virtual/tmpfiles
> be added to @system, or should we have the packages that need it rdepend
> on it directly? I tend to lean toward the second option.  

 We will RDEPEND on it via tmpfiles.eclass. I think floppym has a draft
 somewhere. In case that draft uses DEPEND, it just occurred to me that
 we need RDEPEND for pkg_postinst().
   
>>>
>>> What about administrator-specified temporary files in /etc/tmpfiles.d?
>>> It would be rather unfortunate to have stuff suddenly stop working
>>> because an OpenRC got updated and stopped creating these temporary files.
>>
>> I'd say it would be reasonable for OpenRC to pull it in, since OpenRC
>> used to provide tmpfiles support for some time already.
> 
> OpenRC itself doesn't install any tmpfiles.d files, and my plan is to
> make sure virtual/tmpfiles and opentmpfiles go stable at the same time
> the new OpenRC does, along with at least one package that uses them.
> 
> This will also definitely be covered in the upstream OpenRC news.
> 
> WRT OpenRC pulling it in, it isn't a build or runtime dependency of
> OpenRC, and it may not even be needed in some cases, so I'm not sure how
> much sense it makes from the OpenRC level to pull it in or which type of
> dependency to use for it.
> 
> William
> 

I'm with William on this.  As long as the packages that install items
(init scripts, whatever) that -do- need tmpfiles.d support depend on
virtual/tmpfilesd, this will ensure it's installed regardless of
whether or not openrc depends on the virtual directly.

If end-users are deploying their own tmpfiles.d specifics despite
nothing else needing it, then yes there will be a potential conflict
there, but I think a news item on openrc should suffice for this.

This does however bring up a good question -- I assume that this new
package installs the tmpfiles.dev and tmpfiles.setup init scripts
correct?  Does that mean systemd will be adjusted to also install
these files, or are we going to have yet another package
(tmpfiles-init-scripts or some such) that will install them?  If we're
leaving the init scripts in openrc then openrc *should* RDEPEND on the
virtual.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Revisiting version-related tree policies

[Ian Stakenvicius]

On 03/11/16 01:20 PM, Rich Freeman wrote:
> On Thu, Nov 3, 2016 at 12:11 PM, Michał Górny  wrote:
>>
>> 1. Revision number must be no longer than :
>> 1a. to make <=X-r reliable,
>> 1b. to prevent pathological uses of revision as date.
>>
> 
> Let's just hope nobody starts using tex version numbering and so on.
> Dates might be used in cases where upstream doesn't publish sane
> revisions (in fact, texlive versions are dates, albeit at the year
> level).
> 
> I'm not saying this isn't a good idea, I just could see where it might
> crash into reality at some point.
> 

This is just the revision portion though, that's not part of the
version number from upstream.  IIRC, the revision is meant to only be
used for gentoo ebuild changes, isn't it?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Optimizing toe stepping

[Ian Stakenvicius]

> On Nov 3, 2016, at 8:21 AM, Jason A. Donenfeld  wrote:
> 
>> On Thu, Nov 3, 2016 at 1:15 PM, Nick Vinson  wrote:
>> Just doing that one little thing would have prevented or shutdown the
>> arguments I have seen.
> 
> Yes, obviously of course.
> 
> But sometimes it's just easier and quicker to meddle in somebody
> else's ebuild to improve a particular situation. The question is thus
> how do we make this permissible? My proposal is adding a metadata.xml
> tag -- .
> 
> Jason
> 

Although metadata.xml is one way to do this, since it is more of a social thing 
than a technical one I think it might be better to wikify it instead -- each 
dev can list their "please fix my package" preferences in a per package or per 
anything-with-them-as-maintainer spec in one location.

The previous round of this had a bunch of devs make comments to effect of its 
fine for any dev to commit changes as long as the committee takes 
responsibility for it, it'll take a bit of time but we can probably compile 
those from irc logs and -dev@ and start the list.  Thoughts?

Re: [gentoo-dev] newsitem: important fstab and localmount update, round 4

[Ian Stakenvicius]

On 01/11/16 05:31 PM, Ilya Tumaykin wrote:
> On Tuesday 01 November 2016 16:13:34 William Hubbs wrote:
>> Title: Inportant fstab and localmount update
> 
> 'iNportant'
> 

NIT:  There is also double-whitespace on paragraph 2, line 2:
"symbolic links  will"





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: important fstab and localmount update, round 3

[Ian Stakenvicius]

On 01/11/16 04:03 PM, Michał Górny wrote:
> On Tue, 1 Nov 2016 14:13:28 -0500
> William Hubbs  wrote:
> 
>> If "/dev/disk/by-*" source paths are used for mount points in
> 
> s/source/device/. Source sounds weird to me.

device path works, i used 'source' as in the mount source vs the mount
target.

> 
>> fstab, it is possible that those symbolic links  will not exist when
>> localmount starts and attempts to mount them.
>> To force the old behaviour, you can add rc_want="dev-settle" to
>> /etc/conf.d/localmount or add udev-settle to the sysinit runlevel.
> 
> I would move this to the end, to indicate this is not the recommended
> solution.
> 
>> The preferred solution is to convert fstab from using
> 
> s/preferred/recommended/
> 
>> "/dev/disk/by-*" to the LABEL=, UUID=, or PARTUUID= syntax. This syntax
>> is supported directly by both util-linux and busybox's mount commands and
>> has no dependency on any device manager. More information on this syntax
>> can be found in the fstab and mount man pages.
> 
> fstab(5), mount(1). It is common to use the (n) part when listing
> manpages.
> 

Agreed, thank you!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Problems and limitations of the current version dependency specs

[Ian Stakenvicius]

On 31/10/16 08:31 PM, Michał Górny wrote:
> Hello, everyone.
> 
> I would like to work on a major version depedencny specification
> improvements as part of the next EAPI. For this reason, I'd like to
> first gather some research on how developers are using the current
> system, what they find efficient and what they find cumbersome.
> 
> Therefore, I would like to ask the following questions:
> 
> 1. How often do you find '~' useful? Do you think there should be
> additional operators that ignore revision part?

The only time I have used this is when I've needed to synchronize the
version of two inter-dependent packages, while wanting to allow the
revision portion to vary.

I have generally found it a lot more useful to use this in my various
/etc/portage/ files than in ebuilds, though, especially
package.accept_keywords


> 
> 2. How often do you find '=...*' wildcard syntax useful? To what
> purpose do you use it? Do you find its behavior confusing [1]?

I find that this syntax is rather useful and often is necessary, due
to it being difficult to properly define both minimum and maximun
versions otherwise at times -- especially when I want to use the := or
:0= slot operator.  I don't find its behavior confusing once I became
educated on how it actually works; I do recognize that it *is not*
intuitive to the layman.


> 3. Do you sometimes find yourself using '<'/'<=' specs that
> accidentally match _pre/_rc/... versions?

No, but that is likely just because I tend not to deal with
dependencies that have _pre and _rc suffixes.


> 
> 4. What are the common tasks that you find unnecessarily complex /
> lengthy with the current version specifications?

It is cumbersome to deal with limiting slots to a specific subset,
when wanting to leverage slot-operator rebuilds right now --
effectively you need to have two atoms, one with :=, and a second set
||()'d with each of the slots that are compatible.


> 5. Do you find any other parts of the current version dependency
> specifications confusing?

The as yet still impossible means of dealing properly with multiple
packages that should either independently or when switching from one
to another trigger a (sub)slot rebuild is quite vexing at times.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: important fstab update

[Ian Stakenvicius]

On 28/10/16 12:56 AM, Daniel Campbell wrote:
> On 10/25/2016 10:01 AM, William Hubbs wrote:
>> All,
>>
>> this item is about an important fstab update. In short, people need to
>> move away from /dev/disk-by/* in their fstab vfiles.
>>
>> I do have a question about the newsitem -- how do I make it display only
>> for Linux users?
>>
>> Thanks,
>>
>> William
>>
> Replying to top level since it doesn't seem to fit elsewhere.
> 
> I have an external HDD that I use for periodic, air-gapped backups. I
> use /dev/disk/by-label for it. With that support being removed (or
> rather, problematic for some system configurations), which method is
> most future-proof? I saw mention of UUIDs; is that what we should switch to?
> 
> In my case, it's a removable drive so it may be assigned to something
> besides sdc at times.
> 

What is being recommended here is that instead of
/dev/disk/by-label/ in fstab, you would use LABEL=

man fstab for more info on LABEL= , UUID= , etc.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: important fstab update

[Ian Stakenvicius]

On 27/10/16 09:54 PM, Francesco Riosa wrote:
> 2016-10-28 3:32 GMT+02:00 Ian Stakenvicius <a...@gentoo.org
> <mailto:a...@gentoo.org>>:
> 
> On 27/10/16 09:23 PM, Gregory Woodbury wrote:
> > Out of curiosity, why do folks say that the use of LABEL= is not
> > good?  I realize that s are not required when doing a mkfs, but
> > if the admin does so reliably and wants to use LABEL= thereafter, why 
> should
> > it be "deprecated"?
> 
> I don't think anyone said that the LABEL= syntax is bad; quite the
> opposite -- WilliamH wants everyone using /dev/disk/by-label/
> paths in fstab to instead use LABEL= , to avoid issues if udev
> doesn't create the symlinks before localmount tries to use them.
> 
> 
> Indeed nobody ever said "deprecated" some people (/me too) don't like
> to use labels and prefer UUIDs instead.
> - in some situations -
> To complete the statement labels are very good with fleets of servers
> with predefined and consistent disk layouts, or for some people desktop.
> When it come to a small number of server with different layouts they
> are equivalent in functionality but need managing and memory, when you
> substitute disk for example, simply not worth it.
> 
> Best,
> Francesco


UUID is the same situation in this case -- in fstab you can do it by
UUID= or you can do it by /dev/disk/by-uuid/.  The latter
form depends on udev finishing up and would have the same issue.

The identifier itself that you use for the partition doesn't need to
change at all, its just the means with which you use this identifier
that WilliamH is recommending you change.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: important fstab update

[Ian Stakenvicius]

On 27/10/16 09:23 PM, Gregory Woodbury wrote:
> Out of curiosity, why do folks say that the use of LABEL= is not
> good?  I realize that s are not required when doing a mkfs, but
> if the admin does so reliably and wants to use LABEL= thereafter, why should
> it be "deprecated"?

I don't think anyone said that the LABEL= syntax is bad; quite the
opposite -- WilliamH wants everyone using /dev/disk/by-label/
paths in fstab to instead use LABEL= , to avoid issues if udev
doesn't create the symlinks before localmount tries to use them.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: important fstab update

[Ian Stakenvicius]

On 26/10/16 11:43 PM, Gordon Pettey wrote:
> On Wed, Oct 26, 2016 at 9:05 PM, Ian Stakenvicius <a...@gentoo.org
> <mailto:a...@gentoo.org>> wrote:
> 
> On 26/10/16 04:49 AM, Joshua Kinard wrote:
> > On 10/25/2016 13:15, William Hubbs wrote:
> >> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> >>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs
> <willi...@gentoo.org <mailto:willi...@gentoo.org>> wrote:
> >>>> If you are not using /dev/disk/by-* paths in fstab, you do
> not need to
> >>> take any action for this news item.
> >>>>
> >>>> If you are, it is very critical that you update fstab AS SOON AS
> >>> POSSIBLE. Your system will become unbootable in the future if
> you do
> >>> not  do so.
> >>>
> >>> Err, what is changing that will make systems unbootable?
> >>>
> >>> I am fairly certain systems running systemd will continue to work
> >>> properly with either syntax.
> >>
> >>  They probably will.
> >>
> >>> If this is about the udev-settle issue for OpenRC, I would
> urge you to
> >>> reconsider that.
> >>
> >>  There isn't anything to reconsider afaik. The problem is that
> >>  /dev/disk/by-* are only created by udev/eudev, but the other
> syntax
> >>  works regardless of which device manager  you use, so this is
> the safer
> >>  route.
> >>
> >>  William
> >>
> >
> > I take it us museum relics still using jurassic-era device names like
> > /dev/sd* or /dev/md* aren't affected by this?
> 
> That's correct -- the kernel's 'devtmpfs' creates those ones, whereas
> the /dev/disk/by-* symlinks (pretty well all symlinks in /dev i think,
> actually) are generated by udev rules.
> 
> Actually, I wonder if the /dev/[vgname]/[lvname] paths would be
> affected by this too -- those are symlinks to the actual nodes in
> /dev/mapper/ after all, and are created by 11-dm-lvm.rules
> 
> 
> Those are already problematic; udev and/or lvm2 seem to randomly
> forget to set those up sometimes. I use /dev/mapped/vg-lv in
> /etc/fstab because of that.
>  

If they aren't there at mount time but do show up after everything is
mounted, I'm willing to bet that is caused by the same issue.  I think
I'll add another paragraph to the second draft about this.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: important fstab update

[Ian Stakenvicius]

Here's a revised possibility -- it diverges a little from the original
message but I think its more inclusive as to the issue.

Thoughts?

-

Title: Important fstab and localmount update
Author: William Hubbs 
Content-Type: text/plain
Posted: 2016-10-28
Revision: 1
News-Item-Format: 1.0
[rules-that-limits-this-to-openrc-and-udev??]

Recent updates to init scripts in OpenRC and (e)udev have removed the
requirement for udev to "settle" before it's startup completes.  The
result of this is that services which used to wait for udev to finish
processing all kernel events will now start earlier.  One such service
is localmount.

If "/dev/disk/by-*" source paths for are used for mount points in
fstab, then it is possible that udev may not have created those
symlinks before localmount starts and tries to mount them.

One possible way to address this is to ensure that udev-settle is
started before localmount starts, to enforce the old behaviour.  This
can be done simply by adding it to sysinit the runlevel, or adding an
'rc_want=udev-settle' in /etc/conf.d/localmount.

The more generic solution is to move away from using "/dev/disk/by-*"
source paths and instead convert to using the LABEL= , UUID= , or
PARTUUID= syntax in fstab instead.  This syntax is supported directly
by mount and works regardless of device manager, therefore removing
the the dependency of having udev-settle before mounting these paths.
More information can be found in the fstab manpage.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LLVM News item

[Ian Stakenvicius]

On 25/10/16 06:44 PM, Joakim Tjernlund wrote:
> On Tue, 2016-10-25 at 16:07 -0400, Ian Stakenvicius wrote:
>> On 25/10/16 04:02 PM, Joakim Tjernlund wrote:
>>>
>>> On Tue, 2016-10-25 at 15:41 -0400, Ian Stakenvicius wrote:
>>>>
>>>> On 25/10/16 03:32 PM, Ian Stakenvicius wrote:
>>>>>
>>>>>
>>>>> On 25/10/16 03:08 PM, Joakim Tjernlund wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Tue, 25 Oct 2016 17:32:22 +
>>>>>>> Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and 
>>>>>>>> read:
>>>>>>>> ..
>>>>>>>> In order to enable all targets, add the following to your
>>>>>>>> /etc/portage/package.use or equivalent file:
>>>>>>>>
>>>>>>>>   sys-devel/llvm LLVM_TARGETS: *
>>>>>>>>   sys-devel/clang LLVM_TARGETS: *
>>>>>>>> ...
>>>>>>>>
>>>>>>>> I would like to control such variables(LLVM_TARGETS) through the 
>>>>>>>> profile as
>>>>>>>> well but it seems not supported?
>>>>>>>
>>>>>>> Why not? We're already setting the defaults in profiles, and you can do
>>>>>>> whatever you want in your own profile. The news item is focused on
>>>>>>> regular users, so it covers the usual configuration files rather than
>>>>>>> creating custom profiles.
>>>>>>>
>>>>>>
>>>>>> How? in my profile(which inherits 
>>>>>> gentoo:default/linux/amd64/13.0/desktop) I just tested to add:
>>>>>> # > svn diff
>>>>>> Index: package.use
>>>>>> ===
>>>>>> --- package.use  (revision 1087)
>>>>>> +++ package.use  (working copy)
>>>>>> @@ -1,3 +1,6 @@
>>>>>> +sys-devel/llvm LLVM_TARGETS: *
>>>>>> +sys-devel/clang LLVM_TARGETS: *
>>>>>>
>>>>>> Then I get:
>>>>>> # > emerge -aNDuv world
>>>>>> --- Invalid USE flag for 'sys-devel/llvm' in
>>>>>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>>>>>> 'LLVM_TARGETS:'
>>>>>> --- Invalid USE flag for 'sys-devel/llvm' in
>>>>>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>>>>>> '*'
>>>>>> --- Invalid USE flag for 'sys-devel/clang' in
>>>>>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>>>>>> 'LLVM_TARGETS:'
>>>>>> --- Invalid USE flag for 'sys-devel/clang' in
>>>>>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>>>>>> '*'
>>>>>>
>>>>>
>>>>> Syntax error:
>>>>>
>>>>> sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
>>>>> sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..
>>>
>>> This is standard USE flags, not the VAR: x y z syntax
>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> You can't specify wildcards to enable groups of use flags.
>>>>>
>>>>>
>>>>
>>>> Correction, the earlier syntax *is* supposed to work (and tested that
>>>> it works here, with VIDEO_CARDS)..  If I had to guess this probably
>>>> relates to an issue with the transmode overlay.
>>>>
>>>
>>> Hmm, are you saying that you can write:
>>>   x11-base/xorg-drivers VIDEO_CARDS: intel radeon
>>> in your profile?
>>>
>>> Any idea what my issue might be?
>>>
>>>  Jocke
>>>
>>
>> In my profile as in /etc/portage/package.use/  , yes. Specifically I
>> tested VIDEO_CARDS: *
> 
> I thought it was obvious that I was referring to a custom profile
> as in eselect profile ..
> 
>>
>> I *didn't* try to mess with my in-repo profile though.  Given that
>> repositories may well need to follow PMS, and the USE_EXPAND: * syntax
>> is a portage'ism, this is why they are being rejected in the
>> transmode-overlay case.  I certainly can't find an example of this
>> syntax in the gentoo repo.
> 
> Portage supports lots more than PMS as is, should we remove that?
> Just because something is supported in portage, you don't have to use it
> in official repos. Our overlay is used to maintain all the linux computers
> we have here and /etc/portage is the individual using a particular computer.
> 
> It would be nice if portage, in general, supported the same features/syntax as
> /etc/portage does.
> 
>   Jocke
> 

In-repo profiles are subject to the Package Manager Specification
(PMS), so portage'isms are supposed to be avoided.  Package managers
can have pretty much whatever extensions they want in terms of extra
syntax, etc. in their configuration files/settings though, which is
why this syntax is fine in /etc/portage.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: important fstab update

[Ian Stakenvicius]

On 25/10/16 05:12 PM, Michał Górny wrote:
> On Tue, 25 Oct 2016 12:01:06 -0500
> William Hubbs  wrote:
> 
>> Title: Inportant fstab update
>> Author: William Hubbs 
>> Content-Type: text/plain
>> Posted: 2016-10-28
>> Revision: 1
>> News-Item-Format: 1.0
>>
>> If you are not using /dev/disk/by-* paths in fstab, you do not need to
>> take any action for this news item.
>>
>> If you are, it is very critical that you update fstab AS SOON AS
>> POSSIBLE. Your system will become unbootable in the future if you do
>> not  do so.
> 
> I don't think this is a good way to start any text. You should start
> with a short introduction on what's happening, when and how.
> 
> Right now the news item sounds like the world is going to suddenly fall
> apart for no specific reason. Reading it, I don't know what's changing,
> and how to check if it impacts me already (i.e. if it's 'do not
> reboot' kind of problem) and if it will impact me at all.
> 
>> You need to replace the /dev/disk/by-* paths in your fstab with the
>> equivalent information from the output of the blkid utility.
> 
> This is at least unclear, if not misguiding. I read it as 'blkid will
> give you fs info'. However, you're not telling me which of those
> information I can use and how. I should also point out that blkid
> supports multiple output formats.
> 
> I think it would be better if you explicitly listed the thingies
> supported by mount(1).
> 

Reading mgorny's response, I'm wondering if a news item really makes
any sense at all for this.  What's being done here is essentially a
warning/recommendation for users to act so they don't run into a
problem that's sort-of already there (at least in ~arch)...

Personally I'd rather see us go the other way, ensure udev settles
before localmount runs, and maybe ewarn if /dev/disk/by-* is in fstab
or something.  Leave the migration away from these paths to general
education of system setup, since they technically are valid, just not
ideal.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LLVM News item

[Ian Stakenvicius]

On 25/10/16 04:02 PM, Joakim Tjernlund wrote:
> On Tue, 2016-10-25 at 15:41 -0400, Ian Stakenvicius wrote:
>> On 25/10/16 03:32 PM, Ian Stakenvicius wrote:
>>>
>>> On 25/10/16 03:08 PM, Joakim Tjernlund wrote:
>>>>
>>>> On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
>>>>>
>>>>> On Tue, 25 Oct 2016 17:32:22 +
>>>>> Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
>>>>>> ..
>>>>>> In order to enable all targets, add the following to your
>>>>>> /etc/portage/package.use or equivalent file:
>>>>>>
>>>>>>   sys-devel/llvm LLVM_TARGETS: *
>>>>>>   sys-devel/clang LLVM_TARGETS: *
>>>>>> ...
>>>>>>
>>>>>> I would like to control such variables(LLVM_TARGETS) through the profile 
>>>>>> as
>>>>>> well but it seems not supported?
>>>>>
>>>>> Why not? We're already setting the defaults in profiles, and you can do
>>>>> whatever you want in your own profile. The news item is focused on
>>>>> regular users, so it covers the usual configuration files rather than
>>>>> creating custom profiles.
>>>>>
>>>>
>>>> How? in my profile(which inherits gentoo:default/linux/amd64/13.0/desktop) 
>>>> I just tested to add:
>>>> # > svn diff
>>>> Index: package.use
>>>> ===
>>>> --- package.use(revision 1087)
>>>> +++ package.use(working copy)
>>>> @@ -1,3 +1,6 @@
>>>> +sys-devel/llvm LLVM_TARGETS: *
>>>> +sys-devel/clang LLVM_TARGETS: *
>>>>
>>>> Then I get:
>>>> # > emerge -aNDuv world
>>>> --- Invalid USE flag for 'sys-devel/llvm' in 
>>>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>>>> 'LLVM_TARGETS:'
>>>> --- Invalid USE flag for 'sys-devel/llvm' in 
>>>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>>>> '*'
>>>> --- Invalid USE flag for 'sys-devel/clang' in 
>>>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>>>> 'LLVM_TARGETS:'
>>>> --- Invalid USE flag for 'sys-devel/clang' in 
>>>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>>>> '*'
>>>>
>>>
>>> Syntax error:
>>>
>>> sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
>>> sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..
> 
> This is standard USE flags, not the VAR: x y z syntax
> 
>>>
>>>
>>> You can't specify wildcards to enable groups of use flags.
>>>
>>>
>>
>> Correction, the earlier syntax *is* supposed to work (and tested that
>> it works here, with VIDEO_CARDS)..  If I had to guess this probably
>> relates to an issue with the transmode overlay.
>>
> 
> Hmm, are you saying that you can write:
>   x11-base/xorg-drivers VIDEO_CARDS: intel radeon
> in your profile?
> 
> Any idea what my issue might be?
> 
>  Jocke
> 

In my profile as in /etc/portage/package.use/  , yes. Specifically I
tested VIDEO_CARDS: *

I *didn't* try to mess with my in-repo profile though.  Given that
repositories may well need to follow PMS, and the USE_EXPAND: * syntax
is a portage'ism, this is why they are being rejected in the
transmode-overlay case.  I certainly can't find an example of this
syntax in the gentoo repo.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LLVM News item

[Ian Stakenvicius]

On 25/10/16 03:32 PM, Ian Stakenvicius wrote:
> On 25/10/16 03:08 PM, Joakim Tjernlund wrote:
>> On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
>>> On Tue, 25 Oct 2016 17:32:22 +
>>> Joakim Tjernlund <joakim.tjernl...@infinera.com> wrote:
>>>
>>>>
>>>> Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
>>>> ..
>>>> In order to enable all targets, add the following to your
>>>> /etc/portage/package.use or equivalent file:
>>>>
>>>>   sys-devel/llvm LLVM_TARGETS: *
>>>>   sys-devel/clang LLVM_TARGETS: *
>>>> ...
>>>>
>>>> I would like to control such variables(LLVM_TARGETS) through the profile as
>>>> well but it seems not supported?
>>>
>>> Why not? We're already setting the defaults in profiles, and you can do
>>> whatever you want in your own profile. The news item is focused on
>>> regular users, so it covers the usual configuration files rather than
>>> creating custom profiles.
>>>
>>
>> How? in my profile(which inherits gentoo:default/linux/amd64/13.0/desktop) I 
>> just tested to add:
>> # > svn diff
>> Index: package.use
>> ===
>> --- package.use  (revision 1087)
>> +++ package.use  (working copy)
>> @@ -1,3 +1,6 @@
>> +sys-devel/llvm LLVM_TARGETS: *
>> +sys-devel/clang LLVM_TARGETS: *
>>
>> Then I get:
>> # > emerge -aNDuv world
>> --- Invalid USE flag for 'sys-devel/llvm' in 
>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>> 'LLVM_TARGETS:'
>> --- Invalid USE flag for 'sys-devel/llvm' in 
>> '/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
>> --- Invalid USE flag for 'sys-devel/clang' in 
>> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
>> 'LLVM_TARGETS:'
>> --- Invalid USE flag for 'sys-devel/clang' in 
>> '/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
>>
> 
> Syntax error:
> 
> sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
> sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..
> 
> 
> You can't specify wildcards to enable groups of use flags.
> 
> 

Correction, the earlier syntax *is* supposed to work (and tested that
it works here, with VIDEO_CARDS)..  If I had to guess this probably
relates to an issue with the transmode overlay.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] LLVM News item

[Ian Stakenvicius]

On 25/10/16 03:08 PM, Joakim Tjernlund wrote:
> On Tue, 2016-10-25 at 20:11 +0200, Michał Górny wrote:
>> On Tue, 25 Oct 2016 17:32:22 +
>> Joakim Tjernlund  wrote:
>>
>>>
>>> Noticed todays 2016-10-25-llvm_3_9_with_llvm_targets news item and read:
>>> ..
>>> In order to enable all targets, add the following to your
>>> /etc/portage/package.use or equivalent file:
>>>
>>>   sys-devel/llvm LLVM_TARGETS: *
>>>   sys-devel/clang LLVM_TARGETS: *
>>> ...
>>>
>>> I would like to control such variables(LLVM_TARGETS) through the profile as
>>> well but it seems not supported?
>>
>> Why not? We're already setting the defaults in profiles, and you can do
>> whatever you want in your own profile. The news item is focused on
>> regular users, so it covers the usual configuration files rather than
>> creating custom profiles.
>>
> 
> How? in my profile(which inherits gentoo:default/linux/amd64/13.0/desktop) I 
> just tested to add:
> # > svn diff
> Index: package.use
> ===
> --- package.use   (revision 1087)
> +++ package.use   (working copy)
> @@ -1,3 +1,6 @@
> +sys-devel/llvm LLVM_TARGETS: *
> +sys-devel/clang LLVM_TARGETS: *
> 
> Then I get:
> # > emerge -aNDuv world
> --- Invalid USE flag for 'sys-devel/llvm' in 
> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> 'LLVM_TARGETS:'
> --- Invalid USE flag for 'sys-devel/llvm' in 
> '/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
> --- Invalid USE flag for 'sys-devel/clang' in 
> '/var/lib/layman/transmode/profiles/gentoo64/package.use':
> 'LLVM_TARGETS:'
> --- Invalid USE flag for 'sys-devel/clang' in 
> '/var/lib/layman/transmode/profiles/gentoo64/package.use': '*'
> 

Syntax error:

sys-devel/llvm llvm_targets_firstone llvm_targets_secondone ..
sys-devel/clang llvm_targets_firstone llvm_targets_secondone ..


You can't specify wildcards to enable groups of use flags.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: important fstab update

[Ian Stakenvicius]

On 25/10/16 01:10 PM, Mike Gilbert wrote:
> 
> If this is about the udev-settle issue for OpenRC, I would urge you to
> reconsider that.
> 

+1



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: important fstab update

[Ian Stakenvicius]

On 25/10/16 01:07 PM, James Le Cuirot wrote:
> On Tue, 25 Oct 2016 12:01:06 -0500
> William Hubbs  wrote:
> 
>> this item is about an important fstab update. In short, people need to
>> move away from /dev/disk-by/* in their fstab vfiles.
> 
> "Inportant" typo in the title.
> 
> Even before you posted this, I was wondering why this is a problem now?
> 

Openrc's localmount doesn't wait for udev to finish anymore (partially
because udev doesn't 'settle' by default), and so instead of adding a
'use udev-settle' WilliamH decided to notify people to just not use
udev-triggered symlinks.

The LABEL= or UUID= syntax in /etc/fstab is more robust so it makes
sense for users to use that instead of these symlinks anyhow.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] need for autotools

[Ian Stakenvicius]

On 25/10/16 11:34 AM, Ian Stakenvicius wrote:
> On 25/10/16 11:05 AM, Nick Vinson wrote:
>> On 10/25/2016 07:11 AM, Raymond Jennings wrote:
>>> Don't you need autoconf and automake to build a lot of packages?
>>
>> Theoretically no.  When autotools is used correctly, the release tarball
>> has no dependency on either.  That said, many people don't generate /
>> distribute a release tarball.
>>
>> However, I don't think this is the criterion used to determine what
>> should be in @system.  The wiki defines the system set as the set that
>> "contains the software packages required for a standard Gentoo Linux
>> installation to run properly".
>>
>> That definition definitely excludes automake and autoconf (arguably gcc
>> should also excluded, under that definition, so the wiki might not be
>> 100% correct).
>>
>> -Nicholas Vinson
>>
> 
> Unless you need to patch the build system, in which case you need to
> re-run autoconf/automake/etc (usually via 'eautoreconf').  And there's
> -plenty- of instances of that around as well.
> 

I forgot to mention that autotools.eclass brings in these dependencies
as-needed, though, so I agree that they definitely are not required in
the @system set.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] need for autotools (was: Commented packages in the @system set)

[Ian Stakenvicius]

On 25/10/16 11:05 AM, Nick Vinson wrote:
> On 10/25/2016 07:11 AM, Raymond Jennings wrote:
>> Don't you need autoconf and automake to build a lot of packages?
> 
> Theoretically no.  When autotools is used correctly, the release tarball
> has no dependency on either.  That said, many people don't generate /
> distribute a release tarball.
> 
> However, I don't think this is the criterion used to determine what
> should be in @system.  The wiki defines the system set as the set that
> "contains the software packages required for a standard Gentoo Linux
> installation to run properly".
> 
> That definition definitely excludes automake and autoconf (arguably gcc
> should also excluded, under that definition, so the wiki might not be
> 100% correct).
> 
> -Nicholas Vinson
> 

Unless you need to patch the build system, in which case you need to
re-run autoconf/automake/etc (usually via 'eautoreconf').  And there's
-plenty- of instances of that around as well.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package file name requirement for binary ebuilds

[Ian Stakenvicius]

On 17/10/16 10:54 AM, Michael Mol wrote:
> 
> There's also firefox-bin, which gets built upstream with profile-guided 
> optimizations enabled. PGO is unsupported outside of upstream's build 
> process, 
> last I checked...but that was a few years ago.
> 

Mozilla project has a dev that's supporting PGO builds in the source
package now.

That said, the primary reason why the mozilla *-bin packages exist in
Gentoo is because that's all that upstream officially supports.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Local workarounds with no reported bugs

[Ian Stakenvicius]

On 17/10/16 03:23 AM, Michał Górny wrote:
> Hello, everyone.
> 
> I'd like to point out a major problem in Gentoo: there's a fair number
> of developers who add various local workarounds to problems they meet
> and don't bother to report a bug. Worst than that, this applies not
> only for upstream problems but also to Gentoo eclass/ebuild-related
> issues.
> 
> 
> Example: udev people had problems with MULTILIB_WRAPPED_HEADERS
> in the past. Instead of contacting me (which would result in helpful
> explanation how to do things properly), they abused bash to disable
> the check function implicitly in the ebuilds.
> 
> Nobody bothered to inform me of the issue there. Instead, I had to
> notice it looking at the udev ebuilds accidentally. Furthermore, in
> most of the ebuilds the workaround was no longer necessary but nobody
> bothered to check that.
> 
> 
> Example 2: Coacher had problem with git-r3 not trying fallback URIs
> when earlier URI was https and https wasn't supported in git. So he
> reordered URIs to have https last. With tiny explanation in some random
> commit message.
> 
> So we have a problem that affects around a half of git-r3 packages
> (using quick grep, results inaccurate), however minor it is. Worse, it
> affects the policy of preferring https and causes some people to reject
> the policy silently. And nobody gives a damn to report it!
> 
> 
> Therefore, I'd like to request establishing an official policy against
> workarounds with no associated bug reports.
> 
> Your thoughts?
> 

To be clear, are you referring here to workarounds only regarding
gentoo related stuffs (use of eclasses, package manager (ie portage)
functionality, etc) or are you also referring to the various
workarounds we as maintainers need to do to say, the use of build
tools (cmake, etc) or upstream's codebase/build system itself, to
successfully package it as well?





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package file name requirement for binary ebuilds

[Ian Stakenvicius]

On 16/10/16 10:43 PM, William L. Thomson Jr. wrote:
> On Sunday, October 16, 2016 9:19:25 PM EDT Ian Stakenvicius wrote:
>>
>> *IF* we were going to make use of upstream vs gentoo-generated binary
>> packages in the tree, they *WOULD* block one-another as they would
>> collide file-wise at least partially if not completely.  So there
>> wouldn't be any testing between the two variants on the same installed
>> system.
> 
> That was not an argument I was initially making as justification, but via 
> slotting and changing names of binaries and/or paths it could be done.
> 
> It is in part why systems like eselect exist to switch between 
> implementations. In Java's case there is a wrapper around all binaries that 
> is 
> called, which handles which ones is used. run-java-tool.bash. In addition to 
> things like java-cpnfig etc.
> 
> Also why there is gcc-config, binutils-config, etc. Part of the beauty of 
> Gentoo 
> is installing things that collide, and switching between them for testing.
> 
>>> Maybe the upstream binary runs better, does not crash, etc. Or the Gentoo
>>> one does. If the Gentoo one is better, it could be used to get a
>>> reluctant upstream to make changes. If worse could be used to help figure
>>> out where its going wrong.
>>
>> OK, so here's how things *actually work* in the gentoo repo:
> 
> Because I need such an explanation? I think it could be a little less harsh 
> no?
> 
>> #1, binary packages aren't made unless there's a really good reason
>> for them -- the primary one being that there isn't any other option
>> provided by upstream.
> 
> Is that a mandated policy? There are ebuilds in tree that are not that way.
> 
>> #2, if there is a binary package then the only reason why a gentoo dev
>> would roll it instead of using upstream's version is because the
>> upstream one fails hard or has too many bugs, security
>> vulnerabilities, whatever.  This is as much done on a per-version
>> basis within a package as it is on a per-package one.
> 
> There is a 3rd case, where the package is to complex to package from source. 
> Things like jenkins-bin, and there are others... jenkins can be packaged from 
> source, as some others can be. If they were -sbin, maybe more would be aware 
> and try to package from source vs use as binary because it is to hard to 
> package from source.
> 
>> All of this discussion is centered around trying to bring convention
>> to a problem that simply doesn't exist.  
> 
> Maybe you are just not aware. Which if the packages were required to be 
> named, 
> say -sbin a binary that is a from source package, just not packaged you would 
> be aware.
> 
> They exist, go look! Also seems to be growing.
> 
>> Also, if the idea here is to
>> open the door for a flood of gentoo-dev-rolled *-bin packages in the
>> gentoo repo for end-user convenience,
> 
> No that is not the case, and that is done in extreme limited case. I am not 
> pushing for more binary packages by any means. It would simply be to 
> differentiate, so anyone knows by file name what they are getting, from 
> upstream or from Gentoo.
> 
>> then we should similarly stop
>> this discussion right now too.  How about, instead, you could focus on
>> setting up two (additional) repos -- one containing gentoo-built
>> binary packages, another containing upstream-only packages.
> 
> That is not my goal. I am trying to bring to attention -bin packages in tree. 
> -sbin packages should draw attention to get people to package them from 
> source.
> 
>> That way
>> it'll be very obvious to end-users what they'll be using because
>> they'll know exactly based on where it comes from. 
> 
> This is an issue of things already in tree, and packages being added in tree, 
> in Gentoo's repo. Which I obviously cannot do so its not my work.
> 
>> It'll also be very
>> easy for end-users to control which one is used, just by choosing
>> which repo it comes from.  AND, it'll keep them from polluting the
>> main gentoo repo too.
> 
> It is already polluted, seems you are unaware, but now you know.
> 
> Likely wasn't intentional but came across VERY hostile, and completely 
> missing 
> the mark and point.
> 

It wasn't meant to be hostile but yes my patience was lacking and I
apologize.

I agree, there are a number of binary packages in the tree already and
fortunately most of them have a -bin in their name despite this not
being any formal requirement.  There is also no particular policy that
I am aware of for ensuring packages are designed to be built from
source first and foremost -- however it doesn't make much sense to
have a source-based distro full of precompiled binaries and so I do
believe pretty well every developer strives to make this so whenever
possible, given that's sort of our purpose here.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package file name requirement for binary ebuilds

[Ian Stakenvicius]

On 16/10/16 06:30 PM, William L. Thomson Jr. wrote:
> On Saturday, October 15, 2016 4:10:51 PM EDT Kent Fredric wrote:
>>
>> Yeah, I get the intent, but I don't see it being likely we'd ever have
>> a real usecase for having both a -bin and a -gbin in tree together.
> 
> You actually came up with one I was not considering at first but provides a 
> direct technical benefit you cannot achieve with a USE flag.
>  
>> If anything, I'd imagine if that case arose, it would manifest itself more
>> as:
>>
>>icedtea-bin + USE=official
> 
> Then how would you test that against non official? You cannot install the 
> same 
> package twice at the same time with different USE flags. You can't even make 
> binaries easily of the same package with different USE flags. The previous 
> binary will get overwritten.


*IF* we were going to make use of upstream vs gentoo-generated binary
packages in the tree, they *WOULD* block one-another as they would
collide file-wise at least partially if not completely.  So there
wouldn't be any testing between the two variants on the same installed
system.



> Maybe the upstream binary runs better, does not crash, etc. Or the Gentoo one 
> does. If the Gentoo one is better, it could be used to get a reluctant 
> upstream to make changes. If worse could be used to help figure out where its 
> going wrong.

OK, so here's how things *actually work* in the gentoo repo:

#1, binary packages aren't made unless there's a really good reason
for them -- the primary one being that there isn't any other option
provided by upstream.

#2, if there is a binary package then the only reason why a gentoo dev
would roll it instead of using upstream's version is because the
upstream one fails hard or has too many bugs, security
vulnerabilities, whatever.  This is as much done on a per-version
basis within a package as it is on a per-package one.

All of this discussion is centered around trying to bring convention
to a problem that simply doesn't exist.  Also, if the idea here is to
open the door for a flood of gentoo-dev-rolled *-bin packages in the
gentoo repo for end-user convenience, then we should similarly stop
this discussion right now too.  How about, instead, you could focus on
setting up two (additional) repos -- one containing gentoo-built
binary packages, another containing upstream-only packages.  That way
it'll be very obvious to end-users what they'll be using because
they'll know exactly based on where it comes from.  It'll also be very
easy for end-users to control which one is used, just by choosing
which repo it comes from.  AND, it'll keep them from polluting the
main gentoo repo too.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package file name requirement for binary ebuilds

[Ian Stakenvicius]

On 14/10/16 01:17 PM, William L. Thomson Jr. wrote:
> On Friday, October 14, 2016 1:09:25 PM EDT Ian Stakenvicius wrote:
>> On 14/10/16 01:05 PM, William L. Thomson Jr. wrote:
>>> Problem
>>> 2. There are binary packages that end in -bin, which is good. However it
>>> is
>>> not clear if that is an upstream 3rd party binary. Or a binary made by
>>> compiling a large Gentoo package, by a Gentoo dev or contributor on a
>>> Gentoo system. Like icedtea-bin for example, and likely some others.
>>
>> Is there a reason that this differentiation would matter?
> 
> In my opinion yes, the following reasons at minimum
> 
> 1. Upstream binary little can be done if there are issues. Maybe changing 
> things on the system, but cannot change what it was built/linked against etc. 
> Bugs there would be filed against upstream, not really Gentoo as there is 
> nothing that can be done to change the binary itself.
> 
> 2. Gentoo made binaries can be remade if there are issues. Bugs on those 
> should be filed against Gentoo rather than upstream. There is also a process 
> to 
> making those binaries. It may be as simple as emerging a Gentoo package and 
> creating a tarball, or it may not. Others may need to know how to do such if 
> someone moves on. Most times that is not documented, and people have no idea 
> if the binary was made for Gentoo on Gentoo, or just re-packaged upstream.
> 
> 3. The obvious reason to have a -bin in general, is to let anyone know they 
> are merging a binary package. Which may or may not be wanted. Also shows what 
> packages may need to be packaged from source if possible. People may choose 
> to 
> emerge a self made Gentoo binary more often than say a third party one. Since 
> they know it was built on a Gentoo system, just saves them from having to 
> compile themselves. They also may trust a Gentoo made binary more than one 
> from upstream, but that is speculative.
> 
> Mostly reasons 1 and 2, 3 is a side benefit but not the major rational.
> 

So, #1, if there's a problem we should still have bugs in gentoo's
bugzilla -- there may be little that can be done to the package but if
the issue is with integration into the rest of gentoo that is
absolutely within the realm of the maintainer to address.  Either way,
having the package's name indicate if its an upstream binary or not is
rather moot to this one.

#2, see #1 regarding bugs; regarding maintenance, this isn't a whole
lot different from training replacement devs in how to handle a
foreign build system or managing very complex configuration options --
that is, instructions or documentation or helper scripts should be
made available and shared somewhere not in the package.  Having the
package name indicate upstream-bin vs gentoo-bin doesn't help this one
either.

#3, this may have merit in terms of using an alternate package name
for upstream vs gentoo rolled binaries, but realistically i'm not
seeing a need for the separation in the package's NAME unless we're
going to have both gento-rolled and upstream-rolled binaries in the
repo at the same time, competing with eachother.  It would be just as
effective IMO to list if the package is gentoo-rolled or not in its
description in metadata, no need to (re)define the package name.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package file name requirement for binary ebuilds

[Ian Stakenvicius]

On 14/10/16 01:05 PM, William L. Thomson Jr. wrote:
> Problem
> 2. There are binary packages that end in -bin, which is good. However it is 
> not clear if that is an upstream 3rd party binary. Or a binary made by 
> compiling a large Gentoo package, by a Gentoo dev or contributor on a Gentoo 
> system. Like icedtea-bin for example, and likely some others.

Is there a reason that this differentiation would matter?





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Ian Stakenvicius]

On 14/10/16 10:22 AM, Fernando Rodriguez wrote:
> On 10/13/2016 10:21 AM, Ian Stakenvicius wrote:
>> On 13/10/16 10:13 AM, Raymond Jennings wrote:
>>> On Thu, Oct 13, 2016 at 7:01 AM, Fernando Rodriguez
>>> <cyklon...@gmail.com <mailto:cyklon...@gmail.com>> wrote:
>>>
>>> On 10/04/2016 06:24 PM, William Hubbs wrote:
>>> >
>>> >  This would actually be another reason to get rid of grub-0, if it 
>>> can't
>>> >  build on one of our profiles, it will more than likely never be fixed
>>> >  upstream because they are now focused on grub-2.x.
>>>
>>> grub-0 is 32-bit software. You could build it without multilib but
>>> you need
>>> the dependencies like any other package (and link them
>>> statically). And there
>>> are other packages on the tree that don't build on all profiles.
>>>
>>>
>>> USE="abi_x86_32"
>>>
>>> ?
>>
>> Yes, that's how it's supported on multilib.  Note though it still
>> needs a multilib profile in order to have an abi_x86_32 libc;
>> grub-static exists to support systems where there is no abi_x86_32
>> libc installed, such as those systems using the no-multilib profile.
> 
> I didn't mean it's supported by gentoo but that is possible to build it
> without a 32-bit *system* libc. Just bundle it and link it statically like
> firefox does with it's deps. grub-static probably makes more sense (that's
> a binary package right?). I just meant that this is not a sign that the
> package it's broken upstream as the comment implied.
> 
> 

Ahh, ok.  So you're just confirming what cyklonite mentioned.  I
didn't get that the first time around.

To the specifics though, no it doesn't make sense to bundle a copy of
glibc so that it can be built 32bit in order to support linking grub:0
to it; if anyone -really- wants to build grub:0 on a pure64 platform
then they can use a 32bit crossdev to do it, just like they'd have to
do to build anything else that's 32bit only on a pure64 install.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: rfc: the demise of grub:0

[Ian Stakenvicius]

On 13/10/16 10:13 AM, Raymond Jennings wrote:
> On Thu, Oct 13, 2016 at 7:01 AM, Fernando Rodriguez
> > wrote:
> 
> On 10/04/2016 06:24 PM, William Hubbs wrote:
> >
> >  This would actually be another reason to get rid of grub-0, if it can't
> >  build on one of our profiles, it will more than likely never be fixed
> >  upstream because they are now focused on grub-2.x.
> 
> grub-0 is 32-bit software. You could build it without multilib but
> you need
> the dependencies like any other package (and link them
> statically). And there
> are other packages on the tree that don't build on all profiles.
> 
> 
> USE="abi_x86_32"
> 
> ?

Yes, that's how it's supported on multilib.  Note though it still
needs a multilib profile in order to have an abi_x86_32 libc;
grub-static exists to support systems where there is no abi_x86_32
libc installed, such as those systems using the no-multilib profile.





signature.asc
Description: OpenPGP digital signature

Re: #wg-stable: Reservations about a "STABLE" & "NeedsStable" bugzilla keywords (re: [gentoo-dev] New Working Group established to evaluate the stable tree)

[Ian Stakenvicius]

On 20/08/16 08:30 PM, Daniel Campbell wrote:
> On 08/15/2016 12:42 PM, Rich Freeman wrote:
>> On Mon, Aug 15, 2016 at 3:30 PM, Andreas K. Hüttel  
>> wrote:
>>> 1) Stabilization is a simpler and much more formalized process compared to
>>> normal bug resolution.
>>> * There is one version to be stabilized.
>>> * One precise package version
>>
>> Can you clarify what this means?  Do you mean that at any time only
>> one version of any particular package/slot is marked stable?
>>
>> That seems like it would be problematic for ranged deps.  Granted,
>> those are problematic in and of themselves since they can create
>> conflicts that are hard to resolve.  However, this extends conflicts
>> between package you might not want to install at the same time to
>> situations where you don't even need both of the conflicting packages.
>>
> I believe he's just talking about a per-bug or per-stablereq basis. So
> each version gets its own opportunity to have bugs surface or
> stabilization issues instead of attempting to stabilize a bunch of
> versions at once.
> 
> (Correct me if I'm wrong; I don't see the value of a single stable
> version for each package and it would create a lot of noise in git log)
> 

Even though some projects (mozilla, for instance) do request
stabilizations of multiple packages and/or versions in a single go,
that doesn't mean we should and I have no issues changing our process
to something more atomic.

What should be noted here is that if we work towards adopting new
tools or methods here, we absolutely need to do so in a way that is
beneficial to the workflow of our AT's, especially those that perform
large numbers of stabilizations like ago.  If this new process doesn't
make things at least incrementally easier for them, it needs to be
re-thought.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] SRC_URI="gogdownloader://..."

[Ian Stakenvicius]

On 02/10/16 04:59 PM, James Le Cuirot wrote:
> On Sun, 2 Oct 2016 21:48:04 +0100
> James Le Cuirot  wrote:
> 
>> SRC_URI="gogdownloader://tomb_raider_1/en1installer1 ->
>> setup_tomb_raider_${PV}.exe" IUSE="gogdownloader"
>> RESTRICT="!gogdownloader? ( fetch ) mirror"
>> DEPEND="games-util/lgogdownloader"
> 
> Probably goes without saying but that should have been:
> DEPEND="gogdownloader? ( games-util/lgogdownloader )"
> 

So I think the idea of supporting this is great, but I think the best
way to go about it is to support it in the same manner that the VCS
eclasses do -- that is, DONT use SRC_URI but instead use GOG_URI , and
have the gog eclass within src_unpack handle the actual fetching.

If in a future EAPI we get src_fetch() and the ability to specify
custom fetching, then this can be improved, but for now I'd say do it
the same as the VCS eclasses do.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Proposed future EAPI feature: FILES whitelist

[Ian Stakenvicius]

On 16/09/16 11:20 AM, Ulrich Mueller wrote:
> 
> AFAICS that proposal goes into a direction which is somewhat opposite
> to what we have pursued in EAPI 6. There, we have allowed directories
> as arguments to eapply, in order to simplify application of patchsets.
> Now maintainers would have to list all single files contained in the
> directory again.

I had thought that particular functionality was more to support
patchset tarballs that get extracted to ${WORKDIR} rather than
supporting such (ab)use in ${FILESDIR} ?





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] questions about small fixes/cleanups

[Ian Stakenvicius]

On 14/09/16 12:20 PM, Kent Fredric wrote:
> On Wed, 14 Sep 2016 16:41:54 +0200
> Alexis Ballier  wrote:
> 
>>
>> So, to sum it up, I have to:
>> - Open a browser, go to github (*)
>> - Find out latest commit hash, copy it
>> - (*) Copy the ebuild, setting a 8 digit version representing the date
>> - Open an editor
>> - Edit COMMIT='...' variable by pasting what was found on github. (*)
>>
>>
>> Thanks, but I prefer by far:
>> - Run a script
>> - Copy ebuild, setting version printed by the script.
>>
>>
>> (*) represents everytime i have to switch my hands between keyboard and
>> mouse
>>
> 
> 
> You can also abuse `git ls-remote Path/To/Repo` -> list of SHA1s -> ebuild -> 
> sed
> 
> But you're back to writing a script =)
> 
> Or you can do that manually, it reduces the number of *'s 
> 


More to the point of the original query, such scripts don't
necessarily need to exist in the gentoo repo; they can be in local
repos or project overlays instead.

Note also that I'm perfectly fine with scripts like this staying in
${FILESDIR}.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

[Ian Stakenvicius]

On 11/08/16 10:57 AM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 11.08.2016 kell 12:56, kirjutas Ulrich Mueller:
>>> On Thu, 11 Aug 2016, James Le Cuirot wrote:
>>
 Have you asked Debian why they are doing that?
>>
>>> I did find out but had since forgotten. Here it is:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380725#10
>>
>> So they are aware of the issue since 10 years, but chose not to fix
>> it? Seriously, there's no good reason to dance to their tune then.
> 
> It's not to dance to Debians tune, it's to dance to Valve tunes, which
> happens to create its runtimes from Ubuntu packages.
> I strongly believe that it's important to have such a use case as Steam
> work problem-free in Gentoo. It's currently too messy, with and without
> using steam runtime.
> In the former case (using steam runtime), there are incompatibilities
> between libraries found in the steam runtime, and those that it doesn't
> include and assumes the system provides (primarily mesa and deps); each
> steam runtime version you get to hack around things by removing a small
> selection of libraries from the steam runtime dir to get stuff working;
> a 1-2 month old upgrade I haven't even managed to get to work yet on a
> more up to date machine.
> In the latter case (forcing to not use steam runtime), it's near
> impossible right now to get a set of 32bit binaries to satisfy even
> steam client itself without lots of trial and error, let alone some
> 32bit game.
> 
>>> I'm fine with putting it in libpcre-debian package as kentnl
>>> suggested.
>>
>> I still think that the libpcre.so.3 compatibility link shouldn't be
>> installed in a generally visible location. Install it in a specific
>> directory instead, and start your binary with a wrapper which will
>> add that directory to LD_LIBRARY_PATH.
> 
> Isn't this a use case for ldscripts, e.g like gen_usr_ldscript
> toolchain.eclass function does, except for pointing libpcre.so.3 to
> libpcre.so.1 (so can't use that eclass function, but could just pre-
> create one to $FILESDIR if it works)?
> The important points should be:
> 1) No compilation/linking done on Gentoo should possibly end up with
> putting libpcre.so.3 in its DT_NEEDED
> 2) libpcre.so should link to libpcre.so.1
> 
> If we can satisfy these, I don't see a reason to mess around with some
> extra package.
> Debian reasoning of having stuck with libpcre.so.3 historically is
> sound as well, especially if upstream will never use that, given
> libpcre2.so.x or however they soname pcre2-10+. Also, given PCRE2, and
> given debians todays situation with this, I would also technically
> choose not to change this, as things should migrate over to PCRE2.
> 
> 
> Mart
> 


Wouldn't the most simple solution here would be to make a symlink for
libpcre.so.3 within the local bindir for each Valve or whatever
package that needs it?  This is a binary-package-supporting hack,
might as well do it in the binary packages that need it.  You might
still need to wrap the binary to set some environment stuff, not sure;
either way it doesn't seem to make sense to make this a system-wide thing.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] news item: grub2 multislot use flag is being disabled

[Ian Stakenvicius]

On 08/08/16 10:12 AM, William Hubbs wrote:
> The multislot use flag in sys-boot/grub-2.x, which has been enabled by
> default, is being switched to disabled by default.
> 
> This means that, for all new systems, and for anyone who doesn't take
> action, all of the binaries and documentation in grub-2 that have grub2
> at the start of their names will be renamed to just grub to match
> upstream defaults. For example, grub2-mkconfig will become
> grub-mkconfig, grub2-install will become grub-install, etc.
> 
> If you do not want this to happen on your system, add the following line
> to /etc/portage/package.use.
> 
> sys-boot/grub multislot
> 


The following wording might be a little more neutral; i found when
reading the original version (until i reached the end that is) it
seemed as if the flag was being removed rather than just not being
default-enabled anymore.

-

The multislot use flag in sys-boot/grub-2.x, which had been enabled by
default, is now off by default.

When the flag is enabled, all upstream binaries and documentation are
renamed to "grub2" so as not to collide with grub-0.  Now that the use
flag is no longer default-enabled, these names will revert back to
their upstream defaults.  For example, grub2-mkconfig will become
grub-mkconfig, grub2-install will become grub-install, etc.

If you wish to retain the previous naming scheme please make sure to
explicitly enable USE="multislot" on sys-boot/grub in the usual manner.

-




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] depend.apache.eclass - fix for EAPI6

[Ian Stakenvicius]

On 14/07/16 04:44 PM, Michael Orlitzky wrote:
> On 07/14/2016 04:24 PM, Ian Stakenvicius wrote:
>> Hey all -- depend.apache.eclass currently calls get_libdir() in global
>> scope due to _init_apache2 being called by need_apache*() functions.
>> This patch drops _init_apache2 from these need_apache*() functions on
>> all EAPIS other than 0-5, and calls it during depend.apache_pkg_setup().
> 
> Now would also be a good time to think about whether or not you really
> need an eclass to add =www-servers/apache-2.2* to (R)DEPEND.
> 

Sort of -- Now would be a good time to make sure this patch is OK to
commit; once that's in place, THEN its a good time to consider
deprecation of the eclass alltogether.






signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] depend.apache.eclass - fix for EAPI6

[Ian Stakenvicius]

Hey all -- depend.apache.eclass currently calls get_libdir() in global
scope due to _init_apache2 being called by need_apache*() functions.
This patch drops _init_apache2 from these need_apache*() functions on
all EAPIS other than 0-5, and calls it during depend.apache_pkg_setup().

FYI, there are nine packages which would need to be adjusted if this
change were to not be EAPI6 specific, and none of the adjustments
would need revbumps or stabilizations:

app-text/refbase
dev-perl/Apache-Test
media-sound/mserv
sci-geosciences/mapserver
www-apps/Apache-Gallery
www-apps/lxr
www-apps/redmine
www-apps/rt
www-misc/zoneminder



diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass
index 22a8216..d0b30eb 100644
--- a/eclass/depend.apache.eclass
+++ b/eclass/depend.apache.eclass
@@ -162,6 +162,8 @@ depend.apache_pkg_setup() {
 		else
 			_init_no_apache
 		fi
+	else
+		_init_apache2
 	fi
 }
 
@@ -226,7 +228,9 @@ need_apache2() {
 
 	DEPEND="${DEPEND} ${APACHE2_DEPEND}"
 	RDEPEND="${RDEPEND} ${APACHE2_DEPEND}"
-	_init_apache2
+	case "${EAPI:-0}" in
+	0|1|2|3|4|5) _init_apache2 ;;
+	esac
 }
 
 # @FUNCTION: need_apache2_2
@@ -237,7 +241,9 @@ need_apache2_2() {
 
 	DEPEND="${DEPEND} ${APACHE2_2_DEPEND}"
 	RDEPEND="${RDEPEND} ${APACHE2_2_DEPEND}"
-	_init_apache2
+	case "${EAPI:-0}" in
+	0|1|2|3|4|5) _init_apache2 ;;
+	esac
 }
 
 # @FUNCTION: need_apache2_4
@@ -248,7 +254,9 @@ need_apache2_4() {
 
 DEPEND="${DEPEND} ${APACHE2_4_DEPEND}"
 RDEPEND="${RDEPEND} ${APACHE2_4_DEPEND}"
-_init_apache2
+	case "${EAPI:-0}" in
+	0|1|2|3|4|5) _init_apache2 ;;
+	esac
 }
 
 # @FUNCTION: has_apache


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [tangent] Re: [gentoo-automated-testing] BROKEN: repository became broken!

[Ian Stakenvicius]

> On Jun 17, 2016, at 11:48 PM, Jonathan Callen <jcal...@gentoo.org> wrote:
> 
>> On 06/17/2016 06:22 PM, Ian Stakenvicius wrote:
>>> On 17/06/16 06:17 PM, Ian Stakenvicius wrote:
>>>> On 17/06/16 05:22 PM, Michał Górny wrote:
>>>> On Sat, 18 Jun 2016 00:06:10 +0300
>>>> Andrew Savchenko <birc...@gentoo.org> wrote:
>>>> 
>>>>>> On Fri, 17 Jun 2016 19:42:18 +0200 Michał Górny wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> Since this is a major issue involving a lot of packages, and it needs
>>>>>> to be fixed *quickly*, I'm forwarding the new check results to
>>>>>> gentoo-dev.
>>>>>> 
>>>>>> If the below list contains your package, please fix it ASAP. I will
>>>>>> file bugs for the remaining packages then.
>>>>>> 
>>>>>> Long story short, using := operator inside || () conditional blocks is
>>>>>> completely forbidden and triggers random misbehavior inside package
>>>>>> managers (Portage doesn't do exactly what you think it does).  
>>>>> 
>>>>> Please explain in more details why this is forbidden. man 5 ebuild
>>>>> contains nothing about this, I can't find anything in PMS also. If
>>>>> package manager misbehaves this doesn't automatically imply that
>>>>> ebuilds are broken (and not PM).
>>>> 
>>>> It was explained already. PMS doesn't permit it. It doesn't make *any*
>>>> sense, so the author didn't even bother explicitly saying it's
>>>> forbidden. Package manager can't not misbehave if something can't be
>>>> implemented.
>>> 
>>> Where does PMS not permit it??
>>> 
>>> 8.2: [...]
>>> An any-of group, which consists of the string ||, followed by
>>> whitespace, followed by an open parenthesis, followed by whitespace,
>>> followed by zero or more of (a dependency item of any kind followed by
>>> whitespace), followed by a close parenthesis.
>>> 
>>> 
>>> "dependency item of any kind" would certainly include atoms with slot
>>> operators.
>>> 
>>> 
>>> There is also no caveat at all in 8.2.3 that excludes slot operators,
>>> and 8.2.6.3 also contains no caveat or exclusion of slot operators
>>> from any-of groups.
>>> 
>>> 
>>> Using slot operators within OR deps was intended when EAPI5 was
>>> introduced.  If Portage and other PMs don't handle it well or properly
>>> then they should be fixed, and perhaps the spec should be refined in
>>> EAPI7, but that doesn't mean banning it now.
>> 
>> 
>> Now, one thing that *is* banned is the use of :[SLOT]/[Sub-Slot]
>> values in ebuilds, as per PMS s.8.2.6.3  -- I know there's plenty of
>> ebuilds that are doing that, including in virtuals.
> 
> No, the specific syntax that is banned is ":0/0=" (that is, both a
> subslot and a slot operator).  It is perfectly legal to depend on ":0/0"
> or on ":0=", but not on ":0/0=".
> 

Ah, thank you for that clarification -- I didn't catch the language was 
specifying the subslot as coming before the equal sign.

Well, good that this would be banned given it wouldn't make any sense 
(triggering a rebuild when the subslot changes, while tying something to a 
single slot/subslot value, would never do anything)

[gentoo-dev] [tangent] Re: [gentoo-automated-testing] BROKEN: repository became broken!

[Ian Stakenvicius]

On 17/06/16 06:17 PM, Ian Stakenvicius wrote:
> On 17/06/16 05:22 PM, Michał Górny wrote:
>> On Sat, 18 Jun 2016 00:06:10 +0300
>> Andrew Savchenko <birc...@gentoo.org> wrote:
>>
>>> On Fri, 17 Jun 2016 19:42:18 +0200 Michał Górny wrote:
>>>> Hello,
>>>>
>>>> Since this is a major issue involving a lot of packages, and it needs
>>>> to be fixed *quickly*, I'm forwarding the new check results to
>>>> gentoo-dev.
>>>>
>>>> If the below list contains your package, please fix it ASAP. I will
>>>> file bugs for the remaining packages then.
>>>>
>>>> Long story short, using := operator inside || () conditional blocks is
>>>> completely forbidden and triggers random misbehavior inside package
>>>> managers (Portage doesn't do exactly what you think it does).  
>>>
>>> Please explain in more details why this is forbidden. man 5 ebuild
>>> contains nothing about this, I can't find anything in PMS also. If
>>> package manager misbehaves this doesn't automatically imply that
>>> ebuilds are broken (and not PM).
>>
>> It was explained already. PMS doesn't permit it. It doesn't make *any*
>> sense, so the author didn't even bother explicitly saying it's
>> forbidden. Package manager can't not misbehave if something can't be
>> implemented.
>>
> 
> Where does PMS not permit it??
> 
> 8.2: [...]
> An any-of group, which consists of the string ||, followed by
> whitespace, followed by an open parenthesis, followed by whitespace,
> followed by zero or more of (a dependency item of any kind followed by
> whitespace), followed by a close parenthesis.
> 
> 
> "dependency item of any kind" would certainly include atoms with slot
> operators.
> 
> 
> There is also no caveat at all in 8.2.3 that excludes slot operators,
> and 8.2.6.3 also contains no caveat or exclusion of slot operators
> from any-of groups.
> 
> 
> Using slot operators within OR deps was intended when EAPI5 was
> introduced.  If Portage and other PMs don't handle it well or properly
> then they should be fixed, and perhaps the spec should be refined in
> EAPI7, but that doesn't mean banning it now.
> 
> 
> 


Now, one thing that *is* banned is the use of :[SLOT]/[Sub-Slot]
values in ebuilds, as per PMS s.8.2.6.3  -- I know there's plenty of
ebuilds that are doing that, including in virtuals.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Fw: [gentoo-automated-testing] BROKEN: repository became broken!

[Ian Stakenvicius]

On 17/06/16 05:22 PM, Michał Górny wrote:
> On Sat, 18 Jun 2016 00:06:10 +0300
> Andrew Savchenko  wrote:
> 
>> On Fri, 17 Jun 2016 19:42:18 +0200 Michał Górny wrote:
>>> Hello,
>>>
>>> Since this is a major issue involving a lot of packages, and it needs
>>> to be fixed *quickly*, I'm forwarding the new check results to
>>> gentoo-dev.
>>>
>>> If the below list contains your package, please fix it ASAP. I will
>>> file bugs for the remaining packages then.
>>>
>>> Long story short, using := operator inside || () conditional blocks is
>>> completely forbidden and triggers random misbehavior inside package
>>> managers (Portage doesn't do exactly what you think it does).  
>>
>> Please explain in more details why this is forbidden. man 5 ebuild
>> contains nothing about this, I can't find anything in PMS also. If
>> package manager misbehaves this doesn't automatically imply that
>> ebuilds are broken (and not PM).
> 
> It was explained already. PMS doesn't permit it. It doesn't make *any*
> sense, so the author didn't even bother explicitly saying it's
> forbidden. Package manager can't not misbehave if something can't be
> implemented.
> 

Where does PMS not permit it??

8.2: [...]
An any-of group, which consists of the string ||, followed by
whitespace, followed by an open parenthesis, followed by whitespace,
followed by zero or more of (a dependency item of any kind followed by
whitespace), followed by a close parenthesis.


"dependency item of any kind" would certainly include atoms with slot
operators.


There is also no caveat at all in 8.2.3 that excludes slot operators,
and 8.2.6.3 also contains no caveat or exclusion of slot operators
from any-of groups.


Using slot operators within OR deps was intended when EAPI5 was
introduced.  If Portage and other PMs don't handle it well or properly
then they should be fixed, and perhaps the spec should be refined in
EAPI7, but that doesn't mean banning it now.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] bugs.g.o: Merging UNCONFIRMED & CONFIRMED into NEW

[Ian Stakenvicius]

On 16/06/16 09:47 AM, Michał Górny wrote:
> On Thu, 16 Jun 2016 16:22:32 +0300
> Andrew Savchenko  wrote:
>>  
>> CONFIRMED state is useful, it means that dev or powerful user
>> confirmed this bug and gives it more value. I'd like to keep it.
> 
> Are you saying that bugs that haven't been marked as CONFIRMED have
> less value? Maybe they don't have to be handled at all, unless someone
> you consider more worthy confirms them?
> 

To me it's not about increased or decreased value per se, it's about
workflow:

- An UNCONFIRMED bug I have to reproduce myself and diagnose to
determine if it's really a bug or if it's something else.

- A CONFIRMED bug to me means this has already been done (by myself,
others in the project, or dev's that should know the difference) and I
can skip directly to identifying and fixing the issue.

So when I look at the list of bugs for firefox I know what the state
is more or less for things that are outstanding.  If I have just a
little bit of time to hack away at things I'd rather try to close a
CONFIRMED bug than half-diagnose an UNCONFIRMED one.  Similarly if I
don't have access to my dev system but have plenty of time, I may well
try and triage UNCONFIRMED bugs.

IN_PROGRESS to me is something that should be reserved for when the
fix is ready to go and just hasn't been fully applied or is readily
available to all users (say, the fix is on an overlay for testing) --
I would prefer not to start using that instead of CONFIRMED, but if
that's what the new meaning would be after UNCONFIRMED/CONFIRMED is
merged to OPEN, I guess I could live with it.





signature.asc
Description: OpenPGP digital signature

Re: Facilitating user contributed ebuilds (Was: [gentoo-dev] The future of the Sunrise project)

[Ian Stakenvicius]

On 10/06/16 03:53 AM, Alexander Berntsen wrote:
> ... Their repositories
> would likely be amalgamations of our curated and reviewed
> repositories ...

Could you elaborate on what you mean by this?  When I read it, it
sounds like you're saying people will copy ebuilds/packages from the
core/reviewed repositories into their own, just to have them to
satisfy deps or whatever..

If that's what you mean, then I think many of the comments mentioned
earlier still apply.  I forsee that we'd end up with the type of mess
that binary distros (used to?) have, where the third-party repos
contain various copies of potentially out-of-date and out-of-sync core
packages to satisfy the unique packages they actually want to provide.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] The future of the Sunrise project

[Ian Stakenvicius]

On 08/06/16 08:30 AM, Ulrich Mueller wrote:
>> On Wed, 8 Jun 2016, Dale  wrote:
> 
>> Just a thought here.  Is there a way to do a news announcement for
>> people that have a package installed from the overlay?  If that
>> could be done, then users who don't use it won't be bothered by it
>> but users who do will get the news announcement about its future.
> 
> There can be news items not only for the gentoo tree, but for any
> overlay. Simply place them into metadata/news/ of that repository.
> 
> Conditional display on any "package installed from the overlay" won't
> be possible, though.

A package.mask in the overlay sort of does that...





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 07/06/16 10:19 AM, Ian Stakenvicius wrote:
> On 07/06/16 05:19 AM, Patrick Lauer wrote:
>> On 06/06/2016 04:53 PM, Ian Stakenvicius wrote:
>>>
>>> This -can- be simplified using a REQUIRED_USE to force just-one-of
>>> gtk3,qt4,qt5 , but you can technically do the same with USE=gui too --
>>> all you'd need to do is add dependencies for the no-specific-flag case.
>>>
>>> RDEPEND="...
>>> qt5? ( dev-qt/qtcore:5 )
>>> qt4? ( dev-qt/qtcore:4 )
>>> gtk3? ( x11-libs/gtk+:3 )
>>> gui? ( !qt5? ( !qt4? ( !gtk3? ( dev-qt/qtcore:5 ) ) )"
>> Wow, that is wonderfully horrible, and making me a little bit angry ...
>>
>> So USE="-qt5 gui" enables qt5 in this scenario. How is that reasonable?
>>
>>
>> (And as usual I'm now at the stage where I am not sure what problem that
>> we had before we are actually solving ...)
>>
> 
> I didn't like that particular version either, (A) because of what you
> said, and (B) due to it needing a REQUIRED_USE to enforce a
> just-one-of dependency.  But people don't *LIKE* to have layered
> use-flag logic, so...
> 
s/know/like/ on last sentence




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 07/06/16 05:19 AM, Patrick Lauer wrote:
> On 06/06/2016 04:53 PM, Ian Stakenvicius wrote:
>>
>> This -can- be simplified using a REQUIRED_USE to force just-one-of
>> gtk3,qt4,qt5 , but you can technically do the same with USE=gui too --
>> all you'd need to do is add dependencies for the no-specific-flag case.
>>
>> RDEPEND="...
>>  qt5? ( dev-qt/qtcore:5 )
>>  qt4? ( dev-qt/qtcore:4 )
>>  gtk3? ( x11-libs/gtk+:3 )
>>  gui? ( !qt5? ( !qt4? ( !gtk3? ( dev-qt/qtcore:5 ) ) )"
> Wow, that is wonderfully horrible, and making me a little bit angry ...
> 
> So USE="-qt5 gui" enables qt5 in this scenario. How is that reasonable?
> 
> 
> (And as usual I'm now at the stage where I am not sure what problem that
> we had before we are actually solving ...)
> 

I didn't like that particular version either, (A) because of what you
said, and (B) due to it needing a REQUIRED_USE to enforce a
just-one-of dependency.  But people don't know to have layered
use-flag logic, so...





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] The future of the Sunrise project

[Ian Stakenvicius]

On 07/06/16 05:18 AM, Raymond Jennings wrote:
> On Tue, Jun 7, 2016 at 12:55 AM, Robin H. Johnson  > wrote:
>> 
>> On Tue, Jun 07, 2016 at 09:44:42AM +0200, Dirkjan Ochtman wrote:
>> > On Mon, Jun 6, 2016 at 11:23 PM, Michał Górny > > wrote:
>> > > Your thoughts?
>> > I would agree that proxy-maint and GH pull requests are better than
>> > sunrise, and so we should probably sunset (pun intended) the latter.
>> The new method is better, but that doesn't cover what to do with the
>> 500+ packages in sunrise.
>> 
>> I have found them useful in the past, when I suddenly had a need for
>> something, and there was an ebuild in sunrise that I could adopt into
>> the tree.
>
> How about simply closing sunrise to new packages, and migrate them to
> elsewhere as resources permit?
> 
> Just plugging the spigot and deprecating it would improve things.
> 

Isn't that effectively where we are already at though?  If the last
push was a full year ago, we've pretty well got a closed-tree already.
 I guess we just need to announce it..?

As for what to do with the packages that exist already  what about
adding a p.mask to the repo with a message along the lines of:

"Sunrise has been masked for removal, if you care about this package
please ping its bug on bugs.gentoo.org so that we know it is a
priority for migration"

..or similar?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 04/06/16 01:40 AM, Daniel Campbell wrote:
> On 06/03/2016 09:07 PM, Ian Stakenvicius wrote:
>> On 03/06/16 11:26 PM, Nick Vinson wrote:
>>>
>>> [ Snip! ]  In cases where there's more than 1 option, you have to
>>> either introduce RESTRICTED_USE as Patrick alluded to, or decide a
>>> pecking order (or decide who gets to decide the pecking order).
>>
>>
>> Which dev's already need to do, without USE=gui -- this is not a
>> deviation from the status quo.
>>
>>
>>>
>>> and in that case, it *does* matter what dependencies the gui flag will
>>> pull in.  Even if the user doesn't care, there's no reason for it to
>>> pull in version A when version B is also supported by the package and
>>> every other package with GUI support is using version B.
>>>
>>
>> And USE=gui is not going to eliminate said choices when there are
>> choices between toolkits for a package.
>>
>>>
>>> Some of the proposals on how to handle the case where a package supports
>>> more than 1 implementation (e.g. supports qt and gtk), lead me to think
>>> that the gui flag would inadvertently mask how a package was actually
>>> built and configured. In such a case, troubleshooting is potentially harder.
>>>
>>> If that can't (or won't) happen, you can disregard that paragraph.
>>
>>
>> That can't or won't happen.  NOTHING about the USE=gui proposal turns
>> deterministic things into automagic things.  It's just about
>> restructuring the determinism.
>>
>> Now, as is the case already for packages like this without a
>> REQUIRED_USE line, if a package supports just one of both gtk and qt5,
>> and both flags are enabled, then the package maintainer needs to
>> determine which one takes precedence and the state of the other will
>> be ignored.  This isn't ideal since it can amount to useless rebuilds,
>> but it isn't automagic either.
>>
>>
>>
> You touched on the part that I'm most concerned about: choosing. If the
> 'GUI' USE_EXPAND gets in, do we maintainers check that variable and if
> there's no preference just build whatever? Will we not be expected to
> emit an ewarn or something similar to clarify *why* the package is being
> built a certain way? Granted, if a user has a problem and reports a bug,
> their make.conf's GUI variable should be present in emerge -v output,
> easily explaining the issue.


A pkg_pretend() message would certainly make sense and IMO be a good
idea, but again this isn't any different than the situation as it
stands now WITHOUT a USE=gui.  Regardless I don't see this as a
blocker to the idea.


> 
> It's the implementation that gets me here, not the idea. The idea could
> be neat and make Gentoo management easier at the expense of some
> (hopefully) minor ebuild bloat. Another issue that hasn't been covered
> well yet is how are we going to select DEPENDs? I was told DEPEND
> doesn't support exactly-one-of, and we don't want extraneous dependencies.


...you lost me on this one... You mean use-flag based operators to
select atoms in (R)DEPEND ?  Yeah it doesn't but this isn't an issue
either.  See below:


> Transmission is a good example: supports gtk3, qt4, qt5. Let's say the
> maintainer prefers the qt5 version. Would we do this?:
> 
> DEPEND="gui_qt5? ( dev-qt/qtcore:5 ) gui_qt4? ( dev-qt/qtcore:4 )
> gui_gtk3? ( x11-libs/gtk+:3 )"
> 
> or this?:
> 
> DEPEND="gui_qt5? ( !gui_qt4? ( !gui_gtk3? ( dev-qt/qtcore:5 ) ) )"
> 
> (snipping because I don't feel like writing it all out)


Putting aside what seems to be a USE_EXPAND, for now, since as far as
I know that idea was squashed the day it was introduced on irc...

OK, maintainer prefers the qt5 version as per your assumption, and
because I haven't looked, we'll assume that transmission's gui is
optional.  RDEPEND would most likely be:

RDEPEND="...
gui? (
gtk3? ( x11-libs/gtk+:3 )
!gtk3? (
qt4? ( dev-qt/qtcore:4 )
!qt4? ( dev-qt/qtcore:5 )
)
)"

Note that the -default- doesn't need its own flag, since having qt5
support be wrapped by a qt5 flag doesn't add anything.  Note also that
the deps as they stand now should probably be almost identical:

RDEPEND="...
qt5? ( dev-qt/qtcore:5 )
!qt5? (
gtk3? ( x11-libs/gtk+:3 )
!gtk3? (
qt4? ( dev-qt/qtcore:4 )
)
)"

This -can- be simplified using a REQUIRED_USE to force just-one-of
gtk3,qt4,qt5 , but you can technically do the same with USE=gui too --
all you'd need to do is add dependencies

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 03/06/16 11:26 PM, Nick Vinson wrote:
> 
> [ Snip! ]  In cases where there's more than 1 option, you have to
> either introduce RESTRICTED_USE as Patrick alluded to, or decide a
> pecking order (or decide who gets to decide the pecking order).


Which dev's already need to do, without USE=gui -- this is not a
deviation from the status quo.


> 
> and in that case, it *does* matter what dependencies the gui flag will
> pull in.  Even if the user doesn't care, there's no reason for it to
> pull in version A when version B is also supported by the package and
> every other package with GUI support is using version B.
> 

And USE=gui is not going to eliminate said choices when there are
choices between toolkits for a package.

> 
> Some of the proposals on how to handle the case where a package supports
> more than 1 implementation (e.g. supports qt and gtk), lead me to think
> that the gui flag would inadvertently mask how a package was actually
> built and configured. In such a case, troubleshooting is potentially harder.
> 
> If that can't (or won't) happen, you can disregard that paragraph.


That can't or won't happen.  NOTHING about the USE=gui proposal turns
deterministic things into automagic things.  It's just about
restructuring the determinism.

Now, as is the case already for packages like this without a
REQUIRED_USE line, if a package supports just one of both gtk and qt5,
and both flags are enabled, then the package maintainer needs to
determine which one takes precedence and the state of the other will
be ignored.  This isn't ideal since it can amount to useless rebuilds,
but it isn't automagic either.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 02/06/16 09:48 PM, Nick Vinson wrote:
> On 06/02/2016 08:08 AM, Raymond Jennings wrote:
>> use case:  Telling a package to build a gui without deciding which one
>> to build.  Also helps in cases where you have package A that can only
>> build a qt gui, and package B that can build both qt and gtk, and
>> package C that can build gtk only.  You want to have a gui for all
>> three, but you don't want to hav epackage B build both guis and at the
>> same time while you may prefer qt, you don't want to leave package C
>> without a gui.
> 
> How do you decide which one package B builds in such a case?
> 
> Honestly, I don't think this is a good idea.  The rationale  and
> suggested implementation just don't bring enough benefit in my opinion.
> Often times it's hard enough to research a reported issue with the
> current implementation.  Having a flag like 'gui' whose behavior
> (potentially) changes based on what profile is being used makes things
> considerably harder.  It would no longer be a simple matter of matching
> versions and USE flags, the package maintainer would also need to setup
> an equivalent system with the same profile or research what the 'gui'
> flag with profile 'x' does and setup an equivalent USE flag set.


OK this makes absolutely no sense.

USE=gui is about building the graphical user interface that an
application offers, when it is optional.  That's it.  What
dependencies that means and so on have nothing to do with the flag.
It's the same as USE="server" to build the server daemon for an app
that provides both client and server.

You get that use flags are not supposed to represent dependencies
right, but features of the package??  If you're only able to debug a
build of your package because the flag is called gtk instead of gui,
well...


> 
> Gentoo already has Gnome, KDE, Plasma, and Desktop profiles which mostly
> do the same thing.  The only thing they don't do (as I understand the
> profiles) is enable GUI support for packages that don't support the
> preferred libraries.  Is that really enough justification to implement
> this flag?

Yes.

More specifically, the cleanup of all of those other uses of flags
that are there just to trigger a gui build instead of to indicate a
choice between options, is also enough justification.  Think about a
wayland system -- there's lots of packages that IUSE="X" to build
their gui implementation.  If someone wanting wayland set USE="-X"
then they don't get the gui app even if it'll work in wayland just fine.

Yes, the USE=gui on this hypothetical app may well pull in Xorg libs,
but that's not a reason to keep the flag called "X", because again,
its about the feature of the package *not* the dependency.


> 
> As a maintainer I'd ask that, at the very least, a more compelling
> reason than "it's too annoying to update package.use" is given.  I find
> the argument against putting all the flags in global a valid but weak as
> there are already mitigations for that scenario.   Perhaps I'm missing
> something, but I'm not convinced this will provide a significant enough
> benefit to the average Gentoo user to offset the increased
> troubleshooting demand it'll put on Gentoo's developers, maintainers,
> and proxy-maintainers.


Again, you will very much need to elaborate on what these increased
troubleshooting demands are.  If anything, I see this flag, which will
allow the various tooklit flags to just mean a choice between
toolkits, to make things *easier* for troubleshooting, not harder.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Global USE=gui

[Ian Stakenvicius]

On 02/06/16 05:27 PM, Daniel Campbell wrote:
> To play devil's advocate, can we get a citation on "users don't want to
> care"? Which users? Does Gentoo have a lot of users who don't care, or
> does it attract a more passionate audience that enjoys the control that
> comes with being source-based? I'm inclined to believe the latter, but
> I'm ready to be wrong.
> 

Me. I don't care in 99% of cases.  The only time I do care is when
there's a choice between one or the other.  More specifically, I *DO*
care when I expect to get a gui app installed, but I don't get one at
all, because I didn't have the correct toolkit flag enabled.





signature.asc
Description: OpenPGP digital signature