Re: [gentoo-dev] ironing out release tarballs

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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


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


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

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

Re: [gentoo-dev] EAPI 6 portage is out!

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 18/11/15 02:25 AM, Ulrich Mueller wrote:
>> On Tue, 17 Nov 2015, Michael Orlitzky wrote:
> 
>> It doesn't seem that unlikely to me...
> 
>> 1. Otherwise stable system with package "foo" keyworded as
>> ~arch.
> 
>> 2. foo needs some dependency of a dependency named "bar".
> 
>> 3. The bar maintainer revbumps and removes the old EAPI=5
>> ebuild.
> 
>> I don't really care either way, I'm just wondering whether this
>> is "safe" because it's actually safe, or "safe" because we're
>> gonna do it anyway.
> 
> Actually it is quite simple:
> 
> - The stable tree should not contain any EAPI 6 ebuilds at this
> point, so stable users should not see any change. - Unstable
> users will have a package manager aware of EAPI 6, so all ebuilds
> will be visible for it. - If you mix stable and unstable then you
> are by definition an advanced user, who will be able to cope with
> the situation. :)
> 

And, as a developer maintaining bar in #3 above, you should make
sure that either the stable version satisfies all rdeps (even those
in ~arch), or you don't remove the EAPI5 ~arch version until all the
rdeps are EAPI6.

Theoretically repoman could check for this; i don't know if it's
implemented though or if there are any plans to implement it..
IIRC, confirming removals don't break rdeps is not something repoman
can do unless you run a 'repoman full' on the whole tree (or at
least all the rdeps) yourself.  This really isn't any different from
the case where foo-1.0 has RDEPEND=" =bar-3.0 " and then bar-3.0 is
dropped.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlZMyF8ACgkQAJxUfCtlWe21RAD7Bxku5bXPbQGLcCwgefjJqadB
LA1tSiK0OkCeUKwvtXEBALw4owHTN/cIOZTFgJkx+scKVvH8lefZbQVjTl9w8KlS
=qb2w
-END PGP SIGNATURE-

Re: [gentoo-dev] EAPI 6 portage is out!

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/11/15 05:45 PM, Michael Orlitzky wrote:
> On 11/17/2015 05:09 PM, Michał Górny wrote:
>> Fellow Developers!
>> 
>> I have the pleasure to announce that portage-2.2.25 has just
>> been committed and it comes with complete EAPI 6 support. This
>> effectively means that from this moment forward Gentoo
>> developers are permitted to commit EAPI 6 ebuilds to ~arch.
>> 
> 
> Thanks for all the work on this and the guide.
> 
> Is it really safe to start committing ~arch ebuilds that don't
> work with stable portage? Might not things get wonky for stable
> users who have a few keyworded packages?
> 
> For developers, is my stable version of repoman smart enough to
> make sure I don't break any dependencies in this way?
> 
> 

If your PM doesn't support EAPI6, then those ebuilds will be ignored
just as if they do not exist.  It is plenty safe.  There can be
issues if EAPI5 or older ~arch packages start -needing- EAPI6-only
~arch dependencies, but so long as people are careful (and likely,
start bumping to EAPI6 along with the dependencies) then things will
work out without much incident.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlZLzp4ACgkQAJxUfCtlWe00AAEA5RoB95Z/pvQcqYu+1dDzPh2d
/MP+kcQdHus14B+SnMsBANZubHScfv/9z75lY3Hub3GnamyPLgtSDGyK43UatKBv
=m7RY
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lang/gnat-gcc/

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/15 11:15 AM, hasufell wrote:
> On 09/02/2015 05:06 PM, George Shapovalov wrote:
>> On Wednesday 02 September 2015 16:29:52 hasufell wrote:
 -  >=sys-libs/ncurses-5.7" +   >=sys-libs/ncurses-5.7:*"
>>> This doesn't look correct to me, unless dev-lang/gnat-gcc
>>> doesn't need ncurses headers(?). Only sys-libs/ncurses:0
>>> provides headers (the other slots are for binary
>>> compatibility), so we probably want to depend on SLOT :0. In
>>> addition, if we fix the SLOT to :0, we should do a revbump to
>>> ensure that user VDB is updated correctly.
>> Ah, Ok, thanks for heads up on ncurses (OTOH this is a bit
>> strange - different slots provide not just incompatible but
>> drastically different contents. Shouldn't there be a separate
>> -headers package then? The deps would be kind of more evident
>> in such case..). This was a part of general change to fix
>> repoman complaints. I'll fix the ncurses part and do a revbump
>> to update VDB then..
>> 
>> 
>> 
> 
> Well, it isn't particularly nice, because we don't have proper
> SLOT descriptions (although SLOT can contain any of the
> characters [A-Za-z0-9+_.-], but then I am not sure how the PM
> decides about the "best" SLOT... I couldn't find a useful answer
> in PMS).
> 
> However, this slotting method is already used in libraries like 
> media-libs/libpng or dev-libs/openssl, so it seems it silently
> became a standard.
> 


There's no "best" slot, slots aren't used the same as versions --
they either match or differ.  The slot that's preferred (in portage
at least, i expect other PMs too) is the SLOT of the most recent
version of the package that's emerge'able.

In terms of libraries in general, although the SLOT=0 for full
package version / SLOT=somethingelse for binary-only stuff is a bit
of a convention, you need to check what slotting actually means for
every dependency your package depends on because each one will
differ.  For instance, sci-libs/opencascade installs all versions in
their own specific slot, headers and all.  The choice generally
comes down to what the maintainer of the library package decides to do
.




-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXnIUEACgkQAJxUfCtlWe2TMQEAqwtrleALZNxUeBJzxtilTY19
6+ndXbA0GeY70HpWvdQA/jEB87y+zQoP7J/HMXOZRMHa5bRfwAyZLO8t5VloScyd
=U6d6
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-lang/gnat-gcc/

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/09/15 12:31 PM, hasufell wrote:
>> In terms of libraries in general, although the SLOT=0 for full 
>> package version / SLOT=somethingelse for binary-only stuff is a
>> bit of a convention, you need to check what slotting actually
>> means for every dependency your package depends on because each
>> one will differ.  For instance, sci-libs/opencascade installs
>> all versions in their own specific slot, headers and all.  The
>> choice generally comes down to what the maintainer of the
>> library package decides to do .
>> 
> 
> This is another case where I feel we need better metadata support
> (or at least some documentation policy/standard, so developers
> don't go into pitfalls). With the rise of SUBSLOTs this becomes
> even more a problem, because they also can mean a few different
> things.
> 

Also true..  In theory, subslot changes should just mean an ABI
change that will require a rebuild, but in practice things are a lot
more complicated.  It wouldn't hurt, even in terms of maintainer(s)
keeping track within the package itself, if there was metadata about
this filed somewhere.




-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXnL7UACgkQAJxUfCtlWe1XwwD/TVIFk6dJSYNtsZROduNxCWIN
2F6Al4Pca7rpqyBQ0WcA/0svJX65zA29gucf+Zf6pb9BPbQF/KtyR2VPuXQRj7tE
=Na5Z
-END PGP SIGNATURE-

Re: [gentoo-dev] <>-DEPENDS

[Ian Stakenvicius]

Sent from an iPhone, sorry for the HTML...

> On Sep 7, 2015, at 8:35 AM, Marc Schiffbauer  wrote:
> 
> Hi,
> 
> 
> I'd like to propose a new kind of DEPEND syntax: <>
> 
> This would mean "Any version but the one specified" and is usefull when 
> you have a dependency on another package but a single version of it is 
> not compatible for example.
> 
> I currently have this case in app-backup/obnam which is not compatible 
> to =dev-python/paramiko-1.13.0
> 
> In DEPEND I now have this:
> 
>  !=dev-python/paramiko-1.13.0
>  || ( dev-python/paramiko-1.13.0 )
> 
> which does the trick, but I think much more straight forward would be:
> 
>  <>dev-python/paramiko-1.13.0
> 
> which would be the exact opposite of =dev-python/paramiko-1.13.0
> 
> An alternate syntax would be (but I'd prefer the former):
> 
>  !=dev-python/paramiko-1.13.0
> 
> What do you think and would is the proper way to suggest this for a new 
> EAPI?  A new bug? On what?
> 
> TIA
> -


Why not just:

DEPEND="
dev-python/paramiko
!~dev-python/paramiko-1.13.0
"

Depend on the package but block the individual atom(s) that don't work?

Given that there will be *very few* valid use cases for this type of syntax I 
don't know if it's such a good idea to add it.  I expect adding this new syntax 
would be more likely to cause issues via improper usage than it would add a 
benefit or fill any massively pressing need...

Re: [gentoo-dev] www-client/chromium gtk3 support

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/15 11:48 AM, hasufell wrote:
> On 09/09/2015 05:40 PM, Ian Stakenvicius wrote:
>> 
>> [ Snip list ]
>> 
> 
> There was a tracker on bugzilla about it at some point, but
> people didn't care enough, so I stopped filing bugs. Neither the
> gnome team nor QA had a strong enough opinion to enforce
> consistency here over the whole tree.
> 


Right... So, back to the issue at hand.  If a package -always-
depends on a gtk (usually gtk2), but can optionally be configured to
depend on gtk3 instead (and it should be optional because support
isn't clearly stable yet), what's the solution here?

IUSE="gtk" isn't appropriate because that's meant for enabling
optional gtk support, not choosing -which- gtk to support when there
always needs to be one.  IUSE="gtk3" to me fits well in this case
but it's also reportedly forbidden...
IUSE="experimental-gtk3-support" seems less than optimal but if we
(chromium, mozilla teams) have to go that route I guess we will..

The wiki seems to say that we as rdep maintainers should choose one
and stick with it, but as a mozilla package maintainer, I don't want
to force the entire user base to using one or the other (at least
not yet), given firefox -just- got (that is, will get in two version
bumps) gtk3 support that's considered stable enough for use outside
of development.

I don't suppose we as a community can revisit the decision to ban
IUSE="gtk3" as a flag to toggle between gtk2 and gtk3 support, when
one or the other is -required- by a package?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXwWuYACgkQAJxUfCtlWe25WwD/b8ozgV4zHLyNrIzYI+Cu79+l
gBORP+1q6EMUWyuyVewBAIE3nNFow+XeN67pH4pT6gqQqBJ27VH+bAt9nTprs0pi
=HWeR
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: firefox gtk3 status, danger of gtk2 in-tree deprecation?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/15 06:06 AM, Duncan wrote:
> Paweł Hajdan, Jr. posted on Wed, 09 Sep 2015 09:20:13 +0200 as
> excerpted:
> 
>> A user asked for optional gtk3 support in www-client/chromium: 
>> 
> 
> Talking about browsers and gtk3, I read that binary distros are
> starting to ship firefox built against gtk3, now.
> 
> And with that happened, they'll likely be eager to deprecate
> gtk2, as I think firefox was the big hold-out making that
> impractical.


Firefox's use of gtk3 actually still requires gtk2, so gtk2 won't be
deprecated (at least not any time soon).

Also, FYI, since gtk2 will (for the forseeable future) always be
required by the firefox core, we are going to add a gtk3 flag to
provide end-user control of building the frontend against gtk3 or not.

I don't think deprecation of gtk2 is anything we are going to need
to worry about any time soon.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXwUQcACgkQAJxUfCtlWe1r4QEAwJ4VQLTQhHe9Mx6DocDtkk0k
TXYlocHSXPqrb907jx8BANABAaCToAOPnKchenrMLJxQFh0euC1Ku0ki8H9TwJtu
=p0Fr
-END PGP SIGNATURE-

Re: [gentoo-dev] www-client/chromium gtk3 support

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/09/15 11:16 AM, Alec Warner wrote:
> 
> 
> On Wed, Sep 9, 2015 at 8:10 AM, Alexandre Rostovtsev 
> > wrote:
> 
> On Wed, 2015-09-09 at 11:00 -0400, Mike Gilbert wrote:
>> I would really like a way to toggle gtk3 for testing. If you
>> don't want to expose it as a 'supported' option for users, then
>> masking it sounds fine to me.
> 
> Then add the flag, document it in metadata.xml.
> 
> But in general, try to avoid using this flag in your ebuilds if 
> possible, the gnome team *really* doesn't want to turn gtk3 into
> a global USE flag with uncertain semantics.
> 
> 
> The best way to avoid this IMHO is to not name the flag the same
> thing.
> 
> if you named the chromium flag "experimental-gtk3-ui' or similar,
> then users would be unable to turn it on by just setting 'gtk3'
> 

Is it worth noting that there are dozens of packages in the tree
right now that have a gtk3 flag in IUSE?  Many have 'gtk gtk3'
combinations, and many others have 'gtk3' entirely on their own:

app-editors/emacs
app-editors/emacs-vcs
app-editors/mousepad
app-i18n/fcitx
app-i18n/fcitx-configtool
app-i18n/ibus
app-i18n/ibus-unikey
app-i18n/imsettings
app-i18n/scim
app-i18n/scim-anthy
app-i18n/uim
app-misc/emelfm2
dev-libs/libdbusmenu
dev-python/matplotlib
dev-util/geany
kde-plasma/plasma-desktop
lxde-base/lxdm
mail-client/claws-mail
media-gfx/geeqie
media-libs/libcanberra
media-plugins/audacious-plugins
media-sound/audacious
media-sound/easytag
media-sound/mp3splt-gtk
net-analyzer/pinger
net-dns/avahi
net-libs/gtk-vnc
net-misc/dhcpcd-ui
net-misc/electrum
net-misc/spice-gtk
www-client/dwb
www-client/uget
www-client/uzbl
www-client/vimb
www-plugins/freshplayerplugin
x11-drivers/nvidia-drivers
x11-misc/light-locker
x11-misc/spacefm
x11-themes/light-themes
xfce-base/libxfce4ui
xfce-extra/xfce4-taskmanager

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXwUvcACgkQAJxUfCtlWe3oBgEAvr7nBfDygUPG4MGiK23ya3Xn
RRWLOkprA6SuFjbef84BAJehMtEtt+ZqC3HzGJ5yroM+yCqQE855uQz7+2mpGeyC
=LOpM
-END PGP SIGNATURE-

[gentoo-dev] USE="gui"

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/09/15 01:41 PM, Rich Freeman wrote:
> On Fri, Sep 11, 2015 at 1:11 PM, Duncan <1i5t5.dun...@cox.net>
> wrote:
>> Rich Freeman posted on Fri, 11 Sep 2015 08:13:48 -0400 as
>> excerpted:
>> 
>>> USE=gui or something like that if the main effect is to have
>>> a gui or not. That is the sort of thing that SHOULD go in
>>> make.conf or in a profile. If disabling gtk makes it a
>>> console-only application then use the gui flag.
>> 
>> I like the general proposal, but since it's going to council,
>> can we try to kill another bird with the same stone?  This
>> USE=gui helps...
>> 
>> Wayland's coming, and to the extent that USE=X has previously
>> indicated a GUI, much like USE=gtk and USE=qt indicating the
>> same thing, we're going to have problems.
>> 
>> Can we make USE=gui the generic policy for that, and deprecate
>> more specific forms for choosing /any/ gui, so they can be used
>> for choosing /which/ gui?
> 
> That was exactly why I used "gui" and not "X".  We're going to
> run into the exact same problem once Wayland comes along with the
> way things have been done so far.
> 

So, IUSE="X" has generally been used for gui, but more technically
it's used to depend on and build against x11-libs/* packages.  The
fact that this gives a GUI is practically a side-effect.  When
wayland comes along, do these packages still build against
x11-libs/* to support wayland?

I'm just wondering if we're jumping the gun a little bit on
IUSE="gui"..  yes it'll be nice to have one flag that "just works"
for anyone not caring about the details, but it'll also mean
propagating a slew of REQUIRED_USE=" {X,wayland,gtk,qt4,qt5}? ( gui
)" entries and a lot of extra use-defaults which may or may not
cleanup the sub-profiles of desktop/ 

Also, I believe we need to have the conversation about the pros and
cons of IUSE=gui here before the council meeting, yes?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXzF48ACgkQAJxUfCtlWe0ZQwD8CPt1rOkynOgb/as1gH/u2iYY
Du/EFPwleMDHVgMJDFYBAOfjguA8D1xTPJU9vzsvBf+y4rVFVvvFHuIX8+yyadjD
=SnN3
-END PGP SIGNATURE-

[gentoo-dev] RFC: new function for versionator.eclass

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey all -- i have an idea for a new helper function for
versionator.eclass, that should improve correctness and convenience
when wanting to leverage $REPLACING_VERSIONS for checks in the
related phase functions.

Comments?


diff --git a/eclass/versionator.eclass b/eclass/versionator.eclass
index 74e676e..a92dfa7 100644
- --- a/eclass/versionator.eclass
+++ b/eclass/versionator.eclass
@@ -507,4 +507,27 @@ version_format_string() {
eval echo "${fstr}"
 }

+# @FUNCTION: replacing_version_at_least
+# @USAGE: 
+# @DESCRIPTION:
+# Are all values present in ${REPLACING_VERSIONS} at least version
$1? Uses version_is_at_least
+# and so may not be reliable, be sure to do very careful testing
before actually
+# using this.
+# Returns false if ${REPLACING_VERSIONS} is empty
+replacing_version_at_least() {
+   local tmp want=$1
+
+   case ${EBUILD_PHASE} in
+   pretend|setup|preinst|postinst)
+   if [[ -z ${REPLACING_VERSIONS} ]]; then
return 1 ; fi
+   for tmp in ${REPLACING_VERSIONS}; do
+   if ! version_is_at_least ${want}
${tmp}; then return 1; fi
+   done
+   return 0;
+   ;;
+   *)
+   die "replacing_version_at_least - invalid
phase: ${EBUILD_PHASE}"
+   esac
+}
+
 fi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXzdD8ACgkQAJxUfCtlWe1nZQEAql2yv9bRSCGKdFTAM1dlszua
r1sAO6uV24+bUVvz4aMA/09q12uRea07Vy7I8pXT1w8YvN8EV03Fput8hDbunMHl
=Jkja
-END PGP SIGNATURE-

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/09/15 03:49 PM, Rich Freeman wrote:
> On Wed, Sep 16, 2015 at 3:31 PM, Michał Górny
>  wrote:
>> 2. Dependency changes that don't need to apply immediately 
>> don't need revbump. For example, if foo.eclass raises minimal 
>> required version of a dependency but all packages built so far 
>> will work with the old one.
>> 
> 
> Are we talking about a build dependency or a run-time
> dependency? I don't get why we'd increase the minimal required
> version of a run-time dependency if everything built so far still
> works with the old version.

I'm also concerned with this one.  Bumping version in an eclass so
that the minver that everything -in the tree- needs is correct seems
to me could suddenly make incorrect everything that's currently
emerged up to that change.

That said this might not matter since deps are almost always pushed
up to latest stable/~arch anyways, so perhaps i'm just generally
being more sensitive on this than is necessary.  Definitely, if the
minver was bumped to fix a bug, then imo the eclass needs bumping to
enforce the vdb update.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlX5yR4ACgkQAJxUfCtlWe3BZQD8CPVQ/oEjszqAFtgQzLFKKOSz
3fXRt3ARQE8HHI/jyTwA/jMOnDTTENLs7R/8r2VYYrHIUAv6mrQljuSU2zalJEXY
=S25f
-END PGP SIGNATURE-

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/09/15 02:13 PM, Daniel Campbell wrote:
> How would virtuals be handled with static dependencies?

AFAIK virtuals would need to be handled the same as anything else --
when updating an atom in RDEPEND, the virtual's ebuild needs to be
revbumped.  This would mean that on --update --deep, the new virtual
would get emerged and so the VDB would be updated again with the
proper list of atom(s) that satisfy it.

Same would have to go for eclasses that include dependencies -- any
time an atom changes, the eclass needs to be revbumped and anything
inheriting it also needs to be revbumped (and its inherit line
adjusted).  Of course we may need some well-defined guidelines (if
we don't have them already) on when and how we can remove the old
eclasses.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlX5vjcACgkQAJxUfCtlWe2UiQD/V+w5t64RkYsqFMqYZevlmVH4
01NkXPI0b9NmM4+chSEBANl2HL+KryM5avwa4EDTYbSA11W4IeTVc+lww9MJXn+V
=RZgQ
-END PGP SIGNATURE-

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 16/09/15 04:30 PM, Rich Freeman wrote:
> On Wed, Sep 16, 2015 at 4:17 PM, Michał Górny 
> wrote:
>> 
>> If you modify an eclass, you're responsible for the outcome.
>> Even if means revbumping hundreds of ebuilds for the sake of
>> it. Note that this is the kind of revbump that wouldn't require
>> resetting stable keywords as long as deps are satisfied.
> 
> Ok, so it sounds like there are two eclass proposals out there: 
> 1.  Modify the eclass in place and then revbump all ebuilds that
> use it for which the new RDEPEND matters (the second part of this
> email). 2.  Don't modify the eclass in place, and then update the
> eclass reference and revbump any ebuilds for which the new
> RDEPEND matters, and for the ones that don't matter there really
> is no change since they use the old eclass.
> 
> #1 results in less eclass propagation, but requires mass-commits.
> #2 seems safer and allows the eclass and ebuilds to be modified 
> separately, but still requires lots of ebuild changing.
> 
>> 
>> Runtime. The minver can be raised for developer's convenience
>> -- like when a large number of packages is expected to require
>> a new version soon, and the developers would otherwise have to
>> override the eclass- specified versions. Instead, the eclass is
>> updated and new requirements apply.
> 
> Does not revbumping in this situation actually save us much other
> than the need to do the revbumps themselves?
> 
> If the dependency uses a slot operator then everything is going
> to get rebuilt anyway as soon as the first package comes along
> and triggers an update.  Then again, it does save us a bunch of
> revbumps.
> 

..if the minver is bumped on the atom in the eclass, and the package
is re-emerged without dyndeps, then the existing installed
dependency is considered fine and kept, whereas with dyndeps it
would be upgraded. Is that the only thing we need to be concerned
about?

- - emerge -uD @world would update the dep anyhow

- - emerge -u @world wouldn't rebuild the package if that package
didn't change, and if the package did change then the new dep would
get built.

- - emerge [package] is as above.

So I think I can safely drop my concern.  Care still needs to be
given, certainly, as if the in-tree package isn't revbumped and gets
a patch that only supports the new dep, then suddenly systems will
fail when said package re-emerges.  But that seems bad practice anyhow
.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlX51L8ACgkQAJxUfCtlWe0HYgEAoH7UscWxE4Lgxw+ghFk4EbYY
xYb5XU02Cg9cqh4kH3UBALJGM5sc9K5mFKEDXkiPJva+U4Txeii0MdD4TJpgEBUM
=buWM
-END PGP SIGNATURE-

Re: [gentoo-dev] Introduce ppc64le architecture into gentoo ! please share your comments

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/09/15 08:01 AM, Leno Hou wrote:
> 2. We believe to make Gentoo support ppc64le, we still need to
> compile kernel and bootloader


...usually a gentoo installation requires you to build the kernel
and bootloader yourself, inside of the chroot.  Is this something
that isn't possible?  Or is the requirement related to a live-boot
medium rather than the installation image?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlXy4qwACgkQAJxUfCtlWe2mRAD/esR4zuaVTW4d1DMO43JYUbTe
NJVFMQmzNVnZypHi9k8A/jjm9cB2hvJPCdf6JEnPO6rD1bh8iqByD0DX3NZEpstt
=967P
-END PGP SIGNATURE-

Re: [gentoo-dev] news item: OpenRC 0.18 changes to localmount and netmount

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28/09/15 06:58 PM, William Hubbs wrote:
> Also, we are dropping the use of the -O switch for mount/umount
> -a. This is being dropped because it is util-linux specific and
> not compatible with busybox.

Does this have any actual end-user impact?  AFAIK, using the -O
switch was 'just added' by us originally (i think to reduce the
explicit listing of the different fs types or otherwise simplify the
init script code) right?  I'm just wondering if this paragraph is
actually necessary or not..

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYKoFsACgkQAJxUfCtlWe2XngD/bh/HyUx+K5QTqfq54fdTQ/fd
f8j+lrfrQnvzgAZpTRUA/39eP3NF7mEgyNn+dzgivXa0ucmcC8jtkYdisj8TBorq
=xCLr
-END PGP SIGNATURE-

Re: [gentoo-dev] news item: OpenRC 0.18 changes to localmount and netmount

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 29/09/15 11:10 AM, Ian Stakenvicius wrote:
> On 29/09/15 10:52 AM, Alan McKinnon wrote:
>> On 29/09/2015 16:29, Ian Stakenvicius wrote:
>>> On 28/09/15 06:58 PM, William Hubbs wrote:
>>>> Also, we are dropping the use of the -O switch for 
>>>> mount/umount -a. This is being dropped because it is 
>>>> util-linux specific and not compatible with busybox.
>>> 
>>> Does this have any actual end-user impact?  AFAIK, using the 
>>> -O switch was 'just added' by us originally (i think to
>>> reduce the explicit listing of the different fs types or
>>> otherwise simplify the init script code) right?  I'm just
>>> wondering if this paragraph is actually necessary or not..
> 
>> As a user, that para in the news makes me ask "how does this 
>> affect me?". I have to go read man pages and init scripts to
>> find out.
> 
>> Perhaps this:
> 
>> Also, we are dropping the use of the -O switch for
>> mount/umount -a, because it is util-linux specific and not
>> compatible with busybox. This only affects mounts with
>> "_netdev" listed under options in /etc/fstab. Such systems
>> should use "noauto" and/or "nofail" as described above.
> 
> 
> Exactly my thoughts.  We used -O _netdev within the 'netmount' 
> script to identify which fstab entries are network mounts.  But
> we did it a different way prior to using -O _netdev.  And since
> this isn't actually related in any way to something end-users can
> set in fstab (it has to do with the filesystem type itself) I
> don't see the point in worrying end-users about it.
> 
> I suppose it's worthwhile to note to busybox users that they no 
> longer have to use alternate means of netmounting, as 'netmount' 
> will now work on busybox...?
> 
> Perhaps: " Also, we are dropping the use of the -O switch for
> mount/umount -a, to ensure the localmount and netmount scripts
> are compatible with busybox mount.  If your system uses busybox
> mount please migrate any custom workarounds you may have to the
> openrc localmount/netmount services. "
> 

PS - i still think we should just cut it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYKqoUACgkQAJxUfCtlWe1ijwEAopUzcU8s5btLyojGnoMFRKsR
ecQlbJrTzfPTQhrtzsMA/2pZuBCW8cELoE6Wef10i7ZeZbvxiFAzSHaWKVjwboMk
=nrvu
-END PGP SIGNATURE-

Re: [gentoo-dev] news item: OpenRC 0.18 changes to localmount and netmount

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 29/09/15 10:52 AM, Alan McKinnon wrote:
> On 29/09/2015 16:29, Ian Stakenvicius wrote:
>> On 28/09/15 06:58 PM, William Hubbs wrote:
>>> Also, we are dropping the use of the -O switch for
>>> mount/umount -a. This is being dropped because it is
>>> util-linux specific and not compatible with busybox.
>> 
>> Does this have any actual end-user impact?  AFAIK, using the
>> -O switch was 'just added' by us originally (i think to reduce
>> the explicit listing of the different fs types or otherwise
>> simplify the init script code) right?  I'm just wondering if
>> this paragraph is actually necessary or not..
> 
> As a user, that para in the news makes me ask "how does this
> affect me?". I have to go read man pages and init scripts to find
> out.
> 
> Perhaps this:
> 
> Also, we are dropping the use of the -O switch for mount/umount
> -a, because it is util-linux specific and not compatible with
> busybox. This only affects mounts with "_netdev" listed under
> options in /etc/fstab. Such systems should use "noauto" and/or
> "nofail" as described above.
> 

Exactly my thoughts.  We used -O _netdev within the 'netmount'
script to identify which fstab entries are network mounts.  But we
did it a different way prior to using -O _netdev.  And since this
isn't actually related in any way to something end-users can set in
fstab (it has to do with the filesystem type itself) I don't see the
point in worrying end-users about it.

I suppose it's worthwhile to note to busybox users that they no
longer have to use alternate means of netmounting, as 'netmount'
will now work on busybox...?

Perhaps:
"
Also, we are dropping the use of the -O switch for mount/umount -a,
to ensure the localmount and netmount scripts are compatible with
busybox mount.  If your system uses busybox mount please migrate any
custom workarounds you may have to the openrc localmount/netmount
services.
"





-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYKqe0ACgkQAJxUfCtlWe3v2AD+KNkWk/3lIVa1ws32lPUiP35s
o4GpzFpnUqTuNAlyacgBALpbk3DEBwU6RlRLM8v5xse+4Hd7yOixbisPavoeMzgh
=vuxq
-END PGP SIGNATURE-

Re: [gentoo-dev] LibreSSL import plan

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/09/15 03:29 PM, Anthony G. Basile wrote:
> On 9/30/15 12:18 PM, Ian Stakenvicius wrote: On 30/09/15 07:42
> AM, hasufell wrote:
>>>> * libressl has to conflict with openssl
> Right now libressl exports many of the same symbols as openssl 
> right?  What if it didn't -- that is, we forced a symver map with
> a libressl prefix on all symbols?  That would ensure anything
> built against libressl would not b0rk if openssl was loaded, or
> more specifically, if something else was loaded that was built
> against and links to openssl.
> 
>> Yes you could use symbol versioning, and you can do the side by
>> side by renaming the library but that's a real pita for us
>> since we'd have to hack build systems to link against the
>> correct library name.  Ths should have been done upstream.

Library doesn't have to be renamed as long as it's in a different
path, does it?  If openssl/libssl.so is loaded and none of the
symbols exist due to the symbols expected being 'libressl_*', then
libressl/libssl.so  being loaded will provide the necessary symbols
and not conflict, right?  Or am i missing something subtle here,
like that libressl/libssl.so will never be loaded because the
libssl.so from openssl/ was loaded?

Note in the above i'm specifically not addressing side-by-side lib
installation here and getting rdeps to build against the right ones
- -- just how rdeps use libssl.so if two different ones were installed.

On dealing with side-by-side installation in rdeps, technically
don't we just start filing en masse "use pkg-config" patches to
upstreams?  we could just start doing that now couldn't we?  It's
2015, shouldn't everything be using pkg-config or similar to find
libs by now?


> 
>> @rich0.  Just a side comment.  You said somewhere that maybe
>> apache will choose openssl and postfix libressl and then we'll
>> be in trouble.  No.  The incompatibility is at the abi not api
>> level.  So, for example, some struct size might be different
>> between the two because of internal implementation details, but
>> both should provide a definition of the same struct in their
>> header with the same members. ie. apache should compile against
>> either openssl or libressl and work, you just can't swap out
>> your libssl without recompiling apache which you could do if
>> you had full api compat.


What happens in the case of a proprietary binary package that links
to libssl?  Even if we bundle the libssl.so variant that it needs,
don't we run the risk of the package using the wrong one (esp. in
the case where that package is i.e. dlopen'ed by something else?)

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYNP7YACgkQAJxUfCtlWe3bFAEAtNa6rrLohwL0iQ/I64BaPhnw
HBZiG/I2kwRWOVujDz4A/iivzF8wsG8f84mTLyn9VebGoKHFNgf52bw6erXFD/rT
=jD6F
-END PGP SIGNATURE-

Re: [gentoo-dev] news item: OpenRC 0.18 changes to localmount and netmount

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/10/15 09:41 AM, William Hubbs wrote:
> On Tue, Sep 29, 2015 at 11:13:09AM -0400, Ian Stakenvicius
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> On 29/09/15 11:10 AM, Ian Stakenvicius wrote:
>>> On 29/09/15 10:52 AM, Alan McKinnon wrote:
>>>> On 29/09/2015 16:29, Ian Stakenvicius wrote:
>>>>> On 28/09/15 06:58 PM, William Hubbs wrote:
>>>>>> Also, we are dropping the use of the -O switch for 
>>>>>> mount/umount -a. This is being dropped because it is 
>>>>>> util-linux specific and not compatible with busybox.
>>>>> 
>>>>> Does this have any actual end-user impact?  AFAIK, using
>>>>> the -O switch was 'just added' by us originally (i think
>>>>> to reduce the explicit listing of the different fs types
>>>>> or otherwise simplify the init script code) right?  I'm
>>>>> just wondering if this paragraph is actually necessary or
>>>>> not..
>>> 
>>>> As a user, that para in the news makes me ask "how does
>>>> this affect me?". I have to go read man pages and init
>>>> scripts to find out.
>>> 
>>>> Perhaps this:
>>> 
>>>> Also, we are dropping the use of the -O switch for 
>>>> mount/umount -a, because it is util-linux specific and not 
>>>> compatible with busybox. This only affects mounts with 
>>>> "_netdev" listed under options in /etc/fstab. Such systems 
>>>> should use "noauto" and/or "nofail" as described above.
>>> 
>>> 
>>> Exactly my thoughts.  We used -O _netdev within the
>>> 'netmount' script to identify which fstab entries are network
>>> mounts.  But we did it a different way prior to using -O
>>> _netdev.  And since this isn't actually related in any way to
>>> something end-users can set in fstab (it has to do with the
>>> filesystem type itself) I don't see the point in worrying
>>> end-users about it.
>>> 
>>> I suppose it's worthwhile to note to busybox users that they
>>> no longer have to use alternate means of netmounting, as
>>> 'netmount' will now work on busybox...?
>>> 
>>> Perhaps: " Also, we are dropping the use of the -O switch
>>> for mount/umount -a, to ensure the localmount and netmount
>>> scripts are compatible with busybox mount.  If your system
>>> uses busybox mount please migrate any custom workarounds you
>>> may have to the openrc localmount/netmount services. "
>>> 
>> 
>> PS - i still think we should just cut it.
> 
> What is it that you think we should cut?
> 
> Thanks,
> 
> William
> 

The whole -O _netdev paragraph.  Although i'm willing to cede on
that as I didn't know end users set _netdev in fstab themselves; i
thought it was a property of filesystem types and was entirely
transparent to end-users.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYNQBkACgkQAJxUfCtlWe2p4QEAiJ8bZ5tUPrrHACwXhHZ3wgYj
y57rj2mi2PH4q24cXIUA/3ENCLZcP7ra18T7Tqeo3oWqpjRT2RkT6suyAM/+o42m
=hoyz
-END PGP SIGNATURE-

Re: [gentoo-dev] news item: OpenRC 0.18 changes to localmount and netmount

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/10/15 10:15 AM, Ian Stakenvicius wrote:
> On 01/10/15 09:41 AM, William Hubbs wrote:
>> On Tue, Sep 29, 2015 at 11:13:09AM -0400, Ian Stakenvicius 
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>> 
>>> On 29/09/15 11:10 AM, Ian Stakenvicius wrote:
>>>> On 29/09/15 10:52 AM, Alan McKinnon wrote:
>>>>> On 29/09/2015 16:29, Ian Stakenvicius wrote:
>>>>>> On 28/09/15 06:58 PM, William Hubbs wrote:
>>>>>>> Also, we are dropping the use of the -O switch for 
>>>>>>> mount/umount -a. This is being dropped because it is
>>>>>>>  util-linux specific and not compatible with
>>>>>>> busybox.
>>>>>> 
>>>>>> Does this have any actual end-user impact?  AFAIK,
>>>>>> using the -O switch was 'just added' by us originally
>>>>>> (i think to reduce the explicit listing of the
>>>>>> different fs types or otherwise simplify the init
>>>>>> script code) right?  I'm just wondering if this
>>>>>> paragraph is actually necessary or not..
>>>> 
>>>>> As a user, that para in the news makes me ask "how does 
>>>>> this affect me?". I have to go read man pages and init 
>>>>> scripts to find out.
>>>> 
>>>>> Perhaps this:
>>>> 
>>>>> Also, we are dropping the use of the -O switch for 
>>>>> mount/umount -a, because it is util-linux specific and
>>>>> not compatible with busybox. This only affects mounts
>>>>> with "_netdev" listed under options in /etc/fstab. Such
>>>>> systems should use "noauto" and/or "nofail" as described
>>>>> above.
>>>> 
>>>> 
>>>> Exactly my thoughts.  We used -O _netdev within the 
>>>> 'netmount' script to identify which fstab entries are
>>>> network mounts.  But we did it a different way prior to
>>>> using -O _netdev.  And since this isn't actually related in
>>>> any way to something end-users can set in fstab (it has to
>>>> do with the filesystem type itself) I don't see the point
>>>> in worrying end-users about it.
>>>> 
>>>> I suppose it's worthwhile to note to busybox users that
>>>> they no longer have to use alternate means of netmounting,
>>>> as 'netmount' will now work on busybox...?
>>>> 
>>>> Perhaps: " Also, we are dropping the use of the -O switch 
>>>> for mount/umount -a, to ensure the localmount and netmount 
>>>> scripts are compatible with busybox mount.  If your system 
>>>> uses busybox mount please migrate any custom workarounds
>>>> you may have to the openrc localmount/netmount services. "
>>>> 
>>> 
>>> PS - i still think we should just cut it.
> 
>> What is it that you think we should cut?
> 
>> Thanks,
> 
>> William
> 
> 
> The whole -O _netdev paragraph.  Although i'm willing to cede on 
> that as I didn't know end users set _netdev in fstab themselves;
> i thought it was a property of filesystem types and was entirely 
> transparent to end-users.
> 

Right, so I've learned that I had entirely the wrong idea of what -O
_netdev is for.  So, nevermind on cutting this paragraph and sorry
for the noise.  :)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYNVW8ACgkQAJxUfCtlWe0JwAD+ItJdiwF9rjkaD8u8GBJc3/WU
96R2Z0JZcrefOqvRXXUA/1KW0NEOn7qBy5ius5C8XlvrLE1ccttjmRES71ovV4JA
=sih8
-END PGP SIGNATURE-

Re: [gentoo-dev] OpenRC 0.18 changes -O _netdev

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Since this conversation is now technical rather than news-item
related, I've changed to a new thread.

On 01/10/15 02:17 PM, J. Roeleveld wrote:
> On 1 October 2015 17:49:15 CEST, Mike Gilbert
>  wrote:
 On 28/09/15 06:58 PM, William Hubbs wrote:
> Also, we are dropping the use of the -O switch
> for mount/umount -a. This is being dropped
> because it is util-linux specific and not
> compatible with busybox.
 
>> 
>> The _netdev option is really there to support things like
>> iSCSI, where you are mounting a filesystem like ext4 from a
>> block device which requires network connectivity.
>> 
>> I think some changes are needed here, because this change to 
>> localmount is quite like to break this usage.
> 
> All,
> 
> I had a thought. Not sure if this is possible and if it is, it
> would mean a change to the fstab for people using iSCSI.
> 
> 1) Add an udev rule to name iSCSI devices differently. (Currently
> sd×, maybe to something like scs×) 2) Have 'localmount' ignore
> those entries in fstab. 3) Have 'netmount' (or similar) mount
> those entries.
> 
> I haven't looked into the current scripts yet, so if this doesn't
> make any sense at all, let me know. I will investigate this more
> over the weekend.
> 

At this point, we need to verify the whole reason for its removal is
actually accurate -- it seems it was dropped due to bug 468600,
which is about -O [no]_netdev not being recognized by busybox mount.
 However, there are comments in the bug and notes in busybox
documentation which seems to indicate that -O support has been in
busybox since 1.20.2, and current stable is 1.23.1-r1..  If the
issue is still confirmed, then we can look into alternative methods
of handling iscsi.

Unfortunately, filtering out targets for 'mount -a' based on their
/dev name is entirely not supported by any mount that I know of, so
the method listed above will likely be harder rather than easier to
implement, so I don't think renaming them will be of much use (not
to mention that it would entirely remove the possibility of mounting
based on UUID and similar)




-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYNfocACgkQAJxUfCtlWe3BzwEA1g4oaAP0EITKy0GC0Giq9NAS
XLKHTFNuEObUJNGI38gA/2Xl17ucnvN1TyCd5QZEQ132fOm1jd/e/f9NHDfwNlri
=LOFf
-END PGP SIGNATURE-

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/10/15 02:34 PM, Rich Freeman wrote:
> On Wed, Sep 16, 2015 at 1:09 PM, Rich Freeman 
> wrote:
>> 
>> I'll go ahead and start a tangent on this thread right here.
>> As a first step can we separately consider the proposal to
>> require a revbump anytime a package's RDEPENDS changes?  I'm
>> referring here to directly-specified RDEPENDS, not those
>> inherited from an eclass or virtual.
> 
> Ok, for the purpose of the upcoming council meeting, I'd like to
> make a few separate proposals around dynamic dependencies. There
> are three categories of policies: 1.  RDEPEND changes directly in
> ebuilds. 2.  RDEPEND changes directly in virtuals. 3.  RDEPEND
> changes in eclasses.
> 
> Honestly, I'm not really convinced virtuals need special
> treatment, but I split them off in case it is useful in
> discussion.
> 
> RDEPEND changes directly in ebuilds Proposal 1: Anytime an
> RDEPEND in a non-virtual ebuild is changed, the ebuild must be
> revisioned.  This includes adding/removing inherited eclasses
> which set RDEPENDs.
> 

Seconded, with the exclusion of package renames, as those can be
handled in-place with 'pkgmove' VDB updates.

Slotmove VDB updates *should* be allow slotmove-related changes to
be excluded here too, but unfortunately with portage not doing
updates to rdeps properly, at this time all rdeps will need to be
revbumped when their RDEPEND changes.



> RDEPEND changes directly in virtuals Proposal 2: Anytime an
> RDEPEND in a virtual ebuild is changed, the ebuild must be
> revisioned.  This includes adding/removing inherited eclasses
> which set RDEPENDs.


Seconded; virtuals are empty so its not a big deal here


> 
> RDEPEND changes in eclasses Proposal 3: Anytime an RDEPEND in an
> eclass is changed, the eclass must be revisioned. Proposal 4:
> Anytime an RDEPEND in an eclass is changed, all ebuilds that
> inherit the eclass in the gentoo repository must be revisioned.

This one is trickier to deal with.  For starters, after thread
between yourself and mgorny and I, I think we figured out that there
wouldn't be an end-user breakage from people that have emerged a
package eclass-rdepend'ing on one depset, when that depset is
changed; it just ends up with everyone after the time of the change
needing the new depset.

There are specific cases where the revbump to rdeps will be
necessary (and the eclass itself too, *if* keeping the old eclass
around or differentiating which eclass version is inherited actually
matters):

- - slotmove operations on a dep in *DEPEND
- - the addition of blocker atoms due to the introduction of
conflicting packages
- - the addition of atoms to address implicit dependencies that were
missed before (and weren't in the ebuilds)
- - adjustments to atoms based on changes made to the dependent
package, with the changes now necessary to prevent breakage.  (IE:
useflags changed in-place on a dep and the packages inheriting the
eclass now need to ensure that the new useflag is set)

...there are likely other cases but I can't think of any right now.

At any rate, the point here being that a simple minimum-version-bump
in an eclass RDEPEND does indicate a divergence will occur between
end-user VDB and the repo, but that doesn't necessarily mean it's
something we need to avoid, or rather, we don't necessarily -need-
to enforce convergence between the repo and end-user VDB.


Once we get a bit more hashing out of the above I can try writing up
the complicated proposal(5?,6?) wording...

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF0EAREIAAYFAlYNhJAACgkQAJxUfCtlWe2oXQD2ILHhFlsTJ8FYXbzSROA4hsnE
FGV17l9WmWr31NlrpQD+Iw5tbN/qzeDSZZXXv8/YbXu82IhgB5qK3FZjmxdEEkU=
=hYNh
-END PGP SIGNATURE-

Re: [gentoo-dev] OpenRC 0.18 changes -O _netdev

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/10/15 04:16 PM, William Hubbs wrote:
> On Thu, Oct 01, 2015 at 02:42:15PM -0400, Ian Stakenvicius
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Since this conversation is now technical rather than news-item 
>> related, I've changed to a new thread.
>> 
>> On 01/10/15 02:17 PM, J. Roeleveld wrote:
>>> On 1 October 2015 17:49:15 CEST, Mike Gilbert 
>>> <flop...@gentoo.org> wrote:
>>>>>>>>>> On 28/09/15 06:58 PM, William Hubbs wrote:
>>>>>>>>>>> Also, we are dropping the use of the -O
>>>>>>>>>>> switch for mount/umount -a. This is being
>>>>>>>>>>> dropped because it is util-linux specific and
>>>>>>>>>>> not compatible with busybox.
>>>>>>>>>> 
>>>> 
>>>> The _netdev option is really there to support things like 
>>>> iSCSI, where you are mounting a filesystem like ext4 from
>>>> a block device which requires network connectivity.
>>>> 
>>>> I think some changes are needed here, because this change
>>>> to localmount is quite like to break this usage.
>>> 
>>> All,
>>> 
>>> I had a thought. Not sure if this is possible and if it is,
>>> it would mean a change to the fstab for people using iSCSI.
>>> 
>>> 1) Add an udev rule to name iSCSI devices differently.
>>> (Currently sd??, maybe to something like scs??) 2) Have
>>> 'localmount' ignore those entries in fstab. 3) Have
>>> 'netmount' (or similar) mount those entries.
>>> 
>>> I haven't looked into the current scripts yet, so if this
>>> doesn't make any sense at all, let me know. I will
>>> investigate this more over the weekend.
>>> 
>> 
>> At this point, we need to verify the whole reason for its
>> removal is actually accurate -- it seems it was dropped due to
>> bug 468600, which is about -O [no]_netdev not being recognized
>> by busybox mount. However, there are comments in the bug and
>> notes in busybox documentation which seems to indicate that -O
>> support has been in busybox since 1.20.2, and current stable is
>> 1.23.1-r1..  If the issue is still confirmed, then we can look
>> into alternative methods of handling iscsi.
> 
> The original plan was to move to a point where everyone puts
> _netdev in their fstab for network mounts on Linux so that we
> don't have to track file system types like we do in OpenRC right
> now.  On Linux,
> 
> mount -a -O _netdev
> 
> would mount all network file systems and
> 
> umount -a -O _netdev
> 
> would unmount them.  On busybox, the last time I checked, umount
> -a doesn't support -O at all.
> 

(putting aside the removal of the openrc net-fs list and the need to
require -all- network mounts to need _netdev in /etc/fstab for a while
)

When did you last check busybox?  Indications seem to be that
busybox has received this support a few versions ago.  My quick
'busybox mount -v -a -O _netdev ; busybox mount -v -a -O no_netdev'
seems to indicate it's supported fine with current stable busybox.
So i think this removal can just be rolled back as it's based on
obsolete knowledge.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYNnhcACgkQAJxUfCtlWe20FgD/cm5XssPiKgEoeeCduASjv7Dh
MSq4muIlZKCXgygqFkAA/RQBBwaTe1SxB4eVy3BGm+HVfJxml4pecoI2YNNWugRG
=dG6F
-END PGP SIGNATURE-

Re: [gentoo-dev] Dynamic dependencies

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01/10/15 03:22 PM, Ciaran McCreesh wrote:
> On Thu, 1 Oct 2015 21:11:22 +0200 Kristian Fiskerstrand
> <k...@gentoo.org> wrote:
>> On 10/01/2015 09:12 PM, Ciaran McCreesh wrote:
>>> On Thu, 1 Oct 2015 15:08:00 -0400 Ian Stakenvicius
>>> <a...@gentoo.org> wrote:
>>>> Slotmove VDB updates *should* be allow slotmove-related
>>>> changes to be excluded here too, but unfortunately with
>>>> portage not doing updates to rdeps properly, at this time
>>>> all rdeps will need to be revbumped when their RDEPEND
>>>> changes.
>>> 
>>> This is a severe misrepresentation of what the issue actually
>>> is.
>>> 
>> 
>> Thanks for pointing that out, would you please elaborate on
>> what the issue actually is for the purpose of this discussion?
> 
> Some people expect Portage to do the impossible when handling
> slot moves, on the basis that with a superficial understanding it
> looks like it could partially work in certain easy cases. Thus
> "all rdeps will need to be revbumped when their RDEPEND changes"
> is not an "at this time" thing at all, but a genuine
> requirement.
> 

I think "for the purpose of this discussion" is the relevant point
of K_F's question -- that is, is there a severe misrepresentation on
the need to revbump all ebuilds of rdeps when a package changes its
SLOT= ?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYOi7UACgkQAJxUfCtlWe2LlgD+I6vLjXGDPfq1/ojscXVrMp0A
jUHv4qE6Yl91mTqp1e8A/jWTkKJdqMB8y70jE7LdHZAHIRS4JvpOkW1UEQmHHxwe
=ZOTx
-END PGP SIGNATURE-

Re: [gentoo-dev] LibreSSL import plan

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/09/15 09:11 AM, Rich Freeman wrote:
> 
> Suppose apache uses libfoo and libbar.  Libfoo switches to
> libressl, and libbar sticks with openssl.  That is going to
> create a mess no matter what you do with isolating their
> namespaces, because you're forced to bring it all back together
> and not all software is designed to handle that today (especially
> when you're not using --as-needed, etc).  Flameeyes's blog entry
> keeps coming up: 
> https://blog.flameeyes.eu/2008/06/a-few-risks-i-see-related-to-the-n
ew-portage-2-2-preserve-libs-behaviour
>
> 
That's almost exactly what i had to deal with a while back with the
libjs symbols in firefox vs seamonkey -- firefox was linking to
libsomething (sorry dont remember the name), and libsomething was
built against seamonkey.  firefox's libjs was massively newer than
seamonkey though and so libsomething would end up using the libjs
symbols from within firefox, which was entirely incompatible (and
segfaulting would occur as expected).

The fix in that case was the symver mapping i just described in my
reply to hasufell.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYMDfMACgkQAJxUfCtlWe1OtgD/QvaNGYTqsdbNlMHBkbQ+azrP
CBNpHwEsm32j5yztEXgBAKVG30m1U7UEH9h1g5rNE7aq6Kp0bdOEKjKHZm84VXAF
=9bT/
-END PGP SIGNATURE-

Re: [gentoo-dev] LibreSSL import plan

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/09/15 07:42 AM, hasufell wrote:
> * libressl has to conflict with openssl

Right now libressl exports many of the same symbols as openssl
right?  What if it didn't -- that is, we forced a symver map with a
libressl prefix on all symbols?  That would ensure anything built
against libressl would not b0rk if openssl was loaded, or more
specifically, if something else was loaded that was built against
and links to openssl.

This wouldn't need any rdep patching at all, and would ensure symbol
collisions between the two projects would not occur.  It doesn't
explicitly enable side-by-side installation but it would help ensure
things built for one project wouldn't use symbols from the other's
lib expecting compatibility and randomly fail.

...or am I mis-understanding the major issue with the
libressl/openssl conflict?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYMC3EACgkQAJxUfCtlWe34nwD+N+4s1ZFVLS8CGokYOEa64U6o
EINP0tsAe2EyA/cpy6oBANoIyxf7bfPStLPofV1ZW7/7+z3DsmtSqYztsU6dptmz
=oAIp
-END PGP SIGNATURE-

Re: [gentoo-dev] Team leader(s) election meeting

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 22/09/15 06:12 AM, Alexander Berntsen wrote:
> Friends,
> 
> please set your availability[0] for our next meeting, where we
> will elect team leader(s). We should probably also clear up the
> memberships as most of the members haven't been active in months
> (some have actually never been active at all).
> 
> On a related note this would be a good time for anyone interested
> in contributing to Portage to show up. If you have any questions
> on how to get into Portage hacking, the current team leaders will
> be there to answer your questions to the best of our abilities.
> 
> Please feel free to distribute this email to non-devs that are 
> interested in contributing to Gentoo or Portage. There are
> several other distros using Portage, but we rarely hear anything
> from any of them except for the Google guys every now and again.
> Then there's the matter of our users themselves. Surely it is in
> everyone's interest that this project doesn't stagnate.
> 
> Thanks.
> 
> [0]  
> 

This is the Portage team i assume?  It seems implied but i see
nothing explicit so i just wanted to confirm.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlYBXfIACgkQAJxUfCtlWe1AuwEAgHetp6IZEF7Gcq1DF/Q4EbcJ
Qoj1VnZSC6z7b2t9JzMBAIQX2zgFTwHVk4P46ADByJk8RHAK+Dgi5Ro3gUqlmMqB
=yvyE
-END PGP SIGNATURE-

Re: [gentoo-dev] Always specify SLOT we know a package is compatible with (even if only one SLOT exists at the moment ebuild is added)

[Ian Stakenvicius]

Sent from an iPhone, sorry for the HTML...

> On Sep 19, 2015, at 7:30 AM, Alexis Ballier  wrote:
> 
> On Sat, 19 Sep 2015 12:25:40 +0100
> Ciaran McCreesh  wrote:
> 
>> On Sat, 19 Sep 2015 12:08:21 +0200
>> Pacho Ramos  wrote:
>>> On the other hand, if we start always setting the available slots
>>> that we know to work, we can avoid this issue, and this is also
>>> completely future proof becase I don't think we can assume that
>>> package B will always work with the latest available SLOT package A
>>> can have in the future. Then, applying the same policy of we trying
>>> to set the versions in dependencies to the versions we know are
>>> compatible, we should do the same with the slot.
>> 
>> You know, there's this thing called a :* slot dependency...
>> Originally, the intent was that any dependency which might match more
>> than one slot would explicitly use an operator, and that repoman
>> would enforce it.
> 
> repoman warns when it *does* match more than one slot; maybe it should
> warn when it *might* ?
> 

And how is repo man supposed to know that  :)

I'm having a but of difficulty understanding exactly what the request is in 
this thread.  Rdeps of a package that is slotted (isn't SLOT=0) absolutely 
needs to specify slot or a :* operator.  But for all the packages that are 
SLOT=0, I do not think we should be specifying slot on all the rdeps just 
because some day we might add a new slot.  Especially since we might need to 
change both the old and new SLOT= when we do this.  

And I also see it perfectly acceptable to bump all rdeps when this needs to 
occur.  Although, if we fix "slot move" then this may be less necessary.

Now, adding a ":=" slot operator to rdeps when the package still just has a 
simple/single slot does seem fine to me and makes sense for future proofing.  I 
know some think this isn't a good idea as well though.

Re: [gentoo-dev] RFC: automatically mailing people on pkgcheck problems with their packages

[Ian Stakenvicius]

> On Dec 6, 2015, at 11:52 AM, Rich Freeman  wrote:
> 
>> On Sun, Dec 6, 2015 at 11:09 AM, Michael Orlitzky  wrote:
>> On 12/06/2015 11:00 AM, Michał Górny wrote:
 
 Of course. Add the commit author, too: I want to know if I break someone
 else's package.
>>> 
>>> So far, can't do that since we don't know which commit exactly broke. I
>>> don't want to do any heuristics that could blame the wrong person.
>> 
>> Is the testing performed per-push rather than per-commit? Either way, I
>> would like to get a notification that something broke, even if it wasn't
>> my commit at fault. Just change the word "blame" to "alert" so no one
>> feels slandered.
> 
> ++
> 
> This isn't about shaming people.  It is about alerting that the tree
> is broken.  I think we can agree that when packages don't build it is
> a problem, and it won't fix itself.
> 
> How many commits typically go by in-between checks?  Would it be
> practical to just alert any commit author in that time range?  Sure,
> it would generate a bit of spam, but:
> 
> 1.  Better to get problems fixed sooner than later.
> 2.  The overall improved attention to QA will hopefully reduce the
> error rate and thus make the number of emails regulate themselves.
> 
> One of the first steps towards reducing errors is to increase their 
> visibility.
> 

Couldn't we just alert the people listed in the metadata for the packages 
affected?  Even if it wasn't them that caused the breakage, aren't they 
ultimately responsible for making sure the package works?  They could ping the 
actual committer...

Re: [gentoo-dev] Eclass assisted multilib dependent cache updates

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/01/16 10:54 AM, Gilles Dartiguelongue wrote:
> Hello all,
> 
> while working on bug #518422, I found out that while eclass calls
> the relevant cache updates it has no idea whether or not it is
> called in a multilib context or not.
> 
> Imho, this leads to avoidable human errors where one thinks
> eclass will take care of lib dependent caches, which it does, but
> not for all enabled ABIs which could lead to reduced
> functionality for non-native ABIs.
> 
> While it seems reasonable to call multilib_foreach_abi 
> gnome2_pkg_postinst for multilib enabled ebuilds, it is still not
> ideal as it will call a lot of functions for no good reason. On
> the other hand, checking environment variable set by multilib
> eclasses does not seem like a robust solution.
> 
> Is there any reasonable way to make phase functions aware of if
> they are running in a multilib enabled ebuild to adjust their
> behavior ?
> 

By "phase functions" here, I assume that you are referring to phase
functions exported by the eclass?  In that particular case, AFAIK,
they are never called in a multilib context by default, rather they
are only called within a multilib context when explicitly called
within a multilib_foreach_abi.

Back to the issue at hand, though, likely there would be a way to
leverage 'multilib_is_native_abi' to filter out cases when you don't
want certain things to run.  To do this properly for non-multilib
ebuilds you'll need to make sure that your conditionals won't crash
out if multilib_is_native_abi is undefined, though -- could be a
messy hack...  It would probably make more sense to rearrange the
function(s) internally and perhaps provide two (one for
multilib-build, one not) if the plan is to support ebuilds that
inherit multilib-build AND ebuilds that don't, from the same eclass.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlaKnfMACgkQAJxUfCtlWe0xxQD/S0+QJMqm0qulSR4DAZb4J0uu
RPF53KqIPkuvE0VnL14BAJWscEDyB4Pt9JOEjoiYwNelfDV0frwsgEQVvZu1Ol7Y
=pZVV
-END PGP SIGNATURE-

Re: [gentoo-dev] [EAPI 7] The future goals for PORTDIR, ECLASSDIR and... LICENSEDIR?

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21/11/15 06:29 PM, NP-Hardass wrote:
> Probably not the ideal solution given that you seem to prefer
> removal of such variables, but a REPODIR variable which is set to
> the directory where the repo is (basically making PORTDIR dynamic
> and setting it on a per package basis) could enable developers
> to reference their repo when needed, allowing variable use in a
> multi repo system. Additionally, if that idea is liked, I think
> an array of the repos masters and/or their dirs (or some
> functions to access that information) could also be useful. Like
> get_masters and get_repo_dir functions.
> 

- From your description here REPODIR would only point to the current
repo, so for licence-file access when the license is in the main
gentoo repo, but the current repo is an overlay, it would still fail.

Similar cases could occur for eclasses, especially since 'masters'
in repo metadata allows multiple repos to be chained.

All told, I think i'm in favour of banning the variables, and
potentially providing getter functions that would output the path of
these files if they need to be accessed -- '$(get_eclasspath
[name])' or $(get_licensepath [name]) or the like.  I don't know if
these could be implemented in-eclass or if they would be something
that would have to be added to EAPI7..?



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlZRAu4ACgkQAJxUfCtlWe1r4wEA3bnt0LtExuJCFTFMzZfzoTgl
q+T0eEPvKw0HK3De9rsA/iZZlZ0VKBTErx7mXk4YjiykN9Ruk/ZswkDDSGWM29IW
=JEGh
-END PGP SIGNATURE-

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

[Ian Stakenvicius]

On 02/06/16 03:42 PM, waltd...@waltdnes.org wrote:
> On Thu, Jun 02, 2016 at 09:31:11AM -0400, Damien Levac wrote
>>
>> IMHO, you see this in reverse. the 'gui' useflag would be useful for 
>> users who don't want to care about X/wayland/mir and do not want to care 
>> about gtk/qt, they just want windows to be drawn for the applications 
>> they install -- without, if possible, pulling useless dependencies.
> 
>   How, exactly, will the app draw windows without linking against one of
> X/wayland/mir/qt4/qt5/gtk2/gtk3/fltk or whatever else comes down the
> pike?
> 

The "useless dependencies" is the result of one or more of these
random flags being enabled globally when an end-user just wants to
make sure they get the GUI built for their apps.







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 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 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] [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] 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 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 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

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] [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] gtk/gtk2/gtk3 USE flag situation

[Ian Stakenvicius]

On 27/05/16 10:21 AM, Mart Raudsepp wrote:
> [ Snip! ]


Agree on all other portions above; its the Applications part below
that is most contentious though and is also what I care most about:


> * Applications may only use a gtk2 based stack or gtk3 based stack in a
> given version/revision. gtk3 is strongly preferred when it is deemed to
> not have any regressions compared to gtk2 build, but the choice is
> ultimately with the maintainer. Once the application converts to using
> gtk3 in our distribution, it should try hard to stay that way in
> upcoming versions as well.
> 
> * Some exceptions to the above may exist under heavy consideration,
> especially in cases where the toolkit usage is complex and may have
> some issues for some, but in general gtk3 support is deemed good by
> upstream. Most notable here would be browsers like firefox and
> chromium, which are using gtk dependency more for emulating the theme
> it uses, rather than using it as its real toolkit. If such exceptions
> are allowed, the USE flag naming here must be consistent amongst the
> exceptions. My proposal would be USE=force-gtk2 then, as I have no
> better ideas without stomping on the USE=gtk{2,3} historical meaning.


Personally I don't see an issue at all with maintainers of
applications allowing a package to be built against gtk2 instead of
gtk3 even if gtk3 is deemed "good enough" by upstream.  There are a
number of end-users (myself included) that prefer the gtk2 experience
over gtk3, and so to me I'd like to not limit what app maintainers
want to do, but rather just limit the way they can do it.  The
'force-gtk2' flag to me seems appropriate for this, especially since
this type of choice should explicitly not be linked to a flag in any
profiles (and i believe both gtk2 and gtk3 exist in some profile or
another).


> When arguing in favor of supporting gtk2 builds more for apps, please
> do keep in mind that gtk2 really is pretty much dead. And no, MATE,
> XFCE and others are NOT continuing its support; they are just slow in
> fully converting to gtk3, but they are doing so and I expect both of
> those to be fully done this year, around autumn.
> If the issue is political or just a general gnome3 or gtk3 hate, then I
> would ask you to keep your political opinions or hate outside this
> thread and go contemplate on more important life issues.
> If the issue is lack of themes, then I would like you to help package
> more gtk3 themes. gtk3.20 now has a stable CSS based theme API and
> themes shouldn't be breaking anymore beyond this point, theoretically.
> And gtk3 theme packages should pretty much just be CSS files and some
> metadata. Though we have yet to get over that bumpy thing yet (a main
> reason gtk3.20 isn't in main tree yet).


As to the death of gtk2, well, despite firefox officially adopting
gtk3 as the default in 46.0 there's still a lot of open bugs, some of
which have been around for years, and the other mozilla products have
barely tried to port their UIs over.  I expect it will be 2018 at
least before mozilla doesn't officially need gtk2 anymore.  Dead
upstream or not, I expect there will still be consumers of gtk2 for a
few years yet.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] improper use of X

[Ian Stakenvicius]

On 27/05/16 02:44 PM, rindeal wrote:
> 
> It also clearly shows how is this flag misused:
> 
> dev-python/PyQt4:X - Build bindings for the QtGui module
> dev-python/pyside:X - Build QtGui and QtTest modules
> media-gfx/fbida:X - Install the Motif based image viewer "ida"
> media-video/aravis:X - Build the GTK+-based video viewer for aravis.
> This requires GStreamer and a few plugins but technically not the GST
> plugin for aravis.
> net-irc/quassel:X - Build the Qt 4 GUI client for quassel. If this USE
> flag is disabled, the GUI is not built, and cannot be used. You might
> want to disable this on the server, but you need it enabled on the
> client.
> 

Some of those date back rather far, to when IUSE="X" was effectively
the same as the proposed IUSE="gui".





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] gtk/gtk2/gtk3 USE flag situation

[Ian Stakenvicius]

On 27/05/16 02:23 PM, Mart Raudsepp wrote:
> If gtk2 support is removed though, then per gnome policy gtk3 component
> should come with USE=gtk and per QA policy USE=gtk3.
> 
> The QA policy is not finalized and completely contradicts our side of
> things, hence discussions are needed, but did not conclude.
> This is a thread to continue this discussion, I suppose.
> 

Agreed -- it sounds like gnome and QA need to sit down and come to
concensus, and then we can work out the plan to move forward.

I think as long as the rest of us aren't bound to using only gtk3 if
our packages support gtk2 and we want to maintain said gtk2 support,
we should be fine with whatever decision you two groups come up with.








signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Ian Stakenvicius]

On 02/06/16 11:42 AM, james wrote:
> On 06/01/2016 06:20 PM, Justin Bronder wrote:
>> Due to a lack of time and the fact I don't use any of these packages
>> anymore, they are all up for grabs.
>>
>>  - media-gfx/openmesh [no project]
>>  - sys-cluster/ganglia [cluster]
>>  - sys-cluster/ganglia-web [cluster]
>>  - sys-cluster/torque [cluster]
>>  - sys-cluster/munge [cluster] dependency of sys-cluster/torque
>>  - sys-cluster/mpe2 [cluster]
>>
>> Also, if there's anyone out there using the science overlay and empi
>> who's feeling motivated, that work still needs a champion to get it
>> into the main tree.  If not, I'll probably drop it in a few months
>> and open openmpi and mpich2 to project maintenance as well.  I
>> haven't been involved in HPC for over a decade now, it's time to
>> pass the torch.
> 
> 
> Hello Justin,
> 
> I've been working on cluster ebuilds for a while (Apache Mesos, spark,
> etc). I'm willing to proxy maintain these except torque. Assuming
> there are no users of torque on gentoo (bgo seems inactive...it's
> dead; how would I know?).


I can step up and maintain or co-maintain sys-cluster/torque , I use
it at work and have contributed to it in the past.





signature.asc
Description: OpenPGP digital signature

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

[Ian Stakenvicius]

On 01/06/16 10:13 PM, waltd...@waltdnes.org wrote:
> On Wed, Jun 01, 2016 at 07:56:41PM +0200, Micha?? Górny wrote
> 
>> waltd...@waltdnes.org wrote:
>>
>>>   I see this as at least a redundancy, if not a problem.  First, let's
>>> look at the general case.  An optional "UI" (User Interface) is also
>>> selected...
>>> * via the "tools" useflag 78 times in use.local.desc
>>> * via the "ncurses" useflag 10 times in use.local.desc.
>>> * for a lot of ebuilds via the "ncurses" useflag in use.desc (So why
>>>   does "ncurses" show up in use.local.desc ???)
>>>
>>>  There is no need for an additional "TUI" (Text User Interface) use flag
>>> for these cases.  "tools" and/or "ncurses" tells you enough.  Similarly,
>>> "GUI" is grab-bag of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.  The only
>>> thing they have in common is a hard-coded dependancy on graphics libs.
>>> "GUI" is an implicit dependancy of gtk2/gtk3/qt4/qt5/X/Wayland/whatever.
>>> Using any of them tells you enough.  What do we accomplish by requiring
>>> one more USE flag?  This will also make dependancy resolution of ebuilds
>>> more complex, i.e. slower.  Why?
>>
>> Simple regular users don't want to be concerned with choice of toolkit
>> for every single package, as long as a GUI is provided.
> 
>   Then put one of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk into USE in
> make.conf.  This will *FORCE* a gui where applicable.
> 


The whole point of USE=gui is to get away from needing to do that.
Those flags should be used to choose -which- gui toolkit users want
when one is available, not to choose IF a gui should be built or not.
Take my example into account, i don't want anything qt based if I can
avoid it, but i definitely want wpa-gui.  Right now I only get wpa-gui
if I enable USE=qt4 (or USE=qt5 presumably) on wpa_supplicant.  I'm
not going to set that globally though because I don't want to choose
qt4 based front-ends for anything else, and having to guess for every
random package when i don't care so that I can set a package.use entry
for it is annoying.


>> Furthermore, this matches the recommended USE flag design where the
>> more important flags are provided as feature flags, while specific
>> dependency choice flags are minor.
> 
>   This is going to require *THREE* levels of flags, with the first one
> being totally unnecessary...
> 
> Level 1) GUI
> 
> Level 2) X or xorg or Wayland or Mir
> 
> Level 3) qt4 or qt5 or gtk2 or gtk3 or fltk


1 - USE=gui is for optional gui-or-no-gui, so yes in this scheme its
needed.

2 - If X or Wayland or Mir support is available in a package, then yes
-- also i don't see a way that we don't need these.

3 - toolkit selection choices when a package supports multiple (but
only chooses one) is also a yes.  AND, because we're not tying any-gui
to one of these flags it means that users are free to set just the one
variant that they prefer, globally, instead of having to mess about
per-package.  It also means we can get rid of any or all of these
particular flags from profiles (except for 'gnome' or 'plasma' or the
desktop-variant-specific ones).

The point here is that if there's an app (say, wpa_supplicant as
mentioned before) that provides a gui tool but no options as to what
that tool needs in terms of toolkit etc, we can -just- have USE=gui
control whether or not it's built.  It'll pull in qt because qt is
what it needs, and if someone is dead set against having qt in their
system then they'll know from the dependency tree.  There's no need to
peg the individual toolkit to packages like this just to enable a gui.


> 
>   Let me re-phrase my question... is there *ANY* set of circumstances
> under which any of X/xorg/wayland/mir/qt4/qt5/gtk2/gtk3/fltk USE flag
> can be set for a package *WITHOUT* requiring a gui?  I can see any of X
> or xorg or Wayland or Mir being a requirement for any of
> qt4/qt5/gtk2/gtk3/fltk.  But any of the Level 2 or Level 3 flags *FORCES*
> a GUI of one sort or another.


Likely there is but I'd need to search.  Extending libraries mostly --
cairo, pango etc.. for X vs no-X, avahi for gtk*/qt* ...






signature.asc
Description: OpenPGP digital signature

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

[Ian Stakenvicius]

On 01/06/16 11:19 AM, NP-Hardass wrote:
> On 06/01/2016 10:29 AM, Mart Raudsepp wrote:
>> Hello,
>>
>> So here's something more simple wrt GUI USE flags.
>>
>> Global USE=gui for
>> gui - enable an optional graphics user interface or extra GUI tool
>>
>> Essentially, if it's an optional GUI, it'd be behind a USE=gui, instead
>> of USE=gtk, USE=X, USE=qt4 or USE=qt5, when that optional GUI is
>> available in only one toolkit version. So hence feature based flag, not
>> dependency-based.
>>
> I know that it was previously mentioned that there was discussion about
> this long ago, but I'm not familiar with those discussions. Is someone
> more familiar with those discussions able to bring up the talking points?
> 
> One issue that springs to mind though is, let's say a pkg supports only
> qt4 for a gui, you'd have the gui flag. Upstream adds qt5 support.  Do
> you keep the gui flag and make qt4 and qt5 dependent on it, or do you
> remove the gui flag?  I feel like the latter might lead to confusion,
> while the former suggests that the flag should be used more generally
> than just one toolkit/version being available.

This would be the:

>> There are some other things in the ideas pipeline for when there are
>> multiple toolkit choices, but that's something for a different thread,
>> a different day and more controversial.

...portion. :)




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)

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

[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] New Eclasses: postgres and postgres-multi

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/01/16 11:43 AM, Aaron W. Swenson wrote:
> On 2016-01-13 11:11, Ian Stakenvicius wrote:
>> The work looks really good, but I noticed that postgres-multi 
>> determins the variants to build against based on what's
>> installed on disk via checking eselect..  I think it'd likely
>> be better to instead have proper dependencies based on USE,
>> much like how the python and ABI_* multibuilds work.  That
>> would make the installations as well as the dependencies be
>> determinstic rather than dynamic, which should support binpkgs
>> -much- better (among other things).
>> 
>> The "|| ( postgresql:${SLOT1}= postgresql:${SLOT2}= ...)"
>> RDEPEND that postgres.eclass works out is a little sketchy
>> IMO, unfortunately, as the behaviour that occurs when more than
>> one of those slots are installed is afaik a little unstable --
>> in theory, changes (including removal) of any of the options
>> should trigger a rebuild but I don't know if it does, and I'm
>> fairly certain that a simple --unmerge doesn't trigger a
>> rebuild.  All of that goes away if you perform non-OR
>> dependency via use flags.
>> 
>> The drawback of course is yet another USE_EXPAND, or at least
>> a bunch of rather long use flags, that will need setting by the
>> user.
> 
> What if I made a small adjustment to the DEPEND building like
> so:
> 
> - POSTGRES_DEP="|| (" +   POSTGRES_REQ_USE=" || (" for slot in
> "${POSTGRES_COMPAT[@]}" ; do +IUSE+=" postgres_${slot}" +
> POSTGRES_REQ_USE+=" postgres_${slot}" + + ! use
> "postgres_${slot/_/.}" && continue POSTGRES_DEP+="
> dev-db/postgresql:${slot}=" declare -p POSTGRES_USEDEP
> &>/dev/null && \ POSTGRES_DEP+="[${POSTGRES_USEDEP}]" done -
> POSTGRES_DEP+=" )" +  POSTGRES_REQ_USE=" )"
> 
> I'll have to change from listing the slots in POSTGRES_COMPAT
> from N.N to N_N, but that's not terribly difficult given the one
> ebuild I have it in.
> 
> Is this a change that would require a USE_EXPAND? I know I'll
> have to document the USE flags globally.
> 


A USE_EXPAND isn't necessary, all that provides is a way to group a
set of use flags with a prefix and hide the prefix from end-users
for cosmetic purposes.

As for the patch, you can't determine RDEPEND (ie POSTGRES_DEP)
dynamically like that based on what use flags are being set, in
global scope -- its a runtime vs metadata-generation-time issue.
Changing it to this would work though:


> - ! use "postgres_${slot/_/.}" && continue +  
> POSTGRES_DEP+="
> postgres_${slot}? (" POSTGRES_DEP+=" dev-db/postgresql:${slot}=" 
> declare -p POSTGRES_USEDEP &>/dev/null && \ 
> POSTGRES_DEP+="[${POSTGRES_USEDEP}]" +POSTGRES_DEP+=" )"



The main issue I still saw though was this, in postgres-multi.eclass:

> # @FUNCTION: postgres-multi_pkg_setup # @USAGE:
> postgres-multi_pkg_setup # @DESCRIPTION: # Initialize internal
> environment variable(s). postgres-multi_pkg_setup() { local
> all_slots=$(eselect --brief postgresql list) local user_slot
> 
> for user_slot in "${POSTGRES_COMPAT[@]}"; do has "${user_slot}"
> ${all_slots} && \ _POSTGRES_UNION_SLOTS+=( "${user_slot}" ) done
> 
> elog "Multibuild variants: ${_POSTGRES_UNION_SLOTS[@]}" }


..which, if i'm interpreting correctly, is what causes the postgres
extension to only be installed against what's on disk.  Likely that
should be changed to build the list off of whatever postgres_[SLOT]
use flags are enabled.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlaZL9YACgkQAJxUfCtlWe0sJwD+J6+gPdBLxflwrOmKduu820Kh
psoQz7x3RxR4ZlZn0tcBAIHgwQcUrvac+pXt8YrgdQe1WsUwEhbtq3UEuL00LZBl
=Qr5F
-END PGP SIGNATURE-

Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 15/01/16 12:43 PM, Ian Stakenvicius wrote:
> On 15/01/16 11:43 AM, Aaron W. Swenson wrote:
>> On 2016-01-13 11:11, Ian Stakenvicius wrote:
>>> The work looks really good, but I noticed that postgres-multi
>>>  determins the variants to build against based on what's 
>>> installed on disk via checking eselect..  I think it'd
>>> likely be better to instead have proper dependencies based on
>>> USE, much like how the python and ABI_* multibuilds work.
>>> That would make the installations as well as the dependencies
>>> be determinstic rather than dynamic, which should support
>>> binpkgs -much- better (among other things).
>>> 
>>> The "|| ( postgresql:${SLOT1}= postgresql:${SLOT2}= ...)" 
>>> RDEPEND that postgres.eclass works out is a little sketchy 
>>> IMO, unfortunately, as the behaviour that occurs when more
>>> than one of those slots are installed is afaik a little
>>> unstable -- in theory, changes (including removal) of any of
>>> the options should trigger a rebuild but I don't know if it
>>> does, and I'm fairly certain that a simple --unmerge doesn't
>>> trigger a rebuild.  All of that goes away if you perform
>>> non-OR dependency via use flags.
>>> 
>>> The drawback of course is yet another USE_EXPAND, or at
>>> least a bunch of rather long use flags, that will need
>>> setting by the user.
> 
>> What if I made a small adjustment to the DEPEND building like 
>> so:
> 
>> -POSTGRES_DEP="|| (" +   POSTGRES_REQ_USE=" || (" for slot in 
>> "${POSTGRES_COMPAT[@]}" ; do +   IUSE+=" postgres_${slot}" + 
>> POSTGRES_REQ_USE+=" postgres_${slot}" + +! use 
>> "postgres_${slot/_/.}" && continue POSTGRES_DEP+=" 
>> dev-db/postgresql:${slot}=" declare -p POSTGRES_USEDEP 
>> &>/dev/null && \ POSTGRES_DEP+="[${POSTGRES_USEDEP}]" done - 
>> POSTGRES_DEP+=" )" + POSTGRES_REQ_USE=" )"
> 
>> I'll have to change from listing the slots in POSTGRES_COMPAT 
>> from N.N to N_N, but that's not terribly difficult given the
>> one ebuild I have it in.
> 
>> Is this a change that would require a USE_EXPAND? I know I'll 
>> have to document the USE flags globally.
> 
> 
> 
> A USE_EXPAND isn't necessary, all that provides is a way to group
> a set of use flags with a prefix and hide the prefix from
> end-users for cosmetic purposes.
> 
> As for the patch, you can't determine RDEPEND (ie POSTGRES_DEP) 
> dynamically like that based on what use flags are being set, in 
> global scope -- its a runtime vs metadata-generation-time issue. 
> Changing it to this would work though:
> 
> 
>> -! use "postgres_${slot/_/.}" && continue +
>> POSTGRES_DEP+=" postgres_${slot}? (" POSTGRES_DEP+="
>> dev-db/postgresql:${slot}=" declare -p POSTGRES_USEDEP
>> &>/dev/null && \ POSTGRES_DEP+="[${POSTGRES_USEDEP}]" +
>> POSTGRES_DEP+=" )"
> 
> 
> 
> The main issue I still saw though was this, in
> postgres-multi.eclass:
> 
>> # @FUNCTION: postgres-multi_pkg_setup # @USAGE: 
>> postgres-multi_pkg_setup # @DESCRIPTION: # Initialize internal 
>> environment variable(s). postgres-multi_pkg_setup() { local 
>> all_slots=$(eselect --brief postgresql list) local user_slot
> 
>> for user_slot in "${POSTGRES_COMPAT[@]}"; do has
>> "${user_slot}" ${all_slots} && \ _POSTGRES_UNION_SLOTS+=(
>> "${user_slot}" ) done
> 
>> elog "Multibuild variants: ${_POSTGRES_UNION_SLOTS[@]}" }
> 
> 
> ..which, if i'm interpreting correctly, is what causes the
> postgres extension to only be installed against what's on disk.
> Likely that should be changed to build the list off of whatever
> postgres_[SLOT] use flags are enabled.
> 
> 
> 


I did up a pull request with my change idea; haven't tested it yet
so there may be issues, but i think the diff from the PR would be
easier to understand than the messy code i tried to put in this email.

https://github.com/titanofold/titanofold-gentoo-x86/pull/6
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlaZOeIACgkQAJxUfCtlWe1w1QEAx6jdKVtU0EU0NQvfmiJlDUcJ
LSFq+p+vJ0DUqkcwH1EA/idGolmJC/l5cmKlfVU9QMS1hkZUINHCtAV1202RdDrb
=lkja
-END PGP SIGNATURE-

Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

>> On 12.01.2016 20:22, Aaron W. Swenson wrote:
>>> There are several ebuilds that repeat the same checks and
>>> need to perform the same duties when it comes to working with
>>> PostgreSQL. For example, making sure the users' currently
>>> slot is compatible with the ebuild requirements.
>>> postgres.eclass addresses this and has additional
>>> conveniences to build a dependency string and add a new user 
>>> into the postgres system group.
>>> 
>>> Additionally, as most of you are aware, we have a slot
>>> capable dev-db/postgresql. There is some difficulty that
>>> needed to be resolved so that extensions could also be
>>> installed into multiple slots, which is addressed by
>>> postgres-multi.eclass.
>>> 
>>> I've an overlay at: 
>>> https://github.com/titanofold/titanofold-gentoo-x86
>>> 
>>> With the pgsql-eclass branch containing the eclass and a
>>> postgres-multi enabled PostGIS.
>>> 
>>> Naturally, the eclasses work for me, so far.
>>> 

The work looks really good, but I noticed that postgres-multi
determins the variants to build against based on what's installed on
disk via checking eselect..  I think it'd likely be better to
instead have proper dependencies based on USE, much like how the
python and ABI_* multibuilds work.  That would make the
installations as well as the dependencies be determinstic rather
than dynamic, which should support binpkgs -much- better (among
other things).

The "|| ( postgresql:${SLOT1}= postgresql:${SLOT2}= ...)" RDEPEND
that postgres.eclass works out is a little sketchy IMO,
unfortunately, as the behaviour that occurs when more than one of
those slots are installed is afaik a little unstable -- in theory,
changes (including removal) of any of the options should trigger a
rebuild but I don't know if it does, and I'm fairly certain that a
simple --unmerge doesn't trigger a rebuild.  All of that goes away
if you perform non-OR dependency via use flags.

The drawback of course is yet another USE_EXPAND, or at least a
bunch of rather long use flags, that will need setting by the user.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlaWdzAACgkQAJxUfCtlWe1k9gEAvZZ93mdUhDwTKBxcX+GcrZ5S
bwCQKIkuItSIz0221usA/1rnPt2dGWr9tGMqxekvNypx5RKnF3odSb0m1EVSnTJR
=2xB+
-END PGP SIGNATURE-

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/02/16 07:46 AM, Michał Górny wrote:
> On Mon, 8 Feb 2016 10:08:22 +0100 Patrick Lauer
>  wrote:
> 
>> Ohey,
>> 
>> I've opened a bug at: 
>> https://bugs.gentoo.org/show_bug.cgi?id=573922
>> 
>> The idea here is to change the order of the providers of
>> virtual/udev. For existing installs this has zero impact. For
>> stage3 this would mean that eudev is pulled in instead of
>> udev.
>> 
>> The rationale behind this is:
>> 
>> * eudev is an in-house fork, and there's more than a dozen
>> distros already using it by default that are not us. Which is a
>> little bit weird ...
> 
> That's not an argument. I can also fork random system components.
> Would you consider that a reason to replace the defaults with our
> 'in-house' forks?
> 
>> * Both udev and eudev have pretty much feature parity, so there
>> won't be any user-visible changes
>> 
>> * udev upstream strongly discourages standalone udev (without
>> systemd) since at least 2012
>> 
>> (see for example: 
>> https://lists.freedesktop.org/archives/systemd-devel/2012-June/0055
16.html
>>
>> 
https://lkml.org/lkml/2012/10/3/618
>> )
>> 
>> So it'd be (1) following upstreams recommendations and (2)
>> dogfooding our own tools. I don't see any downsides to this :)
> 
> I'm strongly against this, because:
> 
> 1. It is a conflict-induced fork. As such, it will never be
> merged upstream and it will never be supported upstream. In fact,
> it is continually forces to follow upstream changes and adapt to
> them. eudev is more likely to break because of the Gentoo
> developer(s) working hard to merge upstream changes to their
> incompatible code.

Yes this is true -- however, this claim is based on sys-fs/udev
actually being an upstream package and it really isn't -- it's a
partial package of systemd that upstream really doesn't support as a
separate package anyhow (hence the size and complexity of the ebuild
to build it).

> 
> 2. Many of Gentoo users are programmers who appreciate the
> 'vanilla' API experience Gentoo often provides. Switching the
> defaults to a fork that is known to intentionally diverge from
> upstream goes against that principle. Programs written against
> eudev may not work correctly with upstream udev.

No.  Eudev ensures compatibility with systemd-udev as a principle,
we are not going to fork the API.  Unless upstream decides to do
something with udev that breaks it previous API in an incompatible
way that cannot be reproduced without the rest of systemd, eudev
will retain API compatibility with systemd-udev.  Eudev would not be
nearly as useful as it is, if it wasn't a drop-in replacement for
upstream udevd and libudev.

Besides, now that gudev is its own package there's really just
libudev (rarely changes now), rules.d syntax (afaik hasnt changed
since before the fork), and the support for the builtin's (which we
keep up with) that we need to maintain.


> 3. eudev has fallen behind systemd/udev more than once in the
> past, and caused visible breakage to users this way.


Similarly, in the last 6-12 months eudev's releases have been AHEAD
of sys-fs/udev more than once, too.


> 4. eudev is underdocumented, and the maintainer admits that 'he
> sucks at documenting'. In fact, did anyone even bother to note
> how far eudev diverges from upstream udev to this point?


At this point, WITHOUT the patch applied by USE="rule-generator",
divergence is fairly minimal -- the primary difference is that udev
and libudev contain the internal functions that have been migrated
upstream into the giant libsystemd-common.  Most of the various
improvement patches that we made in the early days have either been
integrated upstream or have been dropped as they are no longer
relevant.  Blueness knows more on this, as I haven't done a thorough
examination of upstream's code in quite a while.


Oh, eudev also doesn't handle network link setup given that external
tools already do this just fine.  That's another difference, though
not one that matters programmatically.  That said, the network-link
setup was added primarily to support systemd's use-case, and there's
very little need or point in having it done by udevd on an rc-based
system.



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAla4u48ACgkQAJxUfCtlWe02JgD+KjY9zpYjh8JZf1gAu3QUahjN
EqtAkPbXZLsELPBuAHgA/Aq2sHQIFg2iKYKow29HXIb43JKUbV96t37m9tUIBBm4
=trQk
-END PGP SIGNATURE-

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/02/16 11:18 AM, Rich Freeman wrote:
> However, I think we're actually missing the bigger issue here.
> Why is this virtual even in @system to begin with?  When I set up
> a chroot or some kinds of containers I don't need udev, or
> sysvinit (or openssh - but let's set that one aside for now).
> 
> We don't stick grub or genkernel or even gentoo-sources in our 
> stage3s.  Why stick (e)udev in there?
> 
> It seems like this should just be another step in the handbook -
> pick your desired device manager.
> 
> Obviously if we produce a boot CD it will need a device manager
> (and kernel and bootloader and network manager), and I don't care
> which one it is.
> 
> This just seems more like the Gentoo way, and it completely
> sidesteps all the controversy over defaults.  We're already
> working on fixing the few remaining functions.sh references so
> that openrc can be removed from the system set as well.
> 

I thought the point of this discussion had to do mostly with what
udev variant gets installed when a user doesn't specify one.  And
AFAIK, since there are still plenty of packages that *DEPEND on
virtual/udev , the discussion's still worth having isn't it?

Besides, if we just move the goal of this discussion from "order of
atoms in virtual/udev" to "order of items in this new Handbook
page", we still need to decide what the default is don't we?



-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAla4ye0ACgkQAJxUfCtlWe0fQQEAhwlNL4UR7OCHwQrIspTJjan0
eRcokUvWl4VSq7BZtjoA/AszQTLuS3AXB4hTB7Vd/fndJ1y+YrbNw1Z+V/pF4tNa
=0G1K
-END PGP SIGNATURE-

Re: [gentoo-dev] python-exec2 C wrapper is looking for a new name!

[Ian Stakenvicius]

On 09/02/16 02:51 PM, Michał Górny wrote:
> Hello, everyone.
> 
> After all those boring, meaningless and violent mailing list threads,
> here's something nice and simple. I'd like to find a new nice name for
> the C wrapper part of python-exec2, and I would like to ask you for
> ideas.
> 
> For some explanation, python-exec2 consists of two wrappers. One of
> them is the 'core' C wrapper that does most of the work. The other is
> a Python script with special shebang that is used to keep
> 'python /usr/bin/foo' working while deferring direct executions to
> the C wrapper.
> 
> The Python wrapper is installed as /usr/lib/python-exec/python-exec2
> and this can't change since everything is symlinked to it. The C
> wrapper is named python-exec2-c (which is an ugly name), and since it's
> used only internally, I can safely change its name to something nicer.
> 
> Any ideas? If possible, I'd like to avoid ambiguity between the two
> wrappers, so the C counterpart would have to be highlighted somehow.
> 

python-exec-cwrapper ?

Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23/01/16 10:51 AM, Ian Stakenvicius wrote:
> 
> 
>> On Jan 22, 2016, at 3:11 PM, Aaron W. Swenson
>> <titanof...@gentoo.org> wrote:
>> 
>> 
>> I would like some feedback on the documentation/comments in
>> the eclass. I'm certain it could be improved. Though, if you
>> were able to follow them (not a slight, just you were the first
>> to follow them), I might have done good enough.
>> 
> 
> I'll have another look; i don't think I read any of the docs,
> just looked to see that PG_CONFIG was set for me and confirmed
> things looked to work the same as multilib-minimal.

OK here's my full review (with docs and all):

postgres.eclass:

postgres_check_slot() <-- #1, not seeing a need for this as
dependencies should be forced now due to USE flag provisions.  #2,
though, the documentation says it should be used in pkg_pretend but
then in the code there's an exclusion to make it a no-op when it's
run in pkg_pretend.  Perhaps it's supposed to be run in pkg_setup??

postgres_new_user() <-- the documentation seems a little bit unclear
on this one..  It looks like it creates the 'postgres' user/group
and optionally it also creates an additional specified user/group..
 But i'm not sure how creating new users/groups here instead of with
calling enewuser/enewgroup directly in the ebuild is helpful per
se...?  It also seems a bit redundant if you wanted to create say, 2
or 3 extra users/groups, to repeatedly call enewuser postgres 


postgres-multi.eclass:

#1 - main description could perhaps be changed from:

# build against any and all compatible PostgreSQL slots that are also
# enabled by the user.

to:

# build and install for one or more PostgreSQL slots as specified by
# POSTGRES_TARGETS use flags.

#2 - POSTGRES_COMPAT , needs an example and/or text to describe the
syntax of the slot specification.

#3 - _POSTGRES_UNION_SLOTS -- you actually mean here the
intersection between the two sets, rather than the union, right?
Var can likely stay as-is but the description should probably be
updated.

#4 - postgres-multi_foreach() -- this actually runs in the builddir,
not the source dir as mentioned in the text.

#5 - postgres-multi_forbest() -- maybe expand on what the "best"
slot is here, ie that it's the lexicographically biggest slot rather
than something else (like, say, the slot that's currently eselected)

#6 - need docs for postgres-multi_src_prepare() and so forth -- just
simple stuff will suffice I think:  postgres-multi_src_prepare()
copies ${S} into a build directory for each target PG_SLOT and
should be specified; the others are default functions that are
provided for convenience, but postgres-multi_foreach should be used
instead of these when customization is necessary.

...and I think that's it..

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlamP+kACgkQAJxUfCtlWe2wAAD/QlCKmkKl/9gr42ggY9RUpvUL
HLT1trvmzvto8QLXLeoBAOWRobPqIU4fcoI0on6CJdeVS+ZEK5MFcdf9qDn3yECA
=VjiJ
-END PGP SIGNATURE-

Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Ian Stakenvicius]

> On Jan 22, 2016, at 3:11 PM, Aaron W. Swenson  wrote:
> 
> 
> I would like some feedback on the documentation/comments in the
> eclass. I'm certain it could be improved. Though, if you were able to
> follow them (not a slight, just you were the first to follow them), I
> might have done good enough.
> 

I'll have another look; i don't think I read any of the docs, just looked to 
see that PG_CONFIG was set for me and confirmed things looked to work the same 
as multilib-minimal.

Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The eclasses look good to go for me -- i've built an ebuild for pl/R
using them and it works as expected (and it's nice to not have to
define PG_CONFIG et. al. myself too).

Can the eclasses be migrated to the tree soon?

Also of note, it will be important to stabilize soon the ~arch
versions of postgresql that have the install_bin path patched;
otherwise if portage is, say, reinstalled with a different python
selection between when postgres is emerged and one of these new
postgres-multi packages are emerged, installation fails.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlaiXiMACgkQAJxUfCtlWe0DUAD/Xj9R3KTYHUBMaXdLioxNtP+N
yzx0Fy3y+eGBpGj0i6wBAOqi/oeRWAOINcl+RNfval46qr2R7Wr9ago2V1eqT+R0
=t7kM
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: rfc: Does OpenRC really need mount-ro

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/02/16 12:30 PM, James Le Cuirot wrote:
> On Wed, 17 Feb 2016 12:19:52 -0500 Rich Freeman
>  wrote:
> 
>> Is dracut still not widely used?  I know that it was all the
>> fashion for a decade or two for every distro to build their own
>> initramfs, but I don't get why anybody wouldn't just make the
>> switch - it is far more capable and configurable.
> 
> Does anyone know what most Gentoo users are doing these days? I
> don't recall the handbook mentioning initramfs at all back in
> 2002 because it wasn't really needed back then. I did without for
> years until I finally put / on LVM. I used lvm2create_initrd for
> a while but that was still quite a manual process and I couldn't
> imagine going back to it now. I've switched to Dracut and it's
> great but I don't get the impression that Gentoo really endorses
> that option over the more laborious ones. Maybe it should?
> 
> https://wiki.gentoo.org/wiki/Initramfs
> 

Genkernel's initramfs generation was what we endorsed for the most
part, until dracut came around.  it's hard to say what "most" are
doing but i expect dracut and genkernel based initramfs's make up
the vast majority in use by gentoo users, with a small minority
rolling their own through other means.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlbEtr0ACgkQAJxUfCtlWe3/xwD+P4OlCY0RuTdGdPWOGRd8ePLi
EvZCZuyp2oxPdYt6xdAA/2CN/Nbgj4bVFa02KeVpuoNOHMErPU4meZfzUjNbGmTH
=iUu6
-END PGP SIGNATURE-

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/02/16 08:46 PM, Nicolas Sebrecht wrote:
> On Mon, Feb 08, 2016 at 11:00:15AM -0500, Ian Stakenvicius
> wrote:
> 
>> Oh, eudev also doesn't handle network link setup given that
>> external tools already do this just fine.  That's another
>> difference, though not one that matters programmatically.  That
>> said, the network-link setup was added primarily to support
>> systemd's use-case, and there's very little need or point in
>> having it done by udevd on an rc-based system.
> 
> Unless I'm mistaken, you're saying that eudev doesn't handle
> network link but it doesn't matter because rc-based systems don't
> requires it.
> 
> And at the same time, I read in this thread that eudev is
> in-place replacement for udev without any harm. What will happen
> to the users wanting systemd AND expect the network link setup?
> 

Systemd requires system configuration differently compared to
openrc and other rc systems.  One cannot expect eudev (or sys-fs/udev)
to be drop-in replacements for systemd and for them to read systemd
configuration.  See
https://www.freedesktop.org/software/systemd/man/systemd.link.html
for more information on network linking, especially the very
systemd-specific config locations.

If someone whats to use both openrc and systemd on the same system,
then they can't have EITHER sys-fs/udev OR sys-fs/eudev installed,
so the point to this particular discussion is rather moot.
Systemd-udev from the systemd package could theoretically read the
network-link config files, assuming that systemd doesn't need to be
PID1 for this to occur; it could very well be, however, that even
when systemd is installed, booting openrc the network link setup
will still need to be configured appropriately outside of these
systemd configs.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAla8uewACgkQAJxUfCtlWe2nBgEAoelTVLQLwhqrrqNFGUncmW3M
iSrWyWSMlKTgeltsNQIBAOjewM3i0enEzhYacRijzmdNkrJdzs5KrYca3Ze1dftw
=1nVy
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: Changing order of default virtual/udev provider

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 10/02/16 12:09 PM, Brian Dolbec wrote:
> On Wed, 10 Feb 2016 10:26:12 -0600 William Hubbs
>  wrote:
> 
> 
>>> Often the decision to procrastinate is a decision that is
>>> rewarded. That should be considered carefully.
>> 
>> + 1.
>> 
>> I also saw another issue that made me shudder. If we change
>> the default to eudev, people who are running separate /usr are
>> going to think they can kill their initramfs's, because people
>> in gentoo conflated the separate /usr and initramfs issue with
>> udev [1].
>> 
>> William
>> 
>> [1] https://bugs.gentoo.org/show_bug.cgi?id=573760#C4
> 
> That isn't a worthwhile reason to procrastinate. IMO we're going
> to get those _ANYWAY_  no matter how long we wait, within reason
> of course.
> 
> There will always be users that can't read/type/whatever and fail
> and file bugs.
> 
> So if we have to wait for one (or more) users to forget about
> the initramfs crud & confusion, we'll be waiting 20 years.  By
> then even systemd will have been replaced by something else...
> 


Yeah I second this -- it was decided officially by council (what, 2
years ago now?) that separate-/usr-without-initramfs doesn't need to
be officially supported anymore, and so if things break that it is
up to end-users to ensure they pick up the pieces.

Although it is likely that eudev *will* keep installation onto / and
out of /usr to help with this not-officially-supported situation in
Gentoo, that doesn't mean the other projects have to stay out of
/usr, and "it worked before the upgrade but doesn't now" certainly
doesn't mean it's a valid bug.  If a user or sysadmin drops their
initramfs when they have a separate-/usr system, any resulting
breakage is on them.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAla74KkACgkQAJxUfCtlWe1cVgD/YCgpgZ9QwN1KXl8G9gPjF3my
dW6YnrV9xzISSYpHQkMA/jDNV5epu4bzWDEmIs0g2hx8qNI3lRHMNvcORRD0lNMi
=nADF
-END PGP SIGNATURE-

Re: [gentoo-dev] Re: usr merge

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/04/16 01:18 PM, »Q« wrote:
> On Sat, 9 Apr 2016 12:09:38 -0400 waltd...@waltdnes.org wrote:
> 
>> On Sat, Apr 09, 2016 at 07:11:31AM -0400, Rich Freeman wrote
>> 
>>> It was simply a recognition that we were already in a state
>>> where booting a system without /usr mounted early can cause
>>> problems.
>> 
>> For certain edge cases... yes.  But they were already using 
>> initramfs or merging /usr into /.  I'm talking about the 95%
>> who don't really need it.
> 
> Booting without /usr mounted early is something Gentoo already
> doesn't support and can't support, right?
> 
> 

It still works for a number of basic cases, but per the Council's
decision quite a while ago, dev's have zero obligation to ensure it
continues to work -- in effect this means it can break at any time.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcLstQACgkQAJxUfCtlWe2I+AEAyVX2Zh8YDbbCfTtCJ8C3Y1Gk
8OX3on1uKDCFeybThAgA/3g/uI2WyPhdayARsNNGQuX8tD+ejv/mpZjY2UUJPSpv
=3e1w
-END PGP SIGNATURE-

Re: [gentoo-dev] pokit (was: usr merge)

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/04/16 10:33 AM, M. J. Everitt wrote:
> I'll come back to the links a bit later, but is policykit and
> its predecessor/derivatives now a mandatory part of a linux
> system?
> 
> Possibly crossing posts here, so apologies in advance .. ! :]
> 

polkit is only required/mandatory AFAIK in relation to dbus, which,
at least for now and at least for non-systemd systems, is also
technically optional.  And even within a dbus-managed environment
I'm not sure if it's absolutely mandatory, tbh.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcHxTAACgkQAJxUfCtlWe1gfAEAi6++jBTDblAA8K3GOZj05lZI
1iN9xSjIZ1uSpqIUKtAA/1liMQleuZTWyCGbw0IIFNt+ELeIUu0RUoBKSnH3DIN5
=YEAz
-END PGP SIGNATURE-

Re: [gentoo-dev] usr merge

[Ian Stakenvicius]

> On Apr 8, 2016, at 8:42 PM, William Hubbs  wrote:
> 
>> On Fri, Apr 08, 2016 at 03:20:24PM -0700, Daniel Campbell wrote:
>> Based on what I've read here in the thread, merging /bin and /sbin
>> into /usr/{sbin,bin} is a matter of convenience by putting most of the
>> static parts of a running system into a single path. As mentioned by
>> some people, however, that's not enough to make deployment across
>> multiple machines super simple. The distros that focus on that aren't
>> rolling release like we are, and thus don't face the same difficulties
>> that we do. In addition, Gentoo supports a broad number of choices for
>> users and some are advocating for an option.
> 
> It is true that we offer a high degree of choice to users, but one of
> those choices is not which paths to install binaries and libraries
> into.
> 

Sure we do.  Users can do pretty much whatever convoluted file system hierarchy 
layout they want prior to unpacking the stage3 -- multiple volumes, symlinks or 
bind-mounts to combine dirs, etc etc.  

IMO support for this usr-merge should be left to that level of system 
configuration, as long as portage/other PMs support installing packages in such 
a way that the contents of /bin and /usr/bin don't collide with each other at 
merge time.

In other words, we should not drop any form of support at all for 
non-usr-merged systems.  Which means all of that ebuild cleanup WilliamH wants 
to do cannot happen.  Which, IMO, makes the whole thing moot.

Re: [gentoo-dev] Re: [gentoo-project] Portage repo usage survey and change evaluation

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/03/16 03:50 AM, Ulrich Mueller wrote:
> How is it possible that we have 52 MiB of ChangeLog entries
> generated in the 0.5 years since the git conversion, whereas we
> had only a total of 103 MiB in the 13.5 years since ChangeLogs
> were introduced in 2002? Certainly our commit rate hasn't
> increased by more than an order of magnitude in the last half
> year?
> 

The content of a changelog entry from git is a lot bigger than it
was just from echangelog, isn't it?

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlbXI4kACgkQAJxUfCtlWe2gJwEA6EDRDBa94PuopiPc7lP/GAyw
cTyWHzPznQpUGyMPXHsBAMQi+EluVkEkf6ilttjXw+XMqi//C0QyaT1jRhvRAprL
=nIHW
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/04/16 03:18 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent
> Fredric:
>> On 21 April 2016 at 06:38, Ian Stakenvicius <a...@gentoo.org>
>> wrote:
>>> Well so far the only needs I have run into for the win32 flag
>>> has been in relation to choosing UI toolkit support for cairo
>>> and gtk+ (and possibly others in the future), which is why I
>>> saw the parallel.
>> 
>> 
>> Given you're not using the flag to indicate "works on win32" as
>> such, but instead "compile using Win32 Widgets instead of
>> something else", wouldn't a better name indicate that somehow?
>> 
>> The simplest thing I can think of that clears this confusion is
>> a few extra characters:
>> 
>> "win32gui", "win32ui"
>> 
>> Or something along those lines.
>> 
>> It doesn't require us to know what the exact binding keywords
>> in microsoft terminology is used, and it clearly communicates
>> "This is something to do with User Interfaces" as opposed to
>> "Just linking/compiling slightly differently".
> 
> win32 is what the base API seems to be called all over in the
> wild. The GTK+ configure flag is also --enable-win32-backend in
> gtk3 and --with-backend=win32 in gtk2 (didn't personally check
> the latter). Note that gtk configure actually also tracks
> platform_win32 and os_win32 in there, which are different things
> (and just configure.ac internal names). Former is true when host
> contains mingw, latter when host contains mingw or cygwin. When
> win32 gdk backend is enabled (which the propose USE flag would 
> do), then it will depend on a matching cairo backend of that, to
> be able to do its own drawing on Windows. There's actually some
> stuff about pangowin32 as well, not sure Ian has noticed that
> yet.
> 
> The GDK win32 backend uses what is called the win32 API. See e.g 
> https://en.wikipedia.org/wiki/Windows_API#Versions For example a
> GdkWindow is created via CreateWindowExW, root of that 
> documentation is apparently at 
> https://msdn.microsoft.com/en-us/library/windows/desktop/ff818516(v=
vs.85).aspx
>
>  It doesn't use the Windows API higher level UI stuff, like
> wxWidgets does, but only the low-level stuff, and then emulating
> the themeing as best as it can right now, like Qt does. So in
> that way win32gui might be misleading. win32 or win32api or
> winapi or I dunno.


USE="winapi" is likely a better flag name, if others agree (and also
agree to the necessity of the flag) then I'll switch to that.


> 
> Theoretically you can also build this stuff for consumption with
> wine. Or maybe ReactOS? Basically the only real point I have is
> that anything kernel_* to control this probably doesn't make
> sense.


I can confirm what I've built with my mingw-crossdev works under
wine; no idea on ReactOS but I don't see why it wouldn't.  That
said, I expect anything built to run on a 'kernel_Winnt' would run
on both anyways so I may well have undone your point. :)


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcX134ACgkQAJxUfCtlWe1g1gD9GlVY1GlsHSkOhBtR3RTJKpqp
pgE3HtSptJpb9gz7zQoA/21XSnNGzs3+/UOagD+R3pRe5cHaUGRSv8m0MN7wAcYF
=4Uoi
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Ian Stakenvicius]

On 20/04/16 03:41 PM, Anthony G. Basile wrote:
> On 4/20/16 3:30 PM, Ian Stakenvicius wrote:
>> On 20/04/16 03:01 PM, Anthony G. Basile wrote:
>>
>>> The way I think of it is
>>
>>> the operating system (ie kernel) = kernel_Winnt the system
>>> libraries (=~libc)= elibc_Winnt the executable binary format
>>> = win32
>>
>>> I don't know that we need an executable binary format flag, but
>>> we might because they're working on windows 10 so it can natively
>>> run ELF.
>>
>>
>>
>> According to 'file' the binary format is actually "PE32 executable
>> (console) Intel 80386, for MS Windows" for a random *.exe file in my
>> /usr/i686-w64-mingw32/usr/bin
>>
>> I assume PE32 would be the label one would use if comparing to ELF ?
>>
> 
> yes and while it is reported by `file` as PE32, it is sometimes referred
> to as just win32.  its proper name, if i recall correctly is "Win32
> Portable Executable File Format".  it is the equivalent of ELF, COFF and
> a.out in the Linux world and Mach-O in the Mac world.  basically its the
> format the linker/loader is looking for.
> 
> if i've understood the plans for windows 10, its kernel will be able to
> link/load native ELF and execute Linux system calls, at least for amd64
> arch/abi.  I saw a demonstration with ubuntu userland, but i'm sure it
> will be able to handle gentoo.  with gentoo portage in there, i think
> we'll expand in to a whole new market.
> 
> not meaning to steal your thread, but i think keeping the namespace
> precise here will help us avoid collisions in the future.
> 
> 

Right, so a +1 for USE="winapi" then?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/04/16 03:01 PM, Anthony G. Basile wrote:
> 
> The way I think of it is
> 
> the operating system (ie kernel) = kernel_Winnt the system
> libraries (=~libc)= elibc_Winnt the executable binary format
> = win32
> 
> I don't know that we need an executable binary format flag, but
> we might because they're working on windows 10 so it can natively
> run ELF.
> 


According to 'file' the binary format is actually "PE32 executable
(console) Intel 80386, for MS Windows" for a random *.exe file in my
/usr/i686-w64-mingw32/usr/bin

I assume PE32 would be the label one would use if comparing to ELF ?


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcX2OEACgkQAJxUfCtlWe1mQQD/QrwFeMpuh0spKgwmA7d5Khhw
LpZ1RFtG2anVsyMrYn0A/Rmde/6Tw2ufvARI2+nCnKShVxDtrU3JbREr2KYrnLYI
=Cja7
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Ian Stakenvicius]

On 21/04/16 11:31 AM, Mart Raudsepp wrote:
> Ühel kenal päeval, K, 20.04.2016 kell 22:18, kirjutas Mart Raudsepp:
>> Basically the only real point I have is that anything kernel_* to
>> control this probably doesn't make sense.
>>
> 
> Oh, just to clarify and avoid misunderstanding:
> I did not intend to ack the changes to gdk-pixbuf and gtk+ with my
> message, even if the flag name is changed.
> It sounds to me like we have some refactoring to do in those ebuilds
> together with aqua in mind as well, once we have agreed on the future
> global USE flag name.
> I also vote 'no' to the profiles changes, because we don't have 6+
> packages with the flag yet to make it global use flag quite yet (though
> it would make sense once we do, and in essence it is a global one that
> needs masking in other profiles, etc - fiddly with local use flag).
> 
> Once this thread has concluded on a naming, I'm sure we can have a
> productive gtk/gdk-pixbuf review via IRC :)
> 
> 
> Mart
> 


Ok, so to summarize:

a) +1 for a USE flag instead of KERNEL/ELIBC (that's 4 in favour, 2
against i think?)

b) -1 for making it global right now pending resolution of logistics
for the profiles/base/use.mask entry,

c) rejection for the proposed ebuild patches pending a toolkit
refactoring to be determined later.


B and C make most of this thread pretty well moot, I guess, but
following A, can we decide that USE="winapi" could be a good flag
name?  If nobody objects I'll use that when leio and I work on the
refactoring of gtk+ and likely try to use local flags somehow for now.









signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New GLEP: file installation masks

[Ian Stakenvicius]

On 20/05/16 11:49 AM, Michał Górny wrote:
> On Fri, 20 May 2016 11:40:39 -0400
> Michael Orlitzky  wrote:
> 
>> On 05/20/2016 11:34 AM, Daniel Campbell wrote:
>>>
>>> ...and the user has this in their install.mask file:
>>>
>>> [bash-completion]
>>> path=/some/other/path
>>> desc=some other description
>>>
>>
>> I don't think that's allowed; the groups are specified by each
>> repository's metadata/install-mask.conf, not by the users.
>>
>> Although, you can ask the same question about overlays that have
>> group-name clashes. Is that an error, or would we use the one from the
>> overlay?
> 
> Oh, you are correct. Originally I planned to handle that, and I forgot
> about it.
> 
> Since there can be multiple paths, we have two options: either
> override, or amend like systemd does with *.d files. I think the former
> would be less surprising.
> 
> Override is simple -- entry from next file overrides previous,
> and discards all data.
> 
> Amending is harder. Description from next file overrides former, but
> paths are appended. But there is special 'path=' (empty) that discards
> all previous values and starts over. I don't think that's really a good
> idea for repos.


I'd vote override, simply because it would match the same behaviour
seen with eclasses and we could leverage the same 'masters =' in
repos.conf to manage order when dealing with multiple repos.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] ebuild-writing/variables: better describe ROOT

[Ian Stakenvicius]

On 10/05/16 05:25 PM, Michael Orlitzky wrote:
>   * dmraid does
> 
>   einfo "Appending pkg.m4 from system to aclocal.m4"
>   cat "${ROOT}"/usr/share/aclocal/pkg.m4 >>"${S}"/aclocal.m4 || \
> die "Could not append pkg.m4

I'm pretty sure dmraid was me, and that code likely predates EPREFIX
(despite whatever the EAPI= says in dmraid's ebuild).  I'll fix /
revisit that one soon.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re : Cannot see my eclass modifications

[Ian Stakenvicius]

> On May 3, 2016, at 5:42 PM, Farid BENAMROUCHE  wrote:
> 
> Hi,
> 
> I'm still searching for the reason why I'm not seeing my eclass 
> modifications... no luck so far.
> 
> What can I do to debug portage's behavior?
> 
> Thank you
> 
> 
> En date de : Sam 30.4.16, Farid BENAMROUCHE  a écrit :
> 
> Objet: Re : Cannot see my eclass modifications
> À: gentoo-dev@lists.gentoo.org
> Date: Samedi 30 avril 2016, 20h03
> 
> Hi all,
> 
>  I'm currently developping a patch for user.eclass, but I'm
>  banging my head against a wall...
> 
>  So for testing first, I've setup an overlay, and I now
> that
>  it is taken in account by portage (If I rename portage's
>  user.eclass, emerge is still working. If I remove my
>  overlay, emerge complains about missing user eclass. So my
>  overlay is actually working)
>  I've modified enewgroup and egetent for example and put
> some
>  einfo and also modified some other stuffs to be sure that
>  I'm entering the function
> 
>  Then emerge sys-power/nut, I can see the pkg-setup traces,
>  just after the call to enewgroup... but still cannot see
> my
>  eclass modifications!
>  I tried to modify directly the
>  /usr/portage/eclass/user.eclass file, but still the same
>  issue...
>  I'm totally puzzled about this point! I'm most likely
>  missing a stupid point somewhere...
> 
>  Anyone knows what could be the problem? Please let me know
>  what traces/info you need and I will post them.
> 
>  Thank you!
> 
> 


You can't override the eclass used by ebuilds in another repo by default.  You 
have to  edit /etc/portage/repos.conf/gentoo.conf and adjust a setting.  Man 
portage or googling about repos.conf should provide more info.

Re: [gentoo-dev] Is X86 uclibc environment supported?

[Ian Stakenvicius]

Quote: blueness:
> 
> The big problem is going to be the migration.  You can't just unmerge
> uclibc and emerge uclibc-ng.  The two hard block one another for that
> reason.  The migration path I took is really really dirty but works:
> 
> 1. ebuild uclibc-ng-.ebuild clean install
> 3. Copy .so files from /var/tmp/portage/.../image/lib to /lib
>   Since the .so versions are different they won't overwrite.
> 4. Use a static binary to switch over the sym links to the new .so's
> 5. emerge uclibc-ng properly
> 6. re-emerge world
> 
> I can automate some of that with scripts, but it will take care on the
> part of the user who should be ready to boot off of rescue media.  I'm
> going to recommend that people really avoid that if possible and start anew.
> 

What about a "unclibc-ng-migrator" ebuild that would do steps 1,3,4 above if 
uclibc-ng isn't installed yet, and be a no-op otherwise? This could be a dep of 
uclibc-ng, and not hard-block uclibc.  A bit hackish but emerge would probably 
enforce the order of things ok with deptree resolution.

Re: [gentoo-dev] Reminder: ALLARCHES

[Ian Stakenvicius]

On 04/05/16 02:01 AM, Kent Fredric wrote:
> On 4 May 2016 at 16:46, Matt Turner  wrote:
>> Having built many stages for an "unstable" arch (mips) has taught me
>> one thing: it's awful being unstable-only. There's no end to the
>> compilation failures and other such headaches, none of which have
>> anything at all to do with the specific architecture.
>>
>> Short of adding a middle level ("stable, wink wink nudge nudge") where
>> things at least compile, I think the current situation is actually
>> significantly better than the alternative of dropping them to
>> unstable.
> 
> I feel like there needs to be something inbetween, a mechanism where
> things can be deemed "tentatively stable", where in they can still be
> later destabilized if evidence compels it.
> 
> As it is, stabilization seems one-directional. If critical defects are
> found in "stable" releases, they tend not to escalate in the other
> direction.
> 
> And I understand why that is, but it doesn't stop me wishing otherwise.
> 
> But instead of adding a rung between stable and unstable ... maybe the
> right approach is to add a layer /beneath/ stable : "Long term
> stable".
> 
> Where long-term stable is "Known to be good at a deep and thorough
> level by people who use the software regularly".
> 
> Long-term stable at this point is not something I'd suggest people set
> as their keywords in general, but it would be a thing that would only
> be granted to specific packages on a case-by-case basis, and it would
> only be encouraged to be used in the sense of
> /etc/portage/package.keywords , where mixing long-term stable and
> stable would be "supported" ... somehow.
> 
> IDK, there's still a lot wrong with my ideas, but hopefully there's
> some ball here to run with.
> 
> 


Rather than adding a third layer of stability and splitting the
userbase even further, how about we just be less shy about dropping
stable keywords on packages back to ~arch when we have bugs that can't
be resolved quickly?  I know this isn't ideal given everyone --sync's
at different times and varying intervals, but if a particular ebuild
gets stabilized on an arch and is found to really not be ready at
least there's a recourse to undo the stabilization and stop -some-
users from getting the new version via their -uDN @world updates.

What might we need in terms of better PM support, for stable -> ~arch
keywording?




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Is X86 uclibc environment supported?

[Ian Stakenvicius]

On 02/05/16 05:27 PM, waltd...@waltdnes.org wrote:
>   Let me know offline if/when you need a beta tester.  I have QEMU and
> an ancient 32-bit-only Atom netbook that could really use a smaller
> libc.
> 

Is musl a good choice perhaps?  iirc it's support right now is better
than uclibc...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re : Cannot see my eclass modifications

[Ian Stakenvicius]

On 04/05/16 02:30 PM, Farid BENAMROUCHE wrote:
> hum... yes I've setup all the relevant settings in my /etc/portage...
> I've also read the man, and still not understanding why.
> 
> But At least you are confirming me that directly modifying the user.eclass in 
> /usr/portage/eclass should work!
> 
> The exact command line I've used was ROOT=/sysroot emerge -av sys-power/nut, 
> where sysroot is a working x86 rootfs (ie, I can chroot in it) with no 
> portage inside...
> 
> PORTAGE_ECLASS_WARNING_ENABLE="1" in the make.conf seems to not work too...


..ok so if you've got a full chroot, you might want to use 'emerge
--config-root=/path/to/chroot [stuff]' and make sure that the
/etc/portage/repos.conf changes you made are in the chroot too.

Barring that, though, the issue may very well be the type of changes
you're trying to make to user.eclass just not working (or being
called) as expected.

A bunch of us hang out on irc.freenode.org in #gentoo-dev-help , and
stuff like this may be easier to help with in a more interactive
environment like that.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Reminder: ALLARCHES

[Ian Stakenvicius]

On 04/05/16 03:43 PM, waltd...@waltdnes.org wrote:
> 
> emerge --keyword-write
> 
> ... similar to "emerge --autounmask-write", but have it write to
> package.accept_keywords, rather than package.unmask?
> 
>   That would achieve the effect that people are looking for, with less
> work.
> 


--autounmask-write modifies package.mask, package.accept_keywords and
package.use already, FYI -- has done so since its inception so far as
I'm aware..







signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Is X86 uclibc environment supported?

[Ian Stakenvicius]

On 29/04/16 09:34 PM, waltd...@waltdnes.org wrote:
> On Fri, Apr 29, 2016 at 08:19:53PM -0400, Anthony G. Basile wrote
> 
>> 1) i support uclibc across many arches. see
>>
>> https://wiki.gentoo.org/wiki/Project:Hardened_uClibc
>>
>>
>> 2) you can file uclibc bugs and i will look at them.  i know about that
>> one and i've got the fix upstream.  its going slowly because the bug was
>> in libcheck which is bundled with gstreamer and so there's layers of
>> backporting.  see
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=577312
> 
>   Thanks.  For the time-being, I'll try building Pale Moon without HTML5
> video support.  It may turn up other problems.
>


If you needed this for Firefox, grab 45.x or 46.0 since you can get
HTML5 support from ffmpeg directly without needing gstreamer.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/7] xorg-2.eclass: drop autotools-utils

[Ian Stakenvicius]

Sent from an iPhone, sorry for the HTML...

> On Apr 17, 2016, at 10:13 AM, Mike Gilbert  wrote:
> 
> @@ -487,10 +497,17 @@ xorg-2_src_configure() {
> xorg-2_src_compile() {
>debug-print-function ${FUNCNAME} "$@"
> 
> +local makeargs=( "$@" )
> +
>if [[ ${XORG_MULTILIB} == yes ]]; then
> -autotools-multilib_src_compile "$@"
> +if ! declare -f multilib_src_compile >/dev/null; then
> +multilib_src_compile() {
> +emake "${makeargs[@]}"
> +}
> +fi
> +multilib-minimal_src_compile
>else
> -autotools-utils_src_compile "$@"
> +emake "${makeargs[@]}"
>fi
> }

Does the src_compile code need to be as complex as this?  Why not just a 'if 
$XORG_MULTILIB ; then multilib-minimal_src_compile "$@"; else emake "$@"; fi '? 
 

...or even 'default' instead of emake...?

Re: [gentoo-dev] [PATCH 1/7] xorg-2.eclass: drop autotools-utils

[Ian Stakenvicius]

> On Apr 17, 2016, at 10:45 AM, Mike Gilbert <flop...@gentoo.org> wrote:
> 
>> On Sun, Apr 17, 2016 at 10:31 AM, Ian Stakenvicius <a...@gentoo.org> wrote:
>> 
>> 
>> Sent from an iPhone, sorry for the HTML...
>> 
>>> On Apr 17, 2016, at 10:13 AM, Mike Gilbert <flop...@gentoo.org> wrote:
>>> 
>>> @@ -487,10 +497,17 @@ xorg-2_src_configure() {
>>> xorg-2_src_compile() {
>>>   debug-print-function ${FUNCNAME} "$@"
>>> 
>>> +local makeargs=( "$@" )
>>> +
>>>   if [[ ${XORG_MULTILIB} == yes ]]; then
>>> -autotools-multilib_src_compile "$@"
>>> +if ! declare -f multilib_src_compile >/dev/null; then
>>> +multilib_src_compile() {
>>> +emake "${makeargs[@]}"
>>> +}
>>> +fi
>>> +multilib-minimal_src_compile
>>>   else
>>> -autotools-utils_src_compile "$@"
>>> +emake "${makeargs[@]}"
>>>   fi
>>> }
>> 
>> Does the src_compile code need to be as complex as this?  Why not just a 'if 
>> $XORG_MULTILIB ; then multilib-minimal_src_compile "$@"; else emake "$@"; fi 
>> '?
>> 
>> ...or even 'default' instead of emake...?
> 
> multilib-mininmal_src_compile and default_src_comple do not provide
> any method to pass arguments to emake. If I recall correctly, there is
> at least one ebuild that needs to do so.
> 

That would do it then...  

mgorny how difficult do you think it would be to pass extra "$@" bits through 
to the default multilib_src_compile?  Or does that just call 'default' too...  
(can't check right now)

Re: [gentoo-dev] [PATCH 0/7] Dropping autotools-utils from xorg-2

[Ian Stakenvicius]

> On Apr 17, 2016, at 10:13 AM, Mike Gilbert  wrote:
> 
> The xorg-2 eclass currently uses the deprecated autotools-utils and
> autotools-multilib eclasses, which are banned in EAPI 6.
> 
> This patchset attempts to remove any trace of autotools-utils from ebuilds
> using xorg-2.
> 
> Note that I am touching stable ebuilds here to avoid forking an "xorg-3"
> eclass. If there is a strong feeling that this is too dangerous, I can alter
> my approach. I have build tested most packages using xorg-2, and only a few
> had issues.
> 

Although I commend you for these efforts, given that this deprecation is also 
linked to EAPI6, why not instead bump to XORG-3 requiring EAPI6, take advantage 
of all the simplifications, and this will allow/enforce migration of all the 
ebuilds as well in turn?

It would be nice for instance to drop the epatch stuffs at the same time, if we 
could...

[gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Ian Stakenvicius]

Hi everyone:

After doing some experimentation with a mingw crossdev, I found that I
needed to do a lot of EXTRA_ECONF settings in combination with
USE="aqua" in order to get packages supporting a win32 API to be
configured appropriately.  In order to support this situation better,
I propose adding a new global flag 'win32', modelled after the 'aqua'
flag, that can be used instead to provide this configuration directly
in ebuilds.

Just like USE="aqua", the flag will be use.mask'ed in base/ so that
users don't erroneously enable it.  I didn't un-use.mask it anywhere
yet since (A) I don't have a prefix/windows environment to test, and
(B) the mingw-based crossdev environments use profiles/embedded by
default, which doesn't inherit from profiles/base and so doesn't have
the use.mask restriction.

The attached patch lists the necessary changes to profile/ as well as
the addition of USE=win32 to *ONE VERSION* of gtk+:2, gtk+:3 and cairo
(the actual commit will include more versions).

Comments?
commit 120335a6721cbcee6f92303c8a6d7cb6cc77b36e
Author: Ian Stakenvicius <a...@gentoo.org>
Date:   Tue Apr 19 15:00:07 2016 -0400

Add USE="win32" to profile, x11-libs/cairo, and x11-libs/gtk+

Similar to USE="aqua", the addition of the win32 use flag allows easier
prefix and crossdev-based building of packages targeting windows (win32)
environments.

This commit adds the flag to profiles/use.desc, and masks it for all
profiles via profiles/base/use.mask.  This leaves the flag available
to be used optionally via the embedded profile, which does not inherit
from base.

Additionally, the commit adds IUSE="win32" support to x11-libs/gtk+ and
its depenency, x11-libs/cairo.  Other packages may follow in future commits.

Package-Manager: portage-2.2.26

diff --git a/profiles/base/use.mask b/profiles/base/use.mask
index 3127dad..f5bd582 100644
--- a/profiles/base/use.mask
+++ b/profiles/base/use.mask
@@ -2,6 +2,10 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Id$
 
+# Ian Stakenvicius <a...@gentoo.org> (19 Apr 2016)
+# USE flag(s) specific to Windows (for mingw, cygwin, etc)
+win32
+
 # Brian Evans <grkni...@gentoo.org> (2 Dec 2015)
 # php 5.4 is end of life, masked for removal
 php_targets_php5-4
diff --git a/profiles/use.desc b/profiles/use.desc
index 6acf19f..49eb30f 100644
--- a/profiles/use.desc
+++ b/profiles/use.desc
@@ -371,6 +371,7 @@ wavpack - Add support for wavpack audio compression tools
 wddx - Add support for Web Distributed Data eXchange
 webkit - Add support for the WebKit HTML rendering/layout engine
 wifi - Enable wireless network functions
+win32 - Include support for the Windows GUI (for mingw or cygwin)
 wmf - Add support for the Windows Metafile vector image format
 wxwidgets - Add support for wxWidgets/wxGTK GUI toolkit
 x264 - Enable h264 encoding using x264
diff --git a/x11-libs/cairo/cairo-1.14.2-r1.ebuild b/x11-libs/cairo/cairo-1.14.2-r1.ebuild
index 12d34b3..3f8aa88 100644
--- a/x11-libs/cairo/cairo-1.14.2-r1.ebuild
+++ b/x11-libs/cairo/cairo-1.14.2-r1.ebuild
@@ -19,7 +19,7 @@ DESCRIPTION="A vector graphics library with cross-device output support"
 HOMEPAGE="http://cairographics.org/;
 LICENSE="|| ( LGPL-2.1 MPL-1.1 )"
 SLOT="0"
-IUSE="X aqua debug directfb gles2 +glib opengl static-libs +svg valgrind xcb xlib-xcb"
+IUSE="X aqua debug directfb gles2 +glib opengl static-libs +svg valgrind win32 xcb xlib-xcb"
 # gtk-doc regeneration doesn't seem to work with out-of-source builds
 #[[ ${PV} == ** ]] && IUSE="${IUSE} doc" # API docs are provided in tarball, no need to regenerate
 
@@ -128,6 +128,7 @@ multilib_src_configure() {
 		$(use_enable static-libs static) \
 		$(use_enable svg) \
 		$(use_enable valgrind) \
+		$(use_enable win32) \
 		$(use_enable xcb) \
 		$(use_enable xcb xcb-shm) \
 		$(use_enable xlib-xcb) \
 		$(use_enable xlib-xcb) \
diff --git a/x11-libs/gtk+/gtk+-2.24.29.ebuild b/x11-libs/gtk+/gtk+-2.24.29.ebuild
index bef80a7..5bfda5c 100644
--- a/x11-libs/gtk+/gtk+-2.24.29.ebuild
+++ b/x11-libs/gtk+/gtk+-2.24.29.ebuild
@@ -13,9 +13,10 @@ HOMEPAGE="http://www.gtk.org/;
 
 LICENSE="LGPL-2+"
 SLOT="2"
-IUSE="aqua cups examples +introspection test vim-syntax xinerama"
+IUSE="aqua cups examples +introspection test vim-syntax win32 xinerama"
 REQUIRED_USE="
-	xinerama? ( !aqua )
+	xinerama? ( !aqua !win32 )
+	aqua? ( !win32 )
 "
 
 KEYWORDS="~alpha amd64 ~arm ~arm64 hppa ~ia64 ~mips ~ppc ppc64 ~s390 ~sh ~sparc x86 ~amd64-fbsd ~x86-fbsd ~x86-freebsd ~x86-interix ~amd64-linux ~arm-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
@@ -25,14 +26,14 @@ COMMON_DEPEND="
 	>=dev-libs/atk-2.10.0[introspection?,${MULTILIB_USEDE

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Ian Stakenvicius]

> On Apr 20, 2016, at 6:51 PM, Andrew Udvare <audv...@gmail.com> wrote:
> 
>> On 20/04/16 12:58, Ian Stakenvicius wrote:
>> On 20/04/16 03:41 PM, Anthony G. Basile wrote:
>>>> According to 'file' the binary format is actually "PE32 executable
>>>> (console) Intel 80386, for MS Windows" for a random *.exe file in my
>>>> /usr/i686-w64-mingw32/usr/bin
> 
> That is because Mingw is for making native executables for Windows, not
> ELF files.

I believe blueness' point here was that with Windows 10's support of ELF, one 
might be able to build a say, winapi toolkit gtk+:3 directly in Linux without 
needing a mingw cross-toolchain.  That is, linking this back to the original 
point, it's best to not mix up the meaning of this use flag with the executable 
file format.

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/04/16 02:17 PM, Mike Frysinger wrote:
> On 20 Apr 2016 21:01, Alon Bar-Lev wrote:
>> On 20 April 2016 at 18:52, Ian Stakenvicius wrote:
>>> After doing some experimentation with a mingw crossdev, I
>>> found that I needed to do a lot of EXTRA_ECONF settings in
>>> combination with USE="aqua" in order to get packages
>>> supporting a win32 API to be configured appropriately.  In
>>> order to support this situation better, I propose adding a
>>> new global flag 'win32', modelled after the 'aqua' flag, that
>>> can be used instead to provide this configuration directly in
>>> ebuilds.
>>> 
>>> Just like USE="aqua", the flag will be use.mask'ed in base/
>>> so that users don't erroneously enable it.  I didn't
>>> un-use.mask it anywhere yet since (A) I don't have a
>>> prefix/windows environment to test, and (B) the mingw-based
>>> crossdev environments use profiles/embedded by default, which
>>> doesn't inherit from profiles/base and so doesn't have the
>>> use.mask restriction.
>>> 
>>> The attached patch lists the necessary changes to profile/ as
>>> well as the addition of USE=win32 to *ONE VERSION* of gtk+:2,
>>> gtk+:3 and cairo (the actual commit will include more
>>> versions).
>>> 
>>> Comments?
>> 
>> You should be able to achieve similar behavior by looking at
>> libc and/or CHOST without introducing new USE flag, just like
>> we do for aix/solaris/freebsd etc...
> 
> agreed ... we have kernel_Winnt & elibc_Winnt already.  i think 
> those represent a mingw environment (vs a cygwin env).
> 
> i don't think a parallel to aqua makes sense.  aqua is a specific
> UI toolkit in OS X.  it's more parallel to something like GTK+ or
> QT.
> 
> further, nesting aqua/win32 doesn't make sense as there is no
> valid profile where both flags would be available.  USE=aqua can
> only be turned on in an OS X profile where your proposed
> USE=win32 would be masked (and vice versa). -mike
> 

Well so far the only needs I have run into for the win32 flag has
been in relation to choosing UI toolkit support for cairo and gtk+
(and possibly others in the future), which is why I saw the parallel.

For my specific needs (mingw cross-compilation), yes leveraging
elibc_mingw would more than suffice, however there may be other
cases where configuring for the 'win32' or 'windows' UI toolkit
makes sense too -- apparently someone's built gtk+ for the win32
toolkit instead of X in cygwin and is distributing binaries (both
KERNEL and ELIBC differ there iirc), and I expect both the
prefix/windows/winnt or prefix/windows/Interix profiles would likely
benefit from this configuration too, but both of those iirc use
different ELIBC values compared to mingw.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcXzJ0ACgkQAJxUfCtlWe0fkQEAugAyzxifYKxh+R8ocgZoL1nB
3SdR9gfDjlOqkBsqBO0A/2ZdubaDowXVg7bVrfkVfZWJF5/c8aZ+5I9wyHkjKHzd
=6/5H
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 20/04/16 02:22 PM, M. J. Everitt wrote:
> On 20/04/16 19:17, Mike Frysinger wrote:
>> agreed ... we have kernel_Winnt & elibc_Winnt already.  i
>> think those represent a mingw environment (vs a cygwin env).
> Surely 'winnt' is a somewhat out-of-date and potentially
> confusing flag? Can't we migrate to a win32 and win64 as
> pertaining to current/recent architectures, and directly relating
> to mingw32 and mingw64 or such-like?!
> 
> Sooner or later win32 is going to be EOL (as the operating
> systems themselves soon will be) ...
> 

kernel_Winnt may seem old but it's accurate in comparison with
kernel_DOS, which would be its predecessor if we had ever attempted
to support it -- the executable is still NTKRNL*.exe or NTOSKRNL.exe
after all, right?

Recall this isn't the ARCH, which can still be either x86 or amd64
(ie x86_64).

The win32 flag I was proposing here was relating to the UI toolkit,
which is likely (i'm guessing) called win32 for legacy reasons
rather than explicitly being 32bit, given I expect the 64bit toolkit
has more or less the same API -- again, not 32bit-windows vs
64-bit-windows related.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iF4EAREIAAYFAlcXzvUACgkQAJxUfCtlWe2ezQEAyWMp3J7msrHqQbqZH/Ww1bXe
pXY0rkEcC0nW7nq6TiUA/Ry56nWOGVobygHia+4bP7b9fomnPha39GdLLZyvafS5
=SEOj
-END PGP 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] 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] 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 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] 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] 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] 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 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 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] 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