Re: [gentoo-dev] [RFC] >=udev-217 or >=eudev-2.1 upgrade news item

[Samuli Suominen]

On 07/11/14 14:21, Alex Xu wrote:
> On 07/11/14 07:13 AM, Samuli Suominen wrote:
>> On 29/10/14 13:42, Alex Xu wrote:
>>> On 29/10/14 07:28 AM, Samuli Suominen wrote:
>>>> request for review before committing, suggestions welcome since it's
>>>> rather short what
>>>> i got to say
>>>>
>>>> thanks,
>>>> Samuli
>>>>
>>> typical news items are in the format " no longer/now do
>>> . [ is >.] if you need , do
>>> . if you do not need , do ."
>>>
>>> [blah blah metadata, I hereby assign all copyright for the following
>>> text to the Gentoo Foundation]
>>>
>>> sys-fs/udev-217 and sys-fs/eudev-2.1 no longer provide a userspace
>>> firmware loader. If you require firmware loading support, you must use
>>> kernel 3.7 or greater with CONFIG_FW_LOADER_USER_HELPER=n. No action is
>>> required if none of your kernel modules need firmware. See [1] for more
>>> information on the upgrade.
>>>
>>> [1]: https://wiki.gentoo.org/wiki/Udev/upgrade#udev_216_to_217
>>>
>> The news item has been committed today. :-)
>>
>> Sorry for the delay. I'm running out of excuses with my health issues. :-(
>>
>> Thanks and sorry,
>> Samuli
>>
> oh, I just figured something. what about systemd? looks like
> IUSE=firmware-loader was removed in 217.
>

Linux 3.7 has been minimum req. for systemd for quite a while now, and I
consider systemd in Gentoo still
to be more of an work-in-progress
And someone agreed with me on #gentoo-systemd, Freenode, that it's not
necessary to include it, so I didn't

However if the maintainers want to add it, that's fine by me, easy to
add one line to the news item... I'll CC them to this
mail just in case

As in, noted

- Samuli

Re: [gentoo-dev] [RFC] >=udev-217 or >=eudev-2.1 upgrade news item

[Samuli Suominen]

On 29/10/14 13:42, Alex Xu wrote:
> On 29/10/14 07:28 AM, Samuli Suominen wrote:
>> request for review before committing, suggestions welcome since it's
>> rather short what
>> i got to say
>>
>> thanks,
>> Samuli
>>
> typical news items are in the format " no longer/now do
> . [ is >.] if you need , do
> . if you do not need , do ."
>
> [blah blah metadata, I hereby assign all copyright for the following
> text to the Gentoo Foundation]
>
> sys-fs/udev-217 and sys-fs/eudev-2.1 no longer provide a userspace
> firmware loader. If you require firmware loading support, you must use
> kernel 3.7 or greater with CONFIG_FW_LOADER_USER_HELPER=n. No action is
> required if none of your kernel modules need firmware. See [1] for more
> information on the upgrade.
>
> [1]: https://wiki.gentoo.org/wiki/Udev/upgrade#udev_216_to_217
>

The news item has been committed today. :-)

Sorry for the delay. I'm running out of excuses with my health issues. :-(

Thanks and sorry,
Samuli

Re: [gentoo-dev] [RFC] >=udev-217 or >=eudev-2.1 upgrade news item

[Samuli Suominen]

On 29/10/14 13:42, Alex Xu wrote:
> On 29/10/14 07:28 AM, Samuli Suominen wrote:
>> request for review before committing, suggestions welcome since it's
>> rather short what
>> i got to say
>>
>> thanks,
>> Samuli
>>
> typical news items are in the format " no longer/now do
> . [ is >.] if you need , do
> . if you do not need , do ."
>
> [blah blah metadata, I hereby assign all copyright for the following
> text to the Gentoo Foundation]
>
> sys-fs/udev-217 and sys-fs/eudev-2.1 no longer provide a userspace
> firmware loader. If you require firmware loading support, you must use
> kernel 3.7 or greater with CONFIG_FW_LOADER_USER_HELPER=n. No action is
> required if none of your kernel modules need firmware. See [1] for more
> information on the upgrade.
>
> [1]: https://wiki.gentoo.org/wiki/Udev/upgrade#udev_216_to_217
>

I'll use your text. So, futher reviews should be aimed at this text.

I've never been a documentation type of guy, my grammar, quite likely,
sucks balls.

- Samuli

[gentoo-dev] [RFC] >=udev-217 or >=eudev-2.1 upgrade news item

[Samuli Suominen]

request for review before committing, suggestions welcome since it's
rather short what
i got to say

thanks,
Samuli
Title: Upgrade to udev >= 217 or eudev >= 2.1
Author: Samuli Suominen 
Content-Type: text/plain
Posted: 2014-10-29
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: = 3.7
kernel with CONFIG_FW_LOADER_USER_HELPER=n config option set, because
>=sys-fs/udev-217 and >=sys-fs/eudev-2.1 no longer has userspace firmware
loader.

[1] https://wiki.gentoo.org/wiki/Udev/upgrade#udev_216_to_217

[gentoo-dev] Request for help with jpeg-9a porting, bug 479818

[Samuli Suominen]

I could use some help with bugs at,

http://bugs.gentoo.org/showdependencytree.cgi?id=479818&hide_resolved=1

Specifically with x11-libs/fox bug
https://bugs.gentoo.org/show_bug.cgi?id=520674 because it's an library,
I'm almost ashamed my patch efforts to it have failed, I keep running
from one error to another

- Samuli

Re: [gentoo-dev] Add bc back to the stage3

[Samuli Suominen]

On 17/09/14 16:29, Alan McKinnon wrote:
> On 17/09/2014 14:49, Aaron W. Swenson wrote:
>> On 2014-09-17 14:20, viv...@gmail.com wrote:
>>> Il 17/09/2014 14:09, Jorge Manuel B. S. Vicetto ha scritto:
 On Wed, 17 Sep 2014, Luca Barbato wrote:

> The bc utility is part of the posix tools and it might be used to build
> linux among the other stuff.
 Luca,

 bc is not in the system set and is a dependency of the kernel or any
 other package that needs it, so why do we need to include a package
 that takes ~20 seconds to build?
>>> Most people don't use the ebuild for the kernel
>> That's a rather outrageous and difficult to substantiate claim. Given
>> what I've seen in the forums and on IRC, it would appear the reverse
>> is true; most people use the ebuild for the kernel.
>>
>> I wouldn't consider people who deviate from the supported methods as
>> our concern. If you're smart enough to do that and want to make your
>> own path, you're smart enough to emerge bc.
>>
>
> Agreed. I've been on -user for 10+ years and only a very few fetch their
> kernels directly from upstream. The vast majority of users who have
> described how they do it simply emerge one of the source packages just
> like the handbook says to do.
>
> There's an even split between genkernel users and those who make
> menuconfig (100% unscientific survey taken from my brain and nowhere else)
>
>
>

I've never used gentoo-sources in my life, and always fetched sources by
hand from kernel.org,
but, at the same time, I find it's 100% my own responsibility to cover
any fallout from that,
including manually emerging required dependencies.

- Samuli

Re: [gentoo-dev] Does the scm ebuild masking policy make sense for git?

[Samuli Suominen]

On 08/09/14 06:47, Rick "Zero_Chaos" Farina wrote:
> On 09/07/2014 09:03 PM, Rich Freeman wrote:
>> Right now the general policy is that we don't allow unmasked (hard or
>> via keywords) ebuilds in the tree if they use an scm to fetch their
>> sources.  There are a bunch of reasons for this, and for the most part
>> they make sense.
> Hard masking is a relic from the days that we didn't just have empty
> keywords, most of the VCS ebuilds in the tree just have empty keywords
> now and are not actually hard masked. I'd say if you set
> ACCEPT_KEYWORDS="**" then you get to keep the pieces.

Hard masking is a relic? That's nonsense

It just always has been a decision left for the developer him or herself
if the masking needs a message or not (package.mask being the way
to mask package with a message, empty KEYWORDS the
way you don't need a message)

Re: [gentoo-dev] udev-9999 (and upcoming 217) no longer has userspace firmware loader (will need Linux 3.7 for firmware's to be loaded)

[Samuli Suominen]

On 01/09/14 03:37, Patrick Lauer wrote:
> On Sunday 31 August 2014 17:13:49 Samuli Suominen wrote:
>> Trying to raise awareness:
>>
>> http://cgit.freedesktop.org/systemd/systemd/commit/?id=be2ea723b1d023b3d385d
>> 3b791ee4607cbfb20ca
>>
> What are the effects for end-users?

Nothing if they follow the CONFIG_CHECK that tells them to set
CONFIG_FW_LOADER_USER_HELPER=n.
And it's it's left to =y or they don't upgrade kernel _at least_ to 3.7,
i.e. not paying attention, then...

>
> Will things just quietly fail hard (e.g. radeon driver -> no firmware -> 
> screen 
> corrupted/black)?

...this.

>
>
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.ebuild
>> ?r1=1.317&r2=1.318
>> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.ebuil
>> d?r1=1.318&r2=1.319
>>
>> I will release a GLEP 42 news item *at the same time* =sys-fs/udev-217
>> is released into ~arch, so nobody
>> will get caught off guard
>>
>> Consider this message a prenotice, now you know it's gone
> ... one more win for eudev. Sigh.
>

They are planning in dropping the userspace loader as well, it's
redudant afterall.

Most firmware are kernel loadable by >= 3.7
Everything is kernel loadable (3.7 and few later versions had some
exceptions for more rare drivers) in latest

[gentoo-dev] udev-9999 (and upcoming 217) no longer has userspace firmware loader (will need Linux 3.7 for firmware's to be loaded)

[Samuli Suominen]

Trying to raise awareness:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=be2ea723b1d023b3d385d3b791ee4607cbfb20ca

http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.ebuild?r1=1.317&r2=1.318
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.ebuild?r1=1.318&r2=1.319

I will release a GLEP 42 news item *at the same time* =sys-fs/udev-217
is released into ~arch, so nobody
will get caught off guard

Consider this message a prenotice, now you know it's gone

- Samuli

Re: [gentoo-dev] The future of dohtml

[Samuli Suominen]

On 28/08/14 18:58, Michał Górny wrote:
> Dnia 2014-08-28, o godz. 00:37:48
> Michał Górny  napisał(a):
>
>> 3. ulm wants to reintroduce dohtml in an eclass for people who want to
>> use it. I'd rather cover it with warnings signs and tell people not to
>> touch it. IMHO a better replacement is the plain 'docinto html; dodoc
>> -r ...', possibly with some extra filtering applied before or after
>> install.
>>
>> What do you think?
> One more thing came up on IRC: einstalldocs (and therefore the default
> install function) installing README* that catches README.html as well.
> I'd rather not add more dohtml-like magic and say it's fine.

I really dislike the whole default list of files defined for DOCS, I keep
constantly adding empty DOCS="" to ebuilds to skip them
I'd rather see whole list pruned empty, and let the maintainer
decide which docs are actually useful

Re: [gentoo-dev] The future of dohtml

[Samuli Suominen]

On 28/08/14 17:11, William Hubbs wrote:
> On Wed, Aug 27, 2014 at 11:43:19PM +0100, Ciaran McCreesh wrote:
>> On Thu, 28 Aug 2014 00:37:48 +0200
>> Michał Górny  wrote:
>>> What do you think?
>> Kill it! With fire! And blood!
> Add me to the list requesting that we kill dohtml as well.
>
> William
>

Me too, I've personally used 'insinto /usr/share/doc/${PF}/html', 'doins
-r ...' for quite a while
when wanting to install docs, since dohtml can't be relied upon, it
skips important files

So +1 for getting rid of it

Re: [gentoo-dev] jpeg-9a in ~arch after half an year in package.mask

[Samuli Suominen]

On 21/08/14 14:31, Samuli Suominen wrote:
> no bugs left open in http://bugs.gentoo.org/show_bug.cgi?id=479818, so
> I've unmasked jpeg-9a
> to ~arch
>
> if you experience problems, take a look at patches applied to
> x11-libs/fltk, net-libs/webkit-gtk, net-misc/nx
> for examples howto solve porting issues
>
> thanks,
> samuli
>

and SLOT="8" as in =media-libs/jpeg-8d-r2:8 will install only 1 file,
libjpeg.so.8,
for compability with binary only programs, as I've found out just from a
user
there are apps like that

- Samuli

[gentoo-dev] jpeg-9a in ~arch after half an year in package.mask

[Samuli Suominen]

no bugs left open in http://bugs.gentoo.org/show_bug.cgi?id=479818, so
I've unmasked jpeg-9a
to ~arch

if you experience problems, take a look at patches applied to
x11-libs/fltk, net-libs/webkit-gtk, net-misc/nx
for examples howto solve porting issues

thanks,
samuli

Re: [gentoo-dev] heads up: glibc-2.20 will require >=linux-2.6.32

[Samuli Suominen]

On 03/08/14 16:16, Mike Frysinger wrote:
> upstream glibc has dropped support for older Linux kernels.  your choices:
>  - upgrade your kernel
>  - switch to a different C library
>  - stick with glibc-2.19 for a while
>
> be warned though there are no plans atm to backport things to glibc-2.19.  
> this includes security fixes, but more importantly as time moves on, making 
> newer gcc versions sanely compile glibc.  we've kept older glibc versions 
> around to be nice, and on a part time basis for cross-compiling, but none of 
> those are given priority.  i.e. fixes come as people feel like doing them.
>
> certainly once glibc-2.20+ goes stable, there is no expectation let alone 
> requirement that packages in the tree be kept working with older glibc 
> versions.  the maintenance cost there is unreasonable.
>
> i guess if you're stuck on old crap, now would be a good time to start 
> preparing to unstick your crap.  glibc-2.20 will most likely be in ~arch in 
> the next 6 months.
> -mike

use of 2.6.32 needs ~sys-fs/udev-208 (kept around for late 2.6.32 patchsets)
use of current udev needs at least 2.6.39 for CONFIG_FHANDLE

so there's more problems with running such a old kernel than just glibc

just saying

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Samuli Suominen]

On 30/07/14 20:29, Michael Haubenwallner wrote:
> Am 2014-07-30 14:33, schrieb Samuli Suominen:
>> There is no need to package.mask if proper if -logic is used, like, for
>> example,
>>
>> if [[ ${PV} == * ]]; then
>> inherit git-r3
>> KEYWORDS=""
>> else
>> KEYWORDS="~amd64 ~arm ~arm64 ~x86"
>> fi
>>
>> Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
>> the KEYWORDS
>> ready, and 1.2.3 and  ebuilds can be identical
> Which instance of the KEYWORDS line is touched by the ekeyword tool these 
> days?
>
> To have ekeyword touch the else-part in the release ebuild, what about this:
>
> if [[ ${PV} == * ]]; then
>   inherit vcs...
>   :; KEYWORDS=""
> else
>   KEYWORDS="..."
> fi
>
> /haubi/
>

You are propably looking for this,
http://bugs.gentoo.org/show_bug.cgi?id=321475

Re: [gentoo-dev] Re: don't rely on dynamic deps

[Samuli Suominen]

On 30/07/14 14:18, Rich Freeman wrote:
> On Wed, Jul 30, 2014 at 3:38 AM, "Paweł Hajdan, Jr."
>  wrote:
>> On 7/30/14, 7:36 AM, Samuli Suominen wrote:
>>> If it's 2-3 packages out of ~300, I'd rather pick them out than
>>> revision bump all ~300 for the 2-3. Or not pick them out at all
>>> and let users do the rebuild (which is the obvious answer
>>> to the output you posted)
>> Peter Stuge pointed it out already, but I also wanted to say rebuilding
>> the affected packages is not obvious to me either.
> Sure, but this seems more like a portage bug (or at least a portage
> output bug) rather than a fundamental issue.
>
> After all, there was no true block - just a need for a rebuild.
>
> I heard prerm as a reason why dynamic deps can break (especially with
> slot operator deps, though obviously it also breaks for
> non-slot-operator deps that should be expressed as such), though as
> has been pointed out those will break unless we unmerge and remerge
> all reverse-deps on every upgrade.  Are there other issues.
>
> To be honest I was expecting a plethora of issues that can go wrong
> with dynamic deps, but so far I'm hearing something like 2-3, and if
> that really is all that there is then this may be a solvable issue.
>
>

That's what I've been trying to point out, people are seriously suggesting
disabling dynamic deps for race conditions
It's like fixing one audio driver in the kernel by deleting whole ALSA block

:-(

- Samuli

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Samuli Suominen]

On 30/07/14 14:48, Luis Ressel wrote:
> On Wed, 30 Jul 2014 09:38:16 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
>
>> In the context of that policy and a content-touchless-bump goal, I 
>> suppose I'd script the bump, pulling keywords from the highest
>> previous version, prepending the ~ as necessary and inserting them in
>> the keywords line after copying the file from the live-ebuild .  That
>> wouldn't be content-touchless, but the touch would be automated so as
>> to avoid mistakes and unnecessary work.
> That proposed script reminds me of http://xkcd.com/1319/. ;)
>
> I think I'd rather go with the original workflow. Okay, perhaps
> package.masking - is a bit uncommon and clutters package.mask, but
> it's not all *that* bad and it eases the workflow.
>
>
> Regards,
> Luis Ressel

There is no need to package.mask if proper if -logic is used, like, for
example,

if [[ ${PV} == * ]]; then
inherit git-r3
KEYWORDS=""
else
KEYWORDS="~amd64 ~arm ~arm64 ~x86"
fi

Then you can just `cp foo-.ebuild foo-1.2.3.ebuild` and it'll have
the KEYWORDS
ready, and 1.2.3 and  ebuilds can be identical

That's what this thread was originally about... That's how x265's ebuild
work, just like eg.
media-libs/xine-lib or sys-fs/udev ebuilds does

(It just seemed this was unclear to some replying in this thread.)

- Samuli

Re: [gentoo-dev] Re: don't rely on dynamic deps

[Samuli Suominen]

On 30/07/14 07:45, Alexander Tsoy wrote:
> В Sun, 27 Jul 2014 14:42:24 +0300
> Samuli Suominen  пишет:
>
>> On 26/07/14 15:49, Ciaran McCreesh wrote:
>>> On Sat, 26 Jul 2014 12:41:16 + (UTC)
>>> Martin Vaeth  wrote:
>>>> hasufell  wrote:
>>>>> Dynamics deps are already broken, not consistently enabled (e.g.
>>>>> when subslots are in use)
>>>> Just to make it clear: No, dynamic deps are not broken.
>>> Yes they are.
>> We just succesfully converted ~300 ebuilds in tree without revision
>> bumps from virtual/udev[gudev,introspection,static-libs]
>> to virtual/libudev and virtual/libgudev
>> Tested it on multiple boxes, went fine. Nobody has filed bugs at
>> http://bugs.gentoo.org/, nobody has filed a single forums post,
>> nobody has said anything at #gentoo, Freenode
>> Only one person said he had to manually build 2 GNOME related
>> packages, simple-scan and something else
> As Michał already noted in this thread, dynamic deps does not play nice
> with slot operators. So I had the same problem with "2 GNOME related
> packages":

I've revision bumped x11-misc/colord and media-gfx/simple-scan
because of this reason, I'll do media-video/cheese as well

If it's 2-3 packages out of ~300, I'd rather pick them out than
revision bump all ~300 for the 2-3. Or not pick them out at all
and let users do the rebuild (which is the obvious answer
to the output you posted)

>
> !!! Multiple package instances within a single package slot have been pulled
> !!! into the dependency graph, resulting in a slot conflict:
>
> virtual/udev:0
>
>   (virtual/udev-208-r2::gentoo, installed) pulled in by
> >=virtual/udev-171:0/0=[gudev] required by 
> (media-video/cheese-3.12.2::gentoo, installed)
> virtual/udev:0/0=[gudev] required by (x11-misc/colord-1.2.1::gentoo, 
> installed)
>
>   (virtual/udev-215::gentoo, ebuild scheduled for merge) pulled in by
> =virtual/udev-215 required by (games-util/xboxdrv-0.8.5-r1::gentoo, 
> installed)
> (and 22 more with the same problem)
>

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Samuli Suominen]

On 29/07/14 03:15, Denis Dupeyron wrote:
> On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen  
> wrote:
>> x265-1.2.ebuild:KEYWORDS="~amd64 ~arm ~x86"
>> x265-1.3.ebuild:KEYWORDS="~amd64 ~x86"
>> x265-.ebuild:KEYWORDS="~amd64 ~x86"
>>
>> As in... You forgot to add ~arm to -.ebuild
> Wait, what? Live ebuilds are keyworded now?
>
> Denis.
>

I should have propably only mailed this to maekke, but CC'd the mailing
list because this
has been a trend lately, people outright ignore * ebuilds and the
preparations
done there for the upcoming releases when they commit non-maintainer
bumps like,
well, I don't want to give examples as that'd be "pointing fingers"
Just that some people think it's better to have poorly done version bump
to get latest,
than live with *correct* older version, and thiskind of thinking really
needs to die...
There is nothing wrong with old, long as it works

- Samuli

Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a

[Samuli Suominen]

On 28/07/14 09:38, Samuli Suominen wrote:
> On 27/07/14 14:33, Pacho Ramos wrote:
>> # Pacho Ramos  (27 Jul 2014)
>> # Not buildable for a long time, bug #414903
>> # Removal in a month.
>> media-plugins/vdr-dxr3
>> media-video/dxr3config
>> media-video/em8300-libraries
> You forgot to mask em8300-modules. That's the package that's actually
> broken.
> Those you masked, actually still build (but are just useless without
> em8300-modules)
>
>

Fixed that for you.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Samuli Suominen]

On 28/07/14 09:41, Samuli Suominen wrote:
> On 27/07/14 22:01, Markus Meier (maekke) wrote:
>> maekke  14/07/27 19:01:15
>>
>>   Modified: x265-1.0.ebuild ChangeLog x265-1.2.ebuild
>> x265-0.8.ebuild
>>   Log:
>>   add ~arm, bug #510340
> Package bumping is done by, eg.:
>
> # cp x265-.ebuild x265-1.3.ebuild
>
> And then,
>
> # grep *.ebuild
>
> x265-1.2.ebuild:KEYWORDS="~amd64 ~arm ~x86"
> x265-1.3.ebuild:KEYWORDS="~amd64 ~x86"
> x265-.ebuild:KEYWORDS="~amd64 ~x86"
>
> As in... You forgot to add ~arm to -.ebuild
>

Fixed that for you.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

[Samuli Suominen]

On 27/07/14 22:01, Markus Meier (maekke) wrote:
> maekke  14/07/27 19:01:15
>
>   Modified: x265-1.0.ebuild ChangeLog x265-1.2.ebuild
> x265-0.8.ebuild
>   Log:
>   add ~arm, bug #510340

Package bumping is done by, eg.:

# cp x265-.ebuild x265-1.3.ebuild

And then,

# grep *.ebuild

x265-1.2.ebuild:KEYWORDS="~amd64 ~arm ~x86"
x265-1.3.ebuild:KEYWORDS="~amd64 ~x86"
x265-.ebuild:KEYWORDS="~amd64 ~x86"

As in... You forgot to add ~arm to -.ebuild

Re: [gentoo-dev] Lastrites: app-crypt/opencdk, net-dialup/gnome-ppp, media-plugins/vdr-dxr3, media-video/dxr3config, media-video/em8300-libraries, net-misc/xsupplicant, sys-cluster/util-vserver, www-a

[Samuli Suominen]

On 27/07/14 14:33, Pacho Ramos wrote:
> # Pacho Ramos  (27 Jul 2014)
> # Not buildable for a long time, bug #414903
> # Removal in a month.
> media-plugins/vdr-dxr3
> media-video/dxr3config
> media-video/em8300-libraries

You forgot to mask em8300-modules. That's the package that's actually
broken.
Those you masked, actually still build (but are just useless without
em8300-modules)

Re: [gentoo-dev] Re: don't rely on dynamic deps

[Samuli Suominen]

On 27/07/14 16:47, Michał Górny wrote:
> Dnia 2014-07-27, o godz. 14:42:24
> Samuli Suominen  napisał(a):
>
>> On 26/07/14 15:49, Ciaran McCreesh wrote:
>>> On Sat, 26 Jul 2014 12:41:16 + (UTC)
>>> Martin Vaeth  wrote:
>>>> hasufell  wrote:
>>>>> Dynamics deps are already broken, not consistently enabled (e.g.
>>>>> when subslots are in use)
>>>> Just to make it clear: No, dynamic deps are not broken.
>>> Yes they are.
>> We just succesfully converted ~300 ebuilds in tree without revision
>> bumps from virtual/udev[gudev,introspection,static-libs]
>> to virtual/libudev and virtual/libgudev
>> Tested it on multiple boxes, went fine.
> How did you exactly test them? 

That you could still emerge packages, even world, without Portage
complaining about unsatisfied
deps

> Did you at least bother checking if
> portage actually uses the deps you added?
>

When you `cd /var/db/pkg` and run `grep virtual/udev.*gudev
*/*/*.ebuild`, you can indeed still see some:

app-cdr/xfburn-0.5.2/xfburn-0.5.2.ebuild:udev? ( virtual/udev[gudev] )"
gnome-base/gvfs-1.20.2/gvfs-1.20.2.ebuild:virtual/udev[gudev] )
media-gfx/gimp-2.8.10-r1/gimp-2.8.10-r1.ebuild:udev? (
virtual/udev[gudev] )"
sys-fs/udisks-1.0.5-r1/udisks-1.0.5-r1.ebuild:>=virtual/udev-208[gudev]
sys-fs/udisks-2.1.3/udisks-2.1.3.ebuild:   
>=virtual/udev-${UDEV_VERSION}[gudev]
virtual/libgudev-208/libgudev-208.ebuild:# $Header:
/var/cvsroot/gentoo-x86/virtual/libgudev/libgudev-208.ebuild,v 1.7
2014/06/18 20:55:21 mgorny Exp $
xfce-extra/thunar-volman-0.8.0/thunar-volman-0.8.0.ebuild:   
virtual/udev[gudev]

But if you try to emerge these packages, like, for example:

$ sudo emerge -pv xfburn thunar-volman

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild   R] xfce-extra/thunar-volman-0.8.0  USE="libnotify -debug" 0 kB
[ebuild   R] app-cdr/xfburn-0.5.2  USE="udev -debug -gstreamer" 0 kB

Portage is using the fresh copies from gentoo-x86

I'm _not_ a Portage, the package manager, developer, so I'd really
appericiate some *examples* where this would become a problem, binary
packages is known one, we have lived with that problem since forever, so
something else, please.
For everything I do with Portage, this is fine with me, and I expect
it's fine for the vast majority of users as well.
And this majority of users won't appericiate the suggested solution of
"lets always revision bump, despite of triggering rebuild for everyone"

To clarify, I know dynamic deps is not perfect, but it's the best
solution we have implemented to avoid the rebuilding problem, and long
as that's true... And seems like you, yourself, have thought about the
same issue:
http://bugs.gentoo.org/show_bug.cgi?id=486778
As in, you can't skip that bug, and go directly to
http://bugs.gentoo.org/show_bug.cgi?id=516612

- Samuli

(Excuse my grammar, woke up five minutes ago, to make some coffee now...)

Re: [gentoo-dev] Re: don't rely on dynamic deps

[Samuli Suominen]

On 27/07/14 14:50, hasufell wrote:
> Samuli Suominen:
>> On 26/07/14 15:49, Ciaran McCreesh wrote:
>>> On Sat, 26 Jul 2014 12:41:16 + (UTC)
>>> Martin Vaeth  wrote:
>>>> hasufell  wrote:
>>>>> Dynamics deps are already broken, not consistently enabled (e.g.
>>>>> when subslots are in use)
>>>> Just to make it clear: No, dynamic deps are not broken.
>>> Yes they are.
>> We just succesfully converted ~300 ebuilds in tree without revision
>> bumps from virtual/udev[gudev,introspection,static-libs]
>> to virtual/libudev and virtual/libgudev
>> Tested it on multiple boxes, went fine. Nobody has filed bugs at
>> http://bugs.gentoo.org/, nobody has filed a single forums post,
>> nobody has said anything at #gentoo, Freenode
>> Only one person said he had to manually build 2 GNOME related packages,
>> simple-scan and something else
>>
>> So, broken? Far from it. More like essential feature.
>>
>> People have just listed some known races dynamic deps have, and I take
>> those races anyday over an regression that causes
>> endless rebuilding...
>>
> I'm not sure if you realize that you just disabled dynamic deps support
> on most of those converted ebuilds.
>

There is a bug in the package manager, you mean.

Re: [gentoo-dev] Re: don't rely on dynamic deps

[Samuli Suominen]

On 26/07/14 15:49, Ciaran McCreesh wrote:
> On Sat, 26 Jul 2014 12:41:16 + (UTC)
> Martin Vaeth  wrote:
>> hasufell  wrote:
>>> Dynamics deps are already broken, not consistently enabled (e.g.
>>> when subslots are in use)
>> Just to make it clear: No, dynamic deps are not broken.
> Yes they are.

We just succesfully converted ~300 ebuilds in tree without revision
bumps from virtual/udev[gudev,introspection,static-libs]
to virtual/libudev and virtual/libgudev
Tested it on multiple boxes, went fine. Nobody has filed bugs at
http://bugs.gentoo.org/, nobody has filed a single forums post,
nobody has said anything at #gentoo, Freenode
Only one person said he had to manually build 2 GNOME related packages,
simple-scan and something else

So, broken? Far from it. More like essential feature.

People have just listed some known races dynamic deps have, and I take
those races anyday over an regression that causes
endless rebuilding...

- Samuli

Re: [gentoo-dev] About current ppc/ppc64 status

[Samuli Suominen]

On 26/07/14 13:22, Anthony G. Basile wrote:
> On 07/26/14 04:44, Pacho Ramos wrote:
>> El sáb, 26-07-2014 a las 10:36 +0200, Pacho Ramos escribió:
>>> El vie, 25-07-2014 a las 15:07 -0500, William Hubbs escribió:
 On Fri, Jul 25, 2014 at 03:57:20PM -0400, Anthony G. Basile wrote:
> On 07/25/14 15:50, Pacho Ramos wrote:
>> El vie, 25-07-2014 a las 15:38 -0400, Anthony G. Basile escribió:
>>> On 07/25/14 15:28, Pacho Ramos wrote:
 That is the reason for me thinking that maybe the way to go
 would be to
 do the opposite -> keep only base-system and a few others
 stable and
 drop stable for most of the rest. This big effort could be
 accomplished
 in a week by other developers willing to help (like me) and
 would solve
 the issue for the long term. I guess that is what HPPA team did
 in the
 past and I think it's working pretty well for them (in summary,
 have a
 stable tree they are able to keep stable). That will also help
 people in
 ppc* teams to know that the remaining stabilization bugs, apart
 of being
 much less, are important enough to deserve rapid attention, as
 opposed
 to current situation that will have some important bugs mixed
 with tons
 of stabilization requests of apps that got ppc stable keywords
 years ago
 and are currently no so important.

>>> Yes, please let's just do base system stable.  I've been
>>> randomly taking
>>> care of ppc but nothing systematic.  Its pretty spotty.  But at
>>> the same
>>> time I don't like the idea of just loosing all the stabilization
>>> effort
>>> on the base system, so that might work best. Something to think
>>> about
>>> for mips too.
>>>
>>>
>> Nice, one think we would need to discuss is what do we consider base
>> system :/
>>
>> I guess packages maintained by base-system, toolchain and...
>> xorg-server
>> and co... what more
>>
>> Not sure if we could have a list of current stable tree for ppc*,
>> once
>> do we have that list, ppc* teams can drop from that list what
>> they want
>> and we get a new list that will be the final result. What do you
>> think
>> about that?
>>
>>
> At the very least, its what's needed to build the stages with
> catalyst.
> I would think we should start with base/packages, but I don't want to
> limit it to just those because I at least need a more for building
> and
> maintaining.  Where should we start to compile such a list?
 If we are going to do this, I think we should drop these arch's
 to exp status in the profiles. That way, it keeps repoman from
 bothering
 the rest of us about stabilizations, and we don't have to worry about
 filing stable requests on them.

 That would let you stabilize things that you need to build the stages.

 William

>>> But, moving ppc* to exp wouldn't lead us to likely break their tree?
>>> (because we wouldn't get any dependency issue even with "base"
>>> packages...)
>>>
>>>
>> I was thinking in this plan:
>> - Get a list with all packages stable on ppc
>> - Drop from that list what ppc teams want
>> - Run on all that packages ekeyword ~ppc*
>> - Run repoman to the full tree to fix the dependencies, use.stable.mask
>> some, tune the list of stable packages...
>>
>>
>>
>
> 1) I don't think we need to drop to exp if we do this right.

+1.   Only reason 'mips' was downgraded to 'exp' because there was
absolutely nobody working on it at the time. I tend
to regret that now. Also, aballier is using amd64-fbsd with 'stable' and
'dev', exactly to avoid breakage, since nobody
really checks for 'exp'

>
> 2) I like this plan.  Its not that we'll drop the whole arch to ~ at
> once but trim at our discretion.  Less chance of breaking everything.
>

+1

Re: [gentoo-dev] USE="gudev introspection" removal from virtual/udev tomorrow'ish

[Samuli Suominen]

On 25/07/14 11:07, Daniel Campbell wrote:
> On 07/24/2014 02:22 PM, Samuli Suominen wrote:
>> gentoo-x86 has been converted to use virtual/libgudev.   big thanks to
>> _AxS_ who helped me to
>> get it finally done.
>>
>> that means we will be removing compability USE flags "gudev
>> introspection" from virtual/udev
>> tomorrow'ish (only waiting for gnome-overlay folks)
>>
>> run this in your overlay:
>>
>> $ grep virtual.*udev.*gudev */*/*.ebuild
>>
>> and convert them to EAPI=5 syntax virtual/libgudev:= but don't do it
>> without making sure you don't
>> need virtual/libudev:= or virtual/udev (like for udevd, udev.pc for
>> udevdir value) as well
>>
>> the Tracker is:
>> http://bugs.gentoo.org/showdependencytree.cgi?id=506034&hide_resolved=1
>>
> What does this mean for users of, say, eudev that needed those flags for
> certain things (but don't have GNOME installed)? Will it just be a
> removed entry from package.use and a rebuild? I'm on stable so it'll
> take a little bit to reach me, but I figured I'd ask on behalf of any
> other concerned users.
>

Short answer:

No impact.

In case of problems:

If some package (installed from Portage) is complaining about missing
USE flags "gudev"
or "introspection" for virtual/udev, it means you need to recompile the
package complaining,
so the Portage's VDB will get the updated ebuild with the new
virtual/libgudev dependency
from actual Portage tree

OR

If some package (installed from overlay) is complaining about missing
USE flags "gudev"
or "introspection", you should propably try updating the overlay, if
that doesn't help,
contact the overlay maintainer, possible uninstall the overlay or fix it
yourself

I hope that answered your question

- Samuli

[gentoo-dev] USE="gudev introspection" removal from virtual/udev tomorrow'ish

[Samuli Suominen]

gentoo-x86 has been converted to use virtual/libgudev.   big thanks to
_AxS_ who helped me to
get it finally done.

that means we will be removing compability USE flags "gudev
introspection" from virtual/udev
tomorrow'ish (only waiting for gnome-overlay folks)

run this in your overlay:

$ grep virtual.*udev.*gudev */*/*.ebuild

and convert them to EAPI=5 syntax virtual/libgudev:= but don't do it
without making sure you don't
need virtual/libudev:= or virtual/udev (like for udevd, udev.pc for
udevdir value) as well

the Tracker is:
http://bugs.gentoo.org/showdependencytree.cgi?id=506034&hide_resolved=1

Re: [gentoo-dev] don't rely on dynamic deps

[Samuli Suominen]

On 22/07/14 10:25, "Paweł Hajdan, Jr." wrote:
> On 7/21/14, 11:52 PM, Alexander Berntsen wrote:
>> 2. Remove dynamic-deps. This is what I think currently makes sense.
> +1 I also think it's the best option.
>
>

Not before someone has implemented an alternative way to avoid useless
rebuilding.
The quality of the distribution doesn't improve by killing one of the
most important
features the package manager has.
The quality of the distribution improves by providing an alternative
with less problems.

Sounds like to me, that the people who want to remove the feature so
badly, are the
ones volunteering for the job as well.

- Samuli

Re: [gentoo-dev] Re: don't rely on dynamic deps

[Samuli Suominen]

On 22/07/14 20:11, Ciaran McCreesh wrote:
> On Tue, 22 Jul 2014 19:03:16 +0200
> Sven Vermeulen  wrote:
>> As someone who regularly adds in dependencies without bumping (adding
>> USE=selinux dependencies to the proper SELinux policy) because that
>> would trigger lots of totally unnecessary rebuilds: 
> Er... You do realise that doing that with dynamic dependencies leads to
> packages depending upon selinux that don't actually use selinux, right?
> Thus triggering lots of totally unnecessary rebuilds on an ABI change.
>

Err, I believe he meant adding RDEPEND -only USE="selinux" to pull in
eg. sec-policy/selinux-dante
from net-proxy/dante
So, how does that exactly make "packages depending upon selinux that
don't actually use selinux"
Doesn't make any sense

- Samuli

Re: [gentoo-dev] Re: don't rely on dynamic deps

[Samuli Suominen]

On 22/07/14 11:21, Michael Palimaka wrote:
> On 07/22/2014 07:52 AM, Alexander Berntsen wrote:
>> To sum up: My vote is disable dynamic-deps. And I would be happy to
>> apply a patch that does this with the information I have today.
> What a great way to kill the distro.
>
> I can already heat my house with the number of unnecessary rebuilds - I
> can't imagine how many people will be left once we have to needlessly
> rebuild libreoffice and half the tree every time someone makes some
> minor change. If developers can't revbump correctly to address the
> shortcomings of dynamic deps, why do we expect they will be able to do
> so for static deps?
>
> When can we expect this issue to be brought before the Council? I look
> forward to seeing the specific examples of unavoidable breakage that
> would be required to make such a decision.
>
>

+1

Re: [gentoo-dev] don't rely on dynamic deps

[Samuli Suominen]

On 22/07/14 04:05, Rick "Zero_Chaos" Farina wrote:
>
> And just for fun, since no one has mentioned it yet, dynamic deps don't
> work at all on binpkgs since the Packages file contains the deps (like
> vardb) and it doesn't get updated (just like vardb).

Known long standing pitfall. It's managable.

>
> Revbump or make dynamic deps actually work (ha).
>

If they are really as broken people claim, why is the feature enabled by
default in the
official package manager?
As in, why I'm not seeing a bug with title "sys-apps/portage: disable
dynamic deps by default"
with a Comment #0 listing all the culprits why it should be disabled by
default?
Or do people think it works well enough, so that it's pros overweight
the cons? I do,
and many others seem to think so as well.

Re: [gentoo-dev] don't rely on dynamic deps

[Samuli Suominen]

On 21/07/14 23:56, Michał Górny wrote:
> Now... whether dynamic deps are technically the right thing to do is another 
> question. It merits discussion, but we need to be really sure about the 
> consequences of any change.
> Yes, it does. I'm not sure if it leads anywhere, though. Dynamic deps
> are a pipe dream. You can't implement them properly, so we're using
> half-working implementation as an excuse to be lazy.

What's lazy is maintainer doing revision bump without thinking
if it's really required, spreading his laziness upon every users
machine (by triggering revision bump driven rebuild)

Re: [gentoo-dev] don't rely on dynamic deps

[Samuli Suominen]

On 21/07/14 23:13, Ian Stakenvicius wrote:
> On 21/07/14 04:06 PM, Samuli Suominen wrote:
>
> > On 21/07/14 22:50, Ciaran McCreesh wrote:
> >> On Mon, 21 Jul 2014 22:42:23 +0300 Samuli Suominen
> >>  wrote:
> >>> people are revbumping packages for the simplest things like
> >>> EAPI4->5
> >> EAPI changing to 5 should always get a revbump, since it causes
> >> confusion if anyone has a USE dependency upon your package.
> >>
>
> > What kind of confusion?   In my experience, Portage handles it
> > well
>
>
> Says the guy that's emerging things with --nodeps most of the time... :D
>
>
>

Portage's dependency calculation takes long time, but if you add useless
rebuilds of packages on top of that, that makes things even worse

(Yeah, I saw the ":D")

Re: [gentoo-dev] don't rely on dynamic deps

[Samuli Suominen]

On 21/07/14 22:50, Ciaran McCreesh wrote:
> On Mon, 21 Jul 2014 22:42:23 +0300
> Samuli Suominen  wrote:
>> people are revbumping packages for the simplest things like EAPI4->5
> EAPI changing to 5 should always get a revbump, since it causes
> confusion if anyone has a USE dependency upon your package.
>

What kind of confusion?   In my experience, Portage handles it well

Re: [gentoo-dev] don't rely on dynamic deps

[Samuli Suominen]

On 21/07/14 22:37, hasufell wrote:
> afaiu dynamic deps are broken and not defined in PMS
>
> still... people seem to fix deps without revbumping, causing users who
> either don't use dynamic deps (it's optional for portage through
> --dynamic-deps=y, although it's on by default) or who use a different PM
> to not get the fix, at worst resulting in broken dependency calculation
>
> suggestion:
> * stop fixing dependencies without revbumping
> * add an appropriate question to the dev quiz
> * remove dynamic deps from portage (afair that is already considered by
> the portage team)
>

Revision bumping for dependency change that doesn't cause the package's
file content
to change doesn't make sense; triggers useless rebuilds for users.

Portage is the official package manager, and has dynamic deps enabled by
default.

And it's already in ebuild-quiz.txt to ensure knowing when to, or not to,
revbump:

*** Ebuild technical/policy questions

1.  You change a package's ebuild to install an init script. Previously,
the package had no init script at all.
Is a revision bump necessary? Why? What about when adding a patch?


So, -1, useless rebuilds is one of the biggest problems lately, it's an
relatively new problem,
people are revbumping packages for the simplest things like EAPI4->5

- Samuli

Re: [gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.

[Samuli Suominen]

Besides, people should migrate to something with active upstream, like
plymouth

Re: [gentoo-dev] Enable format-security in the dev profiles

[Samuli Suominen]

On 21/07/14 18:11, Ian Stakenvicius wrote:
> On 21/07/14 11:07 AM, Agostino Sarubbo wrote:
> > On Monday 21 July 2014 10:08:44 Diego Elio Pettenò wrote:
>
> >> Any -Werror=* flag will make random autoconf checks fail for no
> >> good
>
> >> reason, don't use them on profiles, it's silly.
>
> >>
>
> >> Diego Elio Pettenò — Flameeyes
>
> >> flamee...@flameeyes.eu — http://blog.flameeyes.eu/
>
>
>
> > I don't see where I asked about -Werror instead of only -Wformat.
>
>
> You didn't, explicitly; jer mentioned -Werror because -Wformat has
> been enabled for years already (his words), so the assumption was that
> you meant -Werror and Diego is responding to that.
>
> (Diego's post was against the OP, so out-of-order, is all)
>
>
>

But only -Wformat=2 has -Wformat-security. Do we enable -Wformat with 1
or 2?
I'm asking, I really don't know (and can't check immediately)

- Samuli

[gentoo-dev] We should lastrite splashutils in it's current form and not allow it in tree before it's fixed.

[Samuli Suominen]

media-gfx/splashutils fails to build, and it fails everytime one of it's
reverse dependency changes dependencies because it fails to use
pkg-config to query "Libs: "

it's supposed to have proxy-maint, but nobody is pushing fixes for the
supposed proxy-maint

it's in no shape to be in tree as-is, and since spock@g.o has retired
and was also the upstream of it, well, there is no upstream for it

no upstream, no downstream, fails to build, bugs with patches but nobody
to push them -> lastriting the package in 2 weeks, this
is the first heads up mail

17 bugs found:

326759 Gentoo S Vulnerab secur...@gentoo.org IN_P   
 --- =media-libs/freetype-2.5 18:51:59
398077 Gentoo L Applicat asaf.g...@gmail.com CONF   
 --- media-gfx/splashutils: /sbin/fbtruetype links to libraries in
/usr 2013-06-16
417375 Gentoo L New Ebui asaf.g...@gmail.com CONF   
 --- media-gfx/splashutils: initramfs corruption when compression is
not gzip (new genkernel feature) 2013-12-07
398075 Gentoo L Applicat asaf.g...@gmail.com CONF   
 --- media-gfx/splashutils: please make the static linkage optional
2013-06-16
417439 Gentoo L Core sys asaf.g...@gmail.com UNCO   
 --- media-gfx/splashutils should move cachedir /lib/splash/cache to
/run

Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC

[Samuli Suominen]

On 21/07/14 12:30, Tom Wijsman wrote:
> On Mon, 21 Jul 2014 02:35:45 -0500
> Dale  wrote:
>
>> Diamond wrote:
>>> On Mon, 21 Jul 2014 00:25:02 +
>>> "Robin H. Johnson"  wrote:
>>>
>>>
 Removals:
 net-misc/curl  2014-07-15 09:29:56
 blueness
>>> Is this a joke? Isn't curl as basic package as wget?
>> Look under additions.  It's there. 
> It is probable that the wrong package was auto-completed by accident.
>
> Removals:
> net-misc/curl 2014-07-15 09:29:56 blueness
> net-libs/cyassl   2014-07-15 10:09:41 blueness
>
> Additions:
> net-misc/curl 2014-07-15 09:40:13 blueness
>

Plus, blueness verified with infra@g.o that mirrors didn't sync
in-between, so this was never
visible to any users. :-)

- Samuli

Re: [gentoo-dev] Enable format-security in the dev profiles

[Samuli Suominen]

On 20/07/14 22:28, Agostino Sarubbo wrote:
>
> Hello,
>
>  
>
> I'd like to enable by default format-security at least in the dev
> profiles.
>
>  
>
> Thought?
>
>  
>
> References:
>
> https://bugs.gentoo.org/show_bug.cgi?id=259417
>
> https://fedoraproject.org/wiki/Format-Security-FAQ
>
>  
>
> -- 
>
> Agostino Sarubbo
>
> Gentoo Linux Developer
>

Why not generate a Portage QA warning out from the warning
-Wformat-security produces instead?
That way compile wouldn't abort needlessly.

Re: [gentoo-dev] New global USE flags "upower and "udisks" (split from "udev" in some cases)

[Samuli Suominen]

On 18/07/14 23:58, Georg Rudoy wrote:
> 2014-07-19 0:19 GMT+04:00 Samuli Suominen :
>> So, I propose:
>>
>> upower with short generic description of "Support for power management"
>> udisks with short generic description of "Support for storage management"
> Being a proxy maint of lc-vrooby, I support this proposal.
>
> Also, have you considered udisks2? For example, lc-vrooby can use any
> of udisks:0 and udisks:2, but the rdeps that get pulled and the
> backends that get compiled are controlled by the flags.
>

There should be no separate USE flags for udisks:0 and udisks:2. They can
be installed *and* ran at the same time.
If both are supported, and it's a compile time option, :2 should be forced
If both are supported, and they can be automatically detected at
runtime, || ( sys-fs/udisks:2 sys-fs/udisks:0 ) syntax
should be used
We have a Tracker open for migrating to udisks:2 and adding udisks:0
support is a bug (regression)

[gentoo-dev] New global USE flags "upower and "udisks" (split from "udev" in some cases)

[Samuli Suominen]

Some history first:

When sys-fs/udisks and sys-power/upower was introduced to Portage, they
only had handful of consumers,
and there was no sys-apps/systemd in Portage
They were non problematic packages and could be considered as wrappers
that linked desktops to udev -related
functionality
But, now, upower upstream writes code only with systemd in mind, dropped
hibernate/suspend without any
consideration to non-systemd users
And, Portage doesn't understand || ( ) dependencies anymore wrt
http://bugs.gentoo.org/show_bug.cgi?id=515230
And, people started using local USE flags "udisks" and "upower" despite
being advised against it
And, more people are requesting sys-fs/udisks and sys-power/upower to be
moved away from USE="udev" to
these 2 separate flags, like http://bugs.gentoo.org/show_bug.cgi?id=516380
These 2 flags are already enabled by default in the desktop profile
target, just like USE="udev" is

So, I propose:

upower with short generic description of "Support for power management"
udisks with short generic description of "Support for storage management"

These packages use them already, but a lot more will follow:

[+  D   ] upower
kde-base/kdelibs: Use upower for power management
[+ B] (4/4.12) 4.12.5 [gentoo]
[+ B] (4/4.13) 4.13.0 [gentoo]

[+  D   ] upower
kde-misc/synaptiks: Handle mouse devices correctly across suspend and
resume with upower
[+ B] (4) 0.8.1-r2 [gentoo]
[+ B] (4) 0.8.1-r4 [gentoo]

[+  D   ] upower
lxde-base/lxsession: Pull in sys-power/upower for hibernate/suspend
support
[+  ] 0.4.6.1 [gentoo]
[+  ] 0.4.9.2 [gentoo]
[+  ] 0.4.9.2-r1 [gentoo]
[+  ] 0.4.9.2-r2 [gentoo]
[+  ] 0.4.9.2-r3 [gentoo]

[+  D   ] upower
net-im/telepathy-mission-control: Use sys-power/upower to detect
suspend and resume
[+ B] 5.14.0-r1 [gentoo]
[+ B] 5.14.1 [gentoo]
  5.16.1 [gentoo]

[+  D   ] udisks
app-emulation/wine: Support dynamic storage devices using
sys-fs/udisks
  1.2.3 [gentoo]
  1.3.28 [gentoo]
[+  ] 1.4 [gentoo]
[+  ] 1.4.1 [gentoo]
[+  ] 1.5.0 [gentoo]
[+  ] 1.5.1 [gentoo]
[+  ] 1.5.2 [gentoo]
[+  ] 1.5.3 [gentoo]
[+  ] 1.5.4 [gentoo]
[+  ] 1.5.5 [gentoo]
[+  ] 1.5.6 [gentoo]
[+  ] 1.5.7 [gentoo]
[+  ] 1.5.8 [gentoo]
[+  ] 1.5.9 [gentoo]
[+  ] 1.5.10-r1 [gentoo]
[+  ] 1.5.11-r1 [gentoo]
[+  ] 1.5.12-r1 [gentoo]
[+  ] 1.5.13-r1 [gentoo]
[+  ] 1.5.14-r1 [gentoo]
[+  ] 1.5.15-r2 [gentoo]
[+  ] 1.5.16-r1 [gentoo]
[+  ] 1.5.17 [gentoo]
[+  ] 1.5.18 [gentoo]
[+  ] 1.5.19 [gentoo]
[+  ] 1.5.20 [gentoo]
[+  ] 1.5.21 [gentoo]
[+  ] 1.5.22 [gentoo]
[+  ] 1.5.23-r1 [gentoo]
[+  ] 1.5.24 [gentoo]
[+  ] 1.5.25 [gentoo]
[+  ] 1.5.26 [gentoo]
[+  ] 1.5.27 [gentoo]
[+  ] 1.5.28 [gentoo]
[+  ] 1.5.29 [gentoo]
[+  ] 1.5.30 [gentoo]
[+  ] 1.5.31 [gentoo]
[+ B] 1.6 [gentoo]
[+ B] 1.6.1 [gentoo]
[+ B] 1.6.2 [gentoo]
[+ B] 1.7.0 [gentoo]
[+ B] 1.7.3 [gentoo]
[+ B] 1.7.4 [gentoo]
[+ B] 1.7.8 [gentoo]
[+ B] 1.7.9 [gentoo]
[+ B] 1.7.10 [gentoo]
[+ B] 1.7.11 [gentoo]
[+ B] 1.7.12 [gentoo]
[+ B] 1.7.13 [gentoo]
[+ B] 1.7.14 [gentoo]
[+ B] 1.7.15 [gentoo]
[+ B] 1.7.16 [gentoo]
[+ B] 1.7.17 [gentoo]
[+ B] 1.7.18 [gentoo]
[+ B]  [gentoo]

[+  D   ] udisks
app-leechcraft/lc-vrooby: Use sys-fs/udisks:0 for block device access
(e.g., automounting)
[+  ] 0.6.60 [gentoo]
[+  ] 0.6.65 [gentoo]
[+  ]  [gentoo]

[+  D   ] udisks
app-text/calibre: Add run-time dependency on sys-fs/udisks in order
to mount and unmount reading devices.
[+ B] 1.2 [gentoo]
[+ B] 1.20 [gentoo]
[+ B] 1.25 [gentoo]
[+ B] 1.29 [gentoo]
[+ B] 1.35 [gentoo]

[+  D   ] udisks
gnome-base/gvfs: Enable volume monitoring using sys-fs/udisks
[+  ] 1.18.3 [gentoo]
[+  ] 1.18.3-r1 [gentoo]
[+  ] 1.20.1 [gentoo]

[+  D   ] udisks
kde-base/kdelibs: Use udisks for block device access (e.g.,
automounting)
[+ B] (4/4.12) 4.12.5 [gentoo]
[+ B] (4/4.13) 4.13.0 [gentoo]

[+  D   ] udisks
x11-libs/libfm: Use libfm's udisks-based volume monitor
implementation instead of using the one from gvfs
  0.1.17-r1 [gentoo]
[+  ] (0/4.7.1) 1.1.4 [gentoo]
[+  ] (0/4.0.0) 1.2.0 [gentoo]
[+  ] (0/4.0.0)  [gentoo]

[+  D   ] udisks
xfce-extra/xfce4-power-manager: Pull in sys-fs/udisks for spindown
support
[+ B] 1.2.0-r2 [gentoo]
[+ B] 1.2.0_p20140511 [gentoo]

Re: [gentoo-dev] Prevent to need to change all keywords at the same time

[Samuli Suominen]

On 17/07/14 21:56, Ian Stakenvicius wrote:
>
> I guess we'll have to wait until vapier's back to get it done, tho..
>
>

imlib2 is basically normal autotools based package, there is no need to
tie it to this specific
eclass

it should be extremely trivial to revision bump it to use normal eutils,
autotools, econf, emake
and so forth

the only reason it's tied to this specific eclass is historical reasons

i really can't see anyone objecting the conversion at this time

- samuli

Re: [gentoo-dev] The request to abolish games team policy

[Samuli Suominen]

> 's/disband the games team/move mr_bones_ to the lead of the current
> team, as what's what he has been for couple of years de facto/'
>

*that's what

(stupid typing error)

Re: [gentoo-dev] The request to abolish games team policy

[Samuli Suominen]

On 15/07/14 14:18, Sergey Popov wrote:
> 14.07.2014 22:11, hasufell пишет:
>> I will continue to work with Mr_Bones_, but if any1 says there is no
>> problem with the games project, then he either doesn't know anything
>> about the situation or he doesn't want to know.
>>
>> Again, you seem to be the only council member who cares to mediate here.
>> That is pretty frustrating.
>>
> Just disband the games team and make the new one with you and Mr_Bones
> as a members.
>
> There is no point in having games team that actually does nothing.
> Sometimes you just need to takeover the power and do things on your own,
> like we do with arm team.
>
> vapier was not angry when we took leadership from him(leaving him as
> ordinary team member), so i think you could do this for games team as well.

's/disband the games team/move mr_bones_ to the lead of the current
team, as what's what he has been for couple of years de facto/'

Re: [gentoo-dev] find ${D} -delete in src_install() ?

[Samuli Suominen]

On 15/07/14 13:00, Peter Stuge wrote:
> I came across this in sys-power/pm-utils-1.4.1-r2.ebuild src_install():
>
> # NetworkManager 0.8.2 is handling suspend/resume on it's own with UPower
> find "${D}" -type f -name 55NetworkManager -exec rm -f '{}' +
>
> This seems baroquely reckless, but it has been like that since 2010
> with one revbump and a bunch of stabilizations, so maybe it's fine?

I don't see anything reckless about it.

> Is it really acceptable for an ebuild to delete all files in $D
> which have a particular name?
>
>
> //Peter
>

Of course, why wouldn't it be? $D is the image directory of the package
before it's merged to
actual filesystem, and even if it weren't, it specifies -name as well,
so it's double-safe

Re: [gentoo-dev] Re: The request to abolish games team policy

[Samuli Suominen]

On 09/07/14 18:35, Vadim A. Misbakh-Soloviov wrote:
> В письме от Вт, 8 июля 2014 18:22:50 пользователь Samuli Suominen написал:
>> It seems to me like people aren't making the effort of joining to the
>> team and meeting the high quality
>> ebuild syntax they've kept up...
> Samuli! With all my respect to you personally, please, don't tell anything 
> about "high quality" of ebuilds syntax by the games team. Please.
>

There are open bugs (non-ebuild bugs), sure
There are sometimes wrong dependencies in old binary-only games which
require special CD-ROM or other distfile, because that's
when we rely upon users to report the dependencies

But, the ebuild syntax is good as it's in eg. base-system, toolchain
And games ebuilds are nice examples for people learning to write ebuilds

So, don't know what you are referring to...

- Samuli

Re: [gentoo-dev] Re: The request to abolish games team policy

[Samuli Suominen]

On 09/07/14 07:24, Tom Wijsman wrote:
>> [...] confusions with newer people...
> Ironically; my first Portage tree action "add a directory" got a "don't
> throw [expletive] into [games category]" reply, before adding the ebuild.
>
> One really can't expect new people to start to address a team like
> that prior to addition; I've assumed for some time that contacting the
> teams is a necessity before addition of an ebuild, but that quickly
> turned out to be false for most if not all other teams.
>

Well, I consider gnome-base/ to be gnome@g.o's "territory" in sense that
I'd contact the team prior to adding a ebuild there
Likewise I consider both, xfce-base/ and xfce-extra/ as well as anything
with xfce@g.o in metadata.xml to be xfce@g.o's "territory" in sense that
I'd be slightly annoyed if someone adds/modifies/... an Xfce ebuild without
consulting me (or angelos). But, if it's done properly, like hasufell added
properly added xfce4-whiskermenu-plugin to xfce-extra/, I'll stay quiet,
because it wouldn't achieve anything to complain about something you
would have added _exactly_ the same way line-by-line
Likewise I consider kde-base/ to be kde@g.o's "territory"

And I'm sure the tree has more of these...

Re: [gentoo-dev] Re: The request to abolish games team policy

[Samuli Suominen]

On 08/07/14 19:17, Michael Palimaka wrote:
> On 07/09/2014 01:22 AM, Samuli Suominen wrote:
>> And some personal thoughts about the initial proposal...
>> I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
>> and 2. should definately
>> stay as is.
> What authority does the game team have over anything? Did it get special
> blessing from the Council? Isn't it just another regular project as per
> GLEP 39?
>
>
>

Not everything we have had since-always-standing is documented,
unfortunately -- games has always been special from others
Still, even if it's undocumented, it doesn't mean it doesn't exist

It's like the amd64/x86 stabilization exception that everyone
who can test them can mark them, "everyone" knew it existed
but it wasn't documented properly

Sure, we should drive to getting everything documented, to avoid
thesekind of confusions with newer people...

- Samuli

Re: [gentoo-dev] Re: The request to abolish games team policy

[Samuli Suominen]

On 08/07/14 17:18, Maxim Koltsov wrote:
>
>
>
> 2014-07-08 16:10 GMT+04:00 Rich Freeman  >:
>
> On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny  > wrote:
> >
> > The games team believes that they're binding. In fact, I recall
> one of
> > the team members remarking explicitly that they're going to alter
> > ebuilds that were committed without their approval.
> >
> > In fact, they did remove ebuilds from the tree in the past for this
> > reason [1].
> >
> >
> 
> [1]:http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/games-strategy/openxcom/?hideattic=0
>
> This was 3 weeks ago, so certainly relevant.  Was this removal by
> mutual agreement (ie the games team and maksbotan ?
>
> Rich
>
>
> No, I was not notified beforehand (or failed to recieve such
> notification, it does not matter now). This was a proxied commit, I
> did a usual check of the ebuild and found no problems. I admit that
> the ebuild was not-so-compliant to games herd rules, though. Still,
> immediate removal without notification and/or discussion did annoy me.
> BTW, I fail to see the reason of move to games-engines, but that's
> another issue.
>
> -- 
> Regards, Maxim.

Did you get the ebuild reviewed and accepted for committing at
#gentoo-games as per existing guidelines[1]?
If you didn't, then you propably managed to annoy them first, and the
outcome was expected (as in, the missing work
was done for you, with best intentions)
I've never had any issues with getting games ebuilds reviewed at
#gentoo-games and I've committed dozen(s) of
games to tree.
I've been on the channel, almost always I'm online, I haven't seen
people getting ignored there who have proper
initial work done first (if the ebuild is in a shape you'd have to
rewrite every second line, you might get ignored,
and I find that to be reasonable, since we are all volunteers, afterall)

[1] http://dev.gentoo.org/~vapier/i-wanna-be-in-the-games-herd.html

And some personal thoughts about the initial proposal...
I don't care about the suggestion 3. in mgorny's proposal at all, but 1.
and 2. should definately
stay as is. Since games ebuilds are low maintenance, there is no intrest
in getting dozens of 'eclass porting
bugs', which is why inheriting games last prevents future breakage as
well as ensure the eclasses
exported phases are respected.
It seems to me like people aren't making the effort of joining to the
team and meeting the high quality
ebuild syntax they've kept up...

- Samuli

Re: [gentoo-dev] Is || ( Atom... ) broken?

[Samuli Suominen]

On 07/07/14 13:14, Greg Turner wrote:
> WTF is up with it?  Why does it love the first Atom so much more than
> the others?
>
> It could be such a useful feature, but, in practice, it just never
> seems to do what I want it to.  Is it a bug?
>
> -gmt

short answer, yes, specially in latest ~arch sys-apps/portage, see:

http://bugs.gentoo.org/515230

Re: [gentoo-dev] last rites: =dev-lang/perl-5.12* and family

[Samuli Suominen]

On 30/06/14 18:16, Ian Stakenvicius wrote:
> On 30/06/14 04:46 AM, Andreas K. Huettel wrote:
>
> > [snip!] * As Fabian pointed out, perl-core/Switch-2.160.0 should
> > still go stable. Fine with me (but I can't read your minds about
> > future stabilizations, and the virtual only had ~arch reverse
> > deps).
>
>
> There shouldn't be any need to read minds, here -- if the previous
> stable perl had this capability, then the new stable perl should too

that's nonsense, if upstreams remove features, even working ones, it
might not make everyone happy, but they are well within their
rights to do that (like, upower dropping hibernate/suspend support)

and if someone isn't happy about it, they can always fork

- Samuli

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/wmfishtime/files: wmfishtime-1.24-gtk.patch

[Samuli Suominen]

On 23/06/14 05:01, Jeroen Roovers wrote:
> On Sun, 22 Jun 2014 20:08:41 +0300
> Samuli Suominen  wrote:
>
>> LIBS = `$(PKG_CONFIG) gtk+-2.0 --libs` -lm -X11
> No, it should be
>
> LIBS = $(shell $(PKG_CONFIG) ...)
>
> or PKG_CONFIG will be called every time LIBS is evaluated.
>
> And while you're at it, why not call PKG_CONFIG on x11, too?
>
> LIBS = $(shell $(PKG_CONFIG) --libs gtk+-2.0 x11) -lm
>
>
>  jer
>

Oops. You are right. Thanks.

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-plugins/wmfishtime/files: wmfishtime-1.24-gtk.patch

[Samuli Suominen]

On 22/06/14 19:25, Bernard Cafarelli (voyageur) wrote:
> voyageur14/06/22 16:25:10
>
>   Modified: wmfishtime-1.24-gtk.patch
>   Log:
>   Link with libm, spotted by patrick in bug #513908
>   
>   (Portage version: 2.2.10/cvs/Linux x86_64, signed Manifest commit with key 
> C74525F2)
>
> Revision  ChangesPath
> 1.3  x11-plugins/wmfishtime/files/wmfishtime-1.24-gtk.patch
>
> file : 
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmfishtime/files/wmfishtime-1.24-gtk.patch?rev=1.3&view=markup
> plain: 
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmfishtime/files/wmfishtime-1.24-gtk.patch?rev=1.3&content-type=text/plain
> diff : 
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmfishtime/files/wmfishtime-1.24-gtk.patch?r1=1.2&r2=1.3
>
> Index: wmfishtime-1.24-gtk.patch
> ===
> RCS file: 
> /var/cvsroot/gentoo-x86/x11-plugins/wmfishtime/files/wmfishtime-1.24-gtk.patch,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -r1.2 -r1.3
> --- wmfishtime-1.24-gtk.patch 6 Jun 2011 20:04:49 -   1.2
> +++ wmfishtime-1.24-gtk.patch 22 Jun 2014 16:25:10 -  1.3
> @@ -48,7 +48,7 @@
>   SHELL = sh
>   OBJS = fishmon.o
>  -LIBS = `gtk-config --libs | sed "s/-lgtk//g"`
> -+LIBS = `pkg-config gtk+-2.0 --libs` -lX11
> ++LIBS = `pkg-config gtk+-2.0 --libs` -lm -lX11
>   INSTALL = -m 755
>   
>   all: wmfishtime
>
>
>
>
> gtk+-2.0 --libs` -lm -lX11

This is wrong, it should be:

PKG_CONFIG ?= pkg-config
LIBS = `$(PKG_CONFIG) gtk+-2.0 --libs` -lm -X11

And ebuild should have `export PKG_CONFIG="$(tc-getPKG_CONFIG)"`

As in, PKG_CONFIG needs to be respected from the environment, it's
almost never O.K. to
hardcode pkg-config

I realize you didn't touch that part of the patch right now, but imho,
these should get fixed
whereever spotted.

Thanks,
Samuli

Re: [gentoo-dev] Re: RFC: news item for upower

[Samuli Suominen]

On 04/06/14 19:21, Duncan wrote:
> Rich Freeman posted on Wed, 04 Jun 2014 07:41:23 -0400 as excerpted:
>
>> On Tue, Jun 3, 2014 at 4:24 PM, Alan McKinnon 
>> wrote:
>>> Yes, it *is* a simple matter of running one easy command. Portage does
>>> that for you with trivial ease. But portage doesn't tell you *which* is
>>> the one easy command.
>>>
>>> A news item does that.
>> That is the real challenge here.  It isn't obvious to most users that
>> upower is causing the problem, and it is even less obvious to users
>> without using Google that there is an alternative.
>>
>> Anybody who doesn't read the lists or GMN wouldn't probably wouldn't
>> realize that the simple fix exists.
> This.
>
> It's only simple for me because I saw it right here ahead of time, and 
> it's only simple for ssuominen because he knows about the other choice 
> since he created the package. 

Wrong.   I'm always using the -t (--tree) flag with Portage and I would
have seen upower being the culprit immediately,
and second command would have been `eix upower` to see available
versions, at which point I would have seen
upower-pm-utils, and figured it out.
Just like with any other B blocker that comes up with normal upgrade
process. I've never since 2006 needed to ask
anyone anything regarding blockers, and it has always been trivial to
find out these things. Long before anything
called "news items" even existed.

- Samuli

Re: [gentoo-dev] RFC: news item for upower

[Samuli Suominen]

On 04/06/14 07:11, Samuli Suominen wrote:
> I'm just expecting more from our users. I don't think the news items
> were ever designed for simplistic things like this.
>
>

As in, GLEP 42 Critical News Item != Learning tool for understanding
Portage output

Re: [gentoo-dev] RFC: news item for upower

[Samuli Suominen]

On 04/06/14 01:49, Alan McKinnon wrote:
> On 04/06/2014 00:32, Tom Wijsman wrote:
>> On Tue, 03 Jun 2014 22:24:11 +0200
>> Alan McKinnon  wrote:
>>
>>> The point is, human communication is vastly more powerful
>> +1
>>
>> It might not be clear in the moment, because it looks like a ton of
>> bikeshedding and other ways some individuals would label this; but it
>> will be useful some time from now, when it leads to useful results.
>>
>> Having some people talk about things on a chat, forum, blog, ... might
>> have a short lived effect now with an occasional spike in the future;
>> but, a news item reaches a much wider public for a much longer item.
>>
>> Let's say someone upgrades his system in some weeks / months from now,
>> that person will be thankful that a news item was written about this;
>> instead of having this be part of the already though job of updating.
>>
>> Of course, there is a thing like "too much handholding" but I think
>> that's not the case here as the upower case pops up in a lot of places;
>> one does not have to forget that there is also "too little handholding".
>>
>> If it weren't for genkernel or a kernel seed to help me start out with
>> a booting system, I perhaps might have never started using Gentoo; I've
>> afterwards managed to change my config over time to look nowhere near
>> the original, but at least it makes me happy to have experienced the
>> handholding to bring me where I am today. These "little things" matter.
>>
>
> Indeed. It really comes down to a judgement call whether to compose a
> news item or not.
>
> I myself in my sysadmin day job get this right about 50% of the time if
> I'm lucky. I've learned (via hard knocks) that if a number of people
> raise concerns, then it very well might not be bikeshedding, it might be
> valid. Often as the BOFH I'm too close to the technical problem to
> notice the human elements - that needs a view from 10 feet back.
>
> News items are probably one of Gentoo's best ideas ever.
>
>

I agree, and I'm using news items actively (everyone remembers my udev
related news items you have gotten on every major change, even on
quite small things like configuration filename changes)

All I'm saying is that instructions for simple emerge commands is going
overboard

As in, don't you think I've considered, as a active GLEP 42 user, if there
was a need for one this time? I weighted my options for 3 months before
acting, and people actually agreed with me it wasn't necessary at this
time. I'm really suprised about this, how small group of loud people
on ML can have this kind of effect. It's like, pick a $package_name,
raise enough noise on ML about it, get a news item saying 'emerge '

I'm just expecting more from our users. I don't think the news items
were ever designed for simplistic things like this.

- Samuli

Re: [gentoo-dev] RFC: news item for upower

[Samuli Suominen]

On 03/06/14 21:58, Peter Stuge wrote:
> Steev Klimaszewski wrote:
>> Instead of belittling the users because they are wasting so much of
>> your time
> Causing a rougher transition than neccessary is a waste of users' time.
>
> I don't think that's awesome.
>
>
> //Peter
>

I still don't understand how the news item helps anything, it's all
matter of running
one command, or two at most, `eix upower` after seeing blockers, seeing
2 different
options, selecting which one to go with, emerging it
I'd say such handholding distracts real admins from the real news items
that actually
require paying attention :/

- Samuli

Re: [gentoo-dev] RFC: news item for upower

[Samuli Suominen]

On 03/06/14 18:43, Samuli Suominen wrote:
> I find this useless at this time because the work is in-progress, but in
> order to silence the loud minority,
> please review the news item.
>
> Thanks!
>
> - Samuli
>
>

Will commit this tonight, unless someone has more

- Samuli
Title: UPower loses hibernate / suspend to systemd
Author: Samuli Suominen 
Content-Type: text/plain
Posted: 2014-06-03
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =sys-power/upower-0.99.0'

However, all systemd users are recommended to stay with sys-power/upower.

Re: [gentoo-dev] RFC: news item for upower

[Samuli Suominen]

On 03/06/14 19:26, Tom Wijsman wrote:
> On Tue, 03 Jun 2014 18:53:26 +0300
> Samuli Suominen  wrote:
>
>> Title: UPower discontinued hibernate/suspend support
> https://wiki.gentoo.org/wiki/GLEP:42#News_Item_Headers
>
> You're going to hate me for mentioning this, but that is one character
> too much; 45 > 44 characters. Besides that, I think it would be nice if
> this could indicate systemd somehow.
>
> Some suggestions to brainstorm further:
>
> Title: UPower loses hibernate / suspend to systemd

This works.

> Title: UPower loses suspension to systemd, new fork
> Title: UPower's suspend in systemd or pm-utils fork

I don't want to call it a "fork" just yet.   Albeit, I'm sure it will
evolve into one.

Re: [gentoo-dev] RFC: news item for upower

[Samuli Suominen]

On 03/06/14 18:43, Samuli Suominen wrote:
> I find this useless at this time because the work is in-progress, but in
> order to silence the loud minority,
> please review the news item.
>
> Thanks!
>
> - Samuli
>
>

Added a line, exception for systemd users
Title: UPower discontinued hibernate/suspend support
Author: Samuli Suominen 
Content-Type: text/plain
Posted: 2014-06-03
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =sys-power/upower-0.99.0'

However, all systemd users are recommended to stay with sys-power/upower.

[gentoo-dev] RFC: news item for upower

[Samuli Suominen]

I find this useless at this time because the work is in-progress, but in
order to silence the loud minority,
please review the news item.

Thanks!

- Samuli


Title: UPower discontinued hibernate/suspend support
Author: Samuli Suominen 
Content-Type: text/plain
Posted: 2014-06-03
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: =sys-power/upower-0.99.0'

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 17:45, Chí-Thanh Christopher Nguyễn wrote:
> Samuli Suominen schrieb:
>> On 03/06/14 16:53, Rich Freeman wrote:
>>> So, I get why you did it, but my concern is that when you tell
>>> portage that non-systemd users shouldn't use this package, portage
>>> helpfully solves that problem by turning all the non-systemd users
>>> into systemd users, instead of switching them to the alternative that
>>> works without systemd. 
>> Portage doesn't do anything on it's own, surely it needs an admin to accept
>> or reject the changes
> I disagree. It would have been straightforward to create a transitional
> package sys-power/upower-1 which makes openrc users transition to
> sys-power/upower-pm-utils and systemd users to sys-power/upower-systemd
> or something similar.

No, it wouldn't have, because 0.99.0 is the superior version to which
we are all working towards and 1 would have superceded it
And 0.99.0 is for both, systemd and openrc users

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 16:53, Rich Freeman wrote:
> On Tue, Jun 3, 2014 at 9:46 AM, Samuli Suominen  wrote:
>> To prevent OpenRC users from installing this version because it's
>> an old UPower with no pm-utils support, with no hibernate/suspend support,
>> to ensure desktops don't end up with greyed out Hibernate/Suspend
>> buttons
> So, I get why you did it, but my concern is that when you tell portage
> that non-systemd users shouldn't use this package, portage helpfully
> solves that problem by turning all the non-systemd users into systemd
> users, instead of switching them to the alternative that works without
> systemd.

Portage doesn't do anything on it's own, surely it needs an admin to accept
or reject the changes

It seems we are seeing the severity of something like this diffently, to me,
this belongs to normal Portage functionality, I see something like this
from other packages constantly, I don't understand why this package has
suddently been highlighted like this
It just seems to me people are up in the arms again re: seeing word
"systemd",
when ironically all of this hassle was *for* OpenRC users,
to ensure continuity for them in sys-power/upower-pm-utils where 0.9 git
branch will continue to live
If I hadn't stepped up and blocked the 0.99.0 keywording when it was
originally
about to happen, and then figured a migration path, and then stepped up with
help from pacho2 and tomwij, and migrated the tree like this, we'd have
everyone
on 0.99.0 and no hibernate/suspend for anyone else except systemd users

So, after all the effort we've put in and prepared the tree with OpenRC
users
specifically in mind, if people have to take one or two manual emerge
commands
themselfs, I'm totally fine with that, that's what Gentoo is all about,
choices,
and people who complain about it, really seem like ungrateful over
anything else,
and I'm disappointed. I keep expecting more from our users, the
handholding has
lately gone overboard

I hope that didn't come out wrong, and it certainly wasn't a reply
directly aimed
at you, it was to the thread in general

(I'm still with my original plan, when 0.99.0 goes stable, there will be
multiple bulletin
points to document, news item will be issued)

- Samuli

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 16:40, Tom Wijsman wrote:
> On Tue, 03 Jun 2014 16:28:47 +0300
> Samuli Suominen  wrote:
>
>> On 03/06/14 16:20, Tom Wijsman wrote:
>>> Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag;
>> No, it doesn't.
> Nevermind, `cvs up`-ed; heh, I don't understand how you've got to
> that change, I thought there only was a problem with 0.99.0?
>
>>>  in comparison, 0.99.0 mainly wants you to run it with systemd:
>> "mainly", as in, since 0.99.0 removed support for hibenate/suspend
>> in favour of systemd, the power/session managers need to integrate
>> their own hibernate/suspend support diffently.
> Ah, right; thinking of MATE, I understand the 0.99.0 bit now.
>
>>>   26 May 2014; Samuli Suominen 
>>>   upower-0.99.0.ebuild: This release is mainly for use with
>>>   sys-apps/systemd because upstream removed support for
>>>   sys-power/pm-utils completely from git master. The 0.9 branch is
>>> for sys-power/pm-utils use. Adjust ebuild accordingly.
>>>
>>> Though I'm a bit confused why 0.99.0 doesn't list a systemd
>>> dependency; I thought it had one, but maybe it is in another
>>> package I'm unaware of.
>>>
>> Outdated ChangeLog entry from March, those were the facts we dealt
>> back then,
>> only partly true anymore, consumers have evolved
> Which means that the situation I am assuming right now is outdated; so,
> if you don't mind feel free to highlight why 0.9.23-r3 needs systemd.
>

To prevent OpenRC users from installing this version because it's
an old UPower with no pm-utils support, with no hibernate/suspend support,
to ensure desktops don't end up with greyed out Hibernate/Suspend
buttons
To direct users to upower-pm-utils, or upower-0.99.0, or plain pm-utils, or
other
To indicate OpenRC users can't stay with sys-power/upower older than 0.99.0
because they are going away, to indicate this is the best time to make
informed decision and take manual action regarding choosing which
features set he/she wants, to read up upstream announcements regarding
UPower, to follow-up and do what admins do

- Samuli

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 16:20, Tom Wijsman wrote:
>> This has already hit stable.  The dependency on systemd is present in
>> sys-power/upower-0.9.23-r3, which was just stablized.
> Ehm, no, version 0.9.23-r3 controls that with a systemd USE flag;

No, it doesn't.

>  in comparison, 0.99.0 mainly wants you to run it with systemd:

"mainly", as in, since 0.99.0 removed support for hibenate/suspend
in favour of systemd, the power/session managers need to integrate
their own hibernate/suspend support diffently.
For example, I'm using Xfce, OpenRC, UPower 0.99.0, pm-utils, Xfce 4.11+
and I have hibernate/suspend working just fine without systemd.
And UPower is for much more than hibernate/suspend, it has dozens of
features, so anykind of systemd dependency on 0.99.0 wouldn't make sense

>
>   26 May 2014; Samuli Suominen 
>   upower-0.99.0.ebuild: This release is mainly for use with
>   sys-apps/systemd because upstream removed support for
>   sys-power/pm-utils completely from git master. The 0.9 branch is for
>   sys-power/pm-utils use. Adjust ebuild accordingly.
>
> Though I'm a bit confused why 0.99.0 doesn't list a systemd dependency;
> I thought it had one, but maybe it is in another package I'm unaware of.
>

Outdated ChangeLog entry from March, those were the facts we dealt back
then,
only partly true anymore, consumers have evolved

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 15:08, Tom Wijsman wrote:
> On Tue, 3 Jun 2014 07:35:42 -0400
> Rich Freeman  wrote:
>
>> This probably could have used a news item, as the change impacts both
>> stable and ~arch users.
> Are we going to write a news item every time systemd acquires a new
> mandatory relationship with a reverse dependency?

IMHO, not every singular dependency change (even blocker) needs one.
For those failing to read `eix upower` or `emerge -C upower` or masking
systemd, or number of other ways the blocker can be solved, the answer
is in Gentoo news letter, forums, first hits in Google, /topic of #gentoo at
Freenode, MLs, pretty much everywhere.

But news item has been planned all along for when UPower 0.99.0 goes
stable, propably
GNOME 3.12 and some 0.99.0 consumers, when there are enough steps to
accumulate as news worthy.

- Samuli

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 03/06/14 14:40, J. Roeleveld wrote:
> Would have been nice to fix all the dependencies BEFORE marking the
> systemd- depending "sys-power/upower-pm-utils" stable. -- Joost 

No clue what you mean, sys-power/upower-pm-utils doesn't depend on
sys-apps/systemd,
and whole Portage tree is converted to proper dependencies and the
conversion went in
the correct steps.
If you need support for understanding Portage's output, try the
gentoo-user mailing list.

- Samuli

[gentoo-dev] Remember to add your freedesktop.org specification respecting desktop to freedesktop-bugs@g.o mail alias (eg. lxqt, lxde, mate)

[Samuli Suominen]

Friendly reminder to maintainers of these new desktops that have been
'recently' added to Portage that
you should include your herd to freedesktop-b...@gentoo.org mail alias,
as it's meant to be a shared
among all the desktops. The old school desktops like gnome, kde and xfce
are there, so these new ones
like lxqt, lxde, mate, and whatever else which at least mostly respect
the freedesktop.org XDG standards
and specifications should be there too.
Then you will be a maintainer for dbus, notification-daemon, and so
forth too, and don't need any prior
permissions for fixing them. As in, makes your life easier.

- Samuli

Re: [gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention

[Samuli Suominen]

On 01/06/14 18:48, Mikle Kolyada wrote:
> 01.06.2014 15:18, Samuli Suominen пишет:
>> http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing
>> the new virtuals,
>> and thus, converting the tree, and also blocking stabilization of the
>> already converted packages (gnome seems to have some)
>> pending for 3 months already
>>
>> thanks,
>> samuli
>>
> Is compile only test enough for you? If so, i can take care about it
> right now.
>

yes, compile test is enough, because the changes are not that large
compared to current stable

[gentoo-dev] alpha, ia64, ppc, ppc64, sparc developers, need your attention

[Samuli Suominen]

http://bugs.gentoo.org/show_bug.cgi?id=505962#c6 is blocking stabilizing
the new virtuals,
and thus, converting the tree, and also blocking stabilization of the
already converted packages (gnome seems to have some)
pending for 3 months already

thanks,
samuli

Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?

[Samuli Suominen]

On 31/05/14 23:00, Robin H. Johnson wrote:
> On Sat, May 31, 2014 at 10:46:35PM +0300, Samuli Suominen wrote:
>> The patch in the bug is not enough. Notice
>> http://bugs.gentoo.org/show_bug.cgi?id=461828#c13
>> Those should be reseted to "" too.
> Read what I applied, I did set it to "".
>

Thanks, looks good.   Can we go with fast stabilizing this version?

Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?

[Samuli Suominen]

On 31/05/14 22:41, Robin H. Johnson wrote:
> On Fri, May 30, 2014 at 06:10:40PM +0300, Samuli Suominen wrote:
>> I can't find anyone with access that actually replies to mails, pings,
>> ... to genkernel repository for:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=461828
>>
>> I'll p.mask it on amd64 profiles if noone replies soon :(
> My excuse is AFK baby, literally sleeping on me right now, and not even
> 2 months old.
>
> I saw floppym's original comment opening the bug, but none of the
> followups due to baby eating my life.
>
> I'll apply this patch later today if I have a chance, but I do agree
> with the general sentiment of this thread that the kernel configs NEED
> to get out of genkernel; so that arches can touch them at will, and
> other initramfs/kernel build tools can start to use them.
>
> In the absence of any other prompt complaints, I'll create a
> kernel-configs repo, and move the configs there.
>
> The one thing that WILL have to be maintained in genkernel still, and
> in-sync with kernel changes, are the modules_load files,  esp when new
> common stuff is added to the kernel (disk controllers & filesystems most
> commonly).
>

The patch in the bug is not enough. Notice
http://bugs.gentoo.org/show_bug.cgi?id=461828#c13
Those should be reseted to "" too.

Thanks,
Samuli

Re: [gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 31/05/14 05:47, Steven J. Long wrote:
> On Tue, May 27, 2014 at 09:57:01AM +0300, Samuli Suominen wrote:
>> On 27/05/14 08:34, Michał Górny wrote:
>>> Dnia 2014-05-26, o godz. 23:15:34
>>> Samuli Suominen  napisał(a):
>>>
>>>> UPower upstream removed sys-power/pm-utils support from 0.99 release
>>>> (currently unkeyworded in tree), as in, from current git master.
>>> Don't worry. Looking at the past, I can guess this is only a temporary
>>> inconvenience. I'm pretty sure upower will be discontinued soon
>>> and replaced with systemd-powerd or something :D.
>>>
>> That's more or less what they already did, they forced eg.
>> xfce4-power-manager upstream
>> to move the deleted pm-utils code from upower directly to the power
>> manager (application)
>> itself, likewise for xfce4-session
>> Which means applications will now need to duplicate the pm-utils related
>> code per application
>> basis
>> So I expect upower to be more or less dead for everything but systemd
>> users, except for
>> those upstreams that will actually follow the Xfce path and do the
>> duplication
>> Yet, still, small portition of the code is still 'generic', so
>> xfce4-power-manager will still need
>> both, upower, even 0.99, and then pm-utils, depending on the version,
>> codepath is selected
>>
>> This was sort of expected, since pm-utils has been abandoned for ~5
>> years now at upstream,
>> so nobody is maintaining non-systemd related power management tools
>> anymore, and
>> falling back to eg. manual laptop-mode-tools, acpid, etc. usage will be
>> necessary again,
>> it's like going back to 90s for non-systemd users :P
> I can't believe I'm reading that from a distro-developer. Basically this
> entire thread is "systemd is deprecating the existing tools, so let's dump
> them and half our userbase back to the 90s, isn't that a great thing?"

Then you misunderstood. Notice the ":P" as an indicator of sarcasm.
I've already created sys-power/upower-pm-utils where the sys-power/pm-utils
0.9 git branch will continue to live.

Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?

[Samuli Suominen]

On 30/05/14 19:16, Samuli Suominen wrote:
> On 30/05/14 19:10, Tom Wijsman wrote:
>> On Fri, 30 May 2014 18:10:40 +0300
>> Samuli Suominen  wrote:
>>
>>> I can't find anyone with access that actually replies to mails, pings,
>>> ... to genkernel repository for:
>>>
>>> https://bugs.gentoo.org/show_bug.cgi?id=461828
>>>
>>> I'll p.mask it on amd64 profiles if noone replies soon :(
>>>
>>> - Samuli
>>>
>> Here is a reply!
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=461828#c8
>>
>> Please no p.mask for a single line being wrong...
>>
>> Maybe it is time undertakers free this package to be up for grabs?
>>
> Here is another,
>
> https://bugs.gentoo.org/show_bug.cgi?id=461828#c13
>
> Also alpha and x86 are broken, and the generic config is broken too
>
> :(
>

I'll give it 48 hours and then p.mask it. I won't be fixing it. Status
quo can't stand, it's like shooting
users to head by default. I have no plans in inserting my name to
genkernel's ChangeLog,
and I've done my best to contact people (nobody cares)

Only initramfs tool I care and can warmly recommend to anyone is dracut.

- Samuli

Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?

[Samuli Suominen]

On 30/05/14 19:10, Tom Wijsman wrote:
> On Fri, 30 May 2014 18:10:40 +0300
> Samuli Suominen  wrote:
>
>> I can't find anyone with access that actually replies to mails, pings,
>> ... to genkernel repository for:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=461828
>>
>> I'll p.mask it on amd64 profiles if noone replies soon :(
>>
>> - Samuli
>>
> Here is a reply!
>
> https://bugs.gentoo.org/show_bug.cgi?id=461828#c8
>
> Please no p.mask for a single line being wrong...
>
> Maybe it is time undertakers free this package to be up for grabs?
>

Here is another,

https://bugs.gentoo.org/show_bug.cgi?id=461828#c13

Also alpha and x86 are broken, and the generic config is broken too

:(

[gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?

[Samuli Suominen]

I can't find anyone with access that actually replies to mails, pings,
... to genkernel repository for:

https://bugs.gentoo.org/show_bug.cgi?id=461828

I'll p.mask it on amd64 profiles if noone replies soon :(

- Samuli

Re: [gentoo-dev] UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

On 27/05/14 08:34, Michał Górny wrote:
> Dnia 2014-05-26, o godz. 23:15:34
> Samuli Suominen  napisał(a):
>
>> UPower upstream removed sys-power/pm-utils support from 0.99 release
>> (currently unkeyworded in tree), as in, from current git master.
> Don't worry. Looking at the past, I can guess this is only a temporary
> inconvenience. I'm pretty sure upower will be discontinued soon
> and replaced with systemd-powerd or something :D.
>

That's more or less what they already did, they forced eg.
xfce4-power-manager upstream
to move the deleted pm-utils code from upower directly to the power
manager (application)
itself, likewise for xfce4-session
Which means applications will now need to duplicate the pm-utils related
code per application
basis
So I expect upower to be more or less dead for everything but systemd
users, except for
those upstreams that will actually follow the Xfce path and do the
duplication
Yet, still, small portition of the code is still 'generic', so
xfce4-power-manager will still need
both, upower, even 0.99, and then pm-utils, depending on the version,
codepath is selected

This was sort of expected, since pm-utils has been abandoned for ~5
years now at upstream,
so nobody is maintaining non-systemd related power management tools
anymore, and
falling back to eg. manual laptop-mode-tools, acpid, etc. usage will be
necessary again,
it's like going back to 90s for non-systemd users :P

- Samuli

[gentoo-dev] Re: UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

Note: If you want to convert your ebuild, you can /msg ssuominen on
Freenode and
post an ebuild diff, I can quickly review if the dependency changes are
OK for you,
or clarify anything else you want regarding this.

Sorry, I know this unorthodox workflow, but I'm too sick to even
properly sit in the
chair currently, and people keep poking me regarding the issue, over any
other issues ;-(

On 26/05/14 23:15, Samuli Suominen wrote:
> UPower upstream removed sys-power/pm-utils support from 0.99 release
> (currently unkeyworded in tree),
> as in, from current git master.
> UPower upstream created 0.9 bit branch that has the old legacy upower
> with sys-power/pm-utils support
> available still with --enable-deprecated.
>
> So, sys-power/upower will move on to 0.99 and is, thus, mostly usable
> only for sys-apps/systemd users,
> however, Xfce upstream in git master already moved the
> sys-power/pm-utils code that upower had
> over directly to the apps, like xfce4-session and xfce4-power-manager,
> and will, after next releases,
> still work without sys-apps/systemd even with 0.99 version.
>
> What was done?
>
> sys-power/upower-pm-utils was created where we will maintain upower 0.9
> git branch, currently it's identical
> to =sys-power/upower-0.9.23-r2, but will soon be a git snapshot instead.
>
> What needs to be done before we can keyword >=sys-power/upower-0.99?
>
> See examples of uevt, wmbattery, xfce4-session, xfce4-settings,
> xfce4-power-manager, xfce4-systemload-plugin,
> xfce4-weather-plugin which I already converted (mostly) from this list:
>
> http://qa-reports.gentoo.org/output/genrdeps/rindex/sys-power/upower
>
> Other are all undone, as in, converting deps to what they actually support:
>
> || ( sys-power/upower sys-power/upower-pm-utils ) where everything is
> supported
> || (  upower with pm-utils is supported
>> =sys-power/upower-0.99 where new API is mandatory, currently this would
> only be >= GNOME 3.12 stuff
> well, figure it out, these are just examples
>
> Confusing bug 508920 also exists, but most of the conversation there is
> outdated
>
> I'm going to spinal surgery this friday, and I propably don't have
> health, time, or motivation to open a Tracker
> bug and file all the bugs for the reverse deps this week at all.
> Thus, I propably won't be working on this much this week at all. Things
> are OK as they are now in Portage,
> because >=sys-power/upower-0.99 is not keyworded yet, so nothing is
> broken, it's just work undone.
>
> I know GNOME folks want to get it done, because GNOME 3.12 stuff
> actually needs upower-0.99, but I'm
> saying they can NOT keyword the version without fixing rest of the tree
> before doing so as described
> above. So help me out, or wait it out (like 2 weeks).
>
> Thanks,
> Samuli

[gentoo-dev] UPower upstream (git master) and 0.99 release -> No sys-power/pm-utils support anymore

[Samuli Suominen]

UPower upstream removed sys-power/pm-utils support from 0.99 release
(currently unkeyworded in tree),
as in, from current git master.
UPower upstream created 0.9 bit branch that has the old legacy upower
with sys-power/pm-utils support
available still with --enable-deprecated.

So, sys-power/upower will move on to 0.99 and is, thus, mostly usable
only for sys-apps/systemd users,
however, Xfce upstream in git master already moved the
sys-power/pm-utils code that upower had
over directly to the apps, like xfce4-session and xfce4-power-manager,
and will, after next releases,
still work without sys-apps/systemd even with 0.99 version.

What was done?

sys-power/upower-pm-utils was created where we will maintain upower 0.9
git branch, currently it's identical
to =sys-power/upower-0.9.23-r2, but will soon be a git snapshot instead.

What needs to be done before we can keyword >=sys-power/upower-0.99?

See examples of uevt, wmbattery, xfce4-session, xfce4-settings,
xfce4-power-manager, xfce4-systemload-plugin,
xfce4-weather-plugin which I already converted (mostly) from this list:

http://qa-reports.gentoo.org/output/genrdeps/rindex/sys-power/upower

Other are all undone, as in, converting deps to what they actually support:

|| ( sys-power/upower sys-power/upower-pm-utils ) where everything is
supported
|| ( =sys-power/upower-0.99 where new API is mandatory, currently this would
only be >= GNOME 3.12 stuff
well, figure it out, these are just examples

Confusing bug 508920 also exists, but most of the conversation there is
outdated

I'm going to spinal surgery this friday, and I propably don't have
health, time, or motivation to open a Tracker
bug and file all the bugs for the reverse deps this week at all.
Thus, I propably won't be working on this much this week at all. Things
are OK as they are now in Portage,
because >=sys-power/upower-0.99 is not keyworded yet, so nothing is
broken, it's just work undone.

I know GNOME folks want to get it done, because GNOME 3.12 stuff
actually needs upower-0.99, but I'm
saying they can NOT keyword the version without fixing rest of the tree
before doing so as described
above. So help me out, or wait it out (like 2 weeks).

Thanks,
Samuli

Re: [gentoo-dev] Re: Banning modification of pkg-config files

[Samuli Suominen]

On 12/05/14 22:25, Peter Stuge wrote:
 (Are we seriously discussing banning something useful as pkg-config
 files?! That's retarded. Must be some joke.)
>>> I don't think I said to ban them. I said that I want Gentoo to stay
>>> close to upstream by default. I also said that maintainers shouldn't
>>> be expected to untie upstream bugknots.
>>>
>>> Please do not call me retarded again.
>> That might have been meant to be about the thread as a whole.
> All right, fair enough there too.
>
>
> Thanks
>
> //Peter

Sorry, yes, I meant the thread as a whole of course.

Re: [gentoo-dev] Re: Banning modification of pkg-config files

[Samuli Suominen]

On 12/05/14 20:47, Peter Stuge wrote:
> Rich Freeman wrote:
>>> Longterm, this makes it year after year more difficult to develop
>>> software for "Linux".
>> I'm with you here, but what is the solution?
>>
>> If we say we stick to upstream then we don't provide pkg-config files
>> at all (in these cases).
> I think this is a sane default.

Except having pkg-config is the only way to fix some of the build issues
we are seeing
today, like getting 'Libs.private: ' for static linking, there has been
multiple bugs lately,
and we are in middle of process of obsoleting every custom foo-config
due to same
reasons, so having pkg-config files is an absolute requirement.
Some binary-only distros might get away without them, but we won't.

>
>
>> Then when Debian does the other upstreams use them and then those
>> packages break on Gentoo.
> I like Gentoo to stay very close to upstream.
>
> If upstream pkg A depends on $distro-specific foo of pkg B then that
> will obviously not work in an environment only following upstreams,
> and will require effort to untie gentoo pkg A from $distro specifics.

pkg-config by design works without .pc files if needed, by exporting
FOO_LIBS
and FOO_CFLAGS, so if this is the only problem with them, it's really no
problem
at all compared to the problems caused by lacking the pkg-config files


(Are we seriously discussing banning something useful as pkg-config
files?! That's retarded. Must be some joke.)

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/libsdl2/files: libsdl2-2.0.3-static-libs.patch

[Samuli Suominen]

On 12/05/14 18:56, Julian Ospald (hasufell) wrote:
> hasufell14/05/12 15:56:05
>
>   Added:libsdl2-2.0.3-static-libs.patch
>   Log:
>   version bump
>   
>   (Portage version: 2.2.10/cvs/Linux x86_64, signed Manifest commit with key 
> BDEED020)
>
> Revision  ChangesPath
> 1.1  media-libs/libsdl2/files/libsdl2-2.0.3-static-libs.patch
>
> file : 
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/libsdl2/files/libsdl2-2.0.3-static-libs.patch?rev=1.1&view=markup
> plain: 
> http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/libsdl2/files/libsdl2-2.0.3-static-libs.patch?rev=1.1&content-type=text/plain
>
> Index: libsdl2-2.0.3-static-libs.patch
> ===
> --- SDL2-2.0.2.orig/Makefile.in
> +++ SDL2-2.0.2/Makefile.in
> @@ -33,10 +33,10 @@
>  OBJECTS = @OBJECTS@
>  VERSION_OBJECTS = @VERSION_OBJECTS@
>  
> -SDLMAIN_TARGET = libSDL2main.a
> +SDLMAIN_TARGET = libSDL2main.la
>  SDLMAIN_OBJECTS = @SDLMAIN_OBJECTS@
>  
> -SDLTEST_TARGET = libSDL2_test.a
> +SDLTEST_TARGET = libSDL2_test.la
>  SDLTEST_OBJECTS = @SDLTEST_OBJECTS@
>  
>  SRC_DIST = *.txt acinclude Android.mk autogen.sh android-project 
> build-scripts cmake configure configure.in debian include Makefile.* 
> sdl2-config.in sdl2.m4 sdl2.pc.in SDL2.spec.in src test VisualC.html VisualC 
> Xcode Xcode-iOS
> @@ -123,15 +123,13 @@
>  .PHONY: all update-revision install install-bin install-hdrs install-lib 
> install-data uninstall uninstall-bin uninstall-hdrs uninstall-lib 
> uninstall-data clean distclean dist $(OBJECTS:.lo=.d)
>  
>  $(objects)/$(TARGET): $(OBJECTS) $(VERSION_OBJECTS)
> - $(LIBTOOL) --mode=link $(CC) -o $@ $(OBJECTS) $(VERSION_OBJECTS) 
> $(LDFLAGS) $(EXTRA_LDFLAGS) $(LT_LDFLAGS)
> + $(LIBTOOL) --mode=link $(CC) $(CFLAGS) -o $@ $^ $(LDFLAGS) 
> $(EXTRA_LDFLAGS) $(LT_LDFLAGS)

You know that adding $(LDFLAGS) so late in the linker line makes whole
-Wl,--as-needed get ignored? Should almost certainly be $(CC) $(LDFLAGS)
$(CFLAGS) ...

- Samuli

Re: [gentoo-dev] RFC: using .xz for doc/man/info compression

[Samuli Suominen]

On 11/05/14 20:46, Michał Górny wrote:
> Hello, developers.
>
> I'd like to raise the following item for discussion: making .xz
> the default compressor used by portage for documentation, man pages
> and info files. That is, the equivalent of:
>
>   PORTAGE_COMPRESS=xz
>
> in make.globals.
>
>

I like it, I've been using it myself from make.conf with the current
install on this machine.

But no, I don't have size or speed comparison to give :/

- Samuli

Re: [gentoo-dev] Re: Banning modification of pkg-config files

[Samuli Suominen]

On 10/05/14 12:39, Markos Chandras wrote:
> On 05/10/2014 07:31 AM, Alexandre Rostovtsev wrote:
>> On Sat, 2014-05-10 at 13:50 +0800, Ben de Groot wrote:
>>> On 10 May 2014 04:34, Markos Chandras  wrote:
 On 05/09/2014 09:32 PM, Tom Wijsman wrote:
> On Fri, 9 May 2014 16:15:58 -0400
> Rich Freeman  wrote:
>
>> I think fixing upstream is a no-brainer.
> It indeed is, this is the goal; you can force them in multiple ways,
> some of which can be found on the Lua bug and previous discussion(s).
>
>> The controversy only exists when upstream refuses to cooperate (which
>> seems to be the case when we're one of six distros patching it).  If
>> there are other situations where we supply our own files please speak
>> up.
> Not that I know of; the refusal to cooperate is what this is all about,
> see my last response to hwoarang before this mail for a short summary.
> Though, I think that the Lua maintainers can explain all the details...
>
>> When the only issue is maintainer laziness I could see fixing that in
>> a different way...
> It has always been an issue; we could always use more manpower, ...
>
> https://wiki.gentoo.org/wiki/Contributing_to_Gentoo
>
 Well to me it feels that gentoo specific .pc files is a similar problem
 to any other patch that affects upstream code in order to make the
 package compatible with gentoo. Some people may consider downstream pc
 files more dangerous because reverse deps are affected. But really, if
 there is no other alternative, we shouldn't be treating this as a
 special case. We patch upstream packages all the time after all
>>> Exactly. I don't understand why this is an issue at all. Obviously,
>>> if upstream does not ship a .pc file or ships a broken one, we try
>>> to work with upstream to get it fixed on their end. If they are
>>> uncooperative, we fix it on our end.
>> Adding a pkgconfig file is a bit of a special case. Some distros have a
>> habit of renaming and creating .pc files for various libraries.
> Isn't this the same thing? If Debian creates/renames upstream pc files,
> and you use Debian as a development box, you have the same problem:
> Develop software which is not portable across distros.

Say, a package XYZ makes use of xyz.pc and it's distribution specific,
then you switch to a distribution that also ships XYZ but without
pkg-config file,
you can simply...

export FOOBAR_LIBS="-lfoo"
export FOOBAR_CFLAGS="-I/usr/include/foo"
./configure
make
make install

...as pkg-config allows using it without the .pc files by design. This
is an non-issue.

- Samuli

Re: [gentoo-dev] Some tarballs still ship broken .png images that can't be viewed with libpng16, "Tracker" bug #468386

[Samuli Suominen]

On 08/04/14 23:26, Pacho Ramos wrote:
> El mar, 08-04-2014 a las 22:25 +0300, Samuli Suominen escribió:
>> On 08/04/14 22:26, Pacho Ramos wrote:
>>> El mar, 08-04-2014 a las 16:14 +0300, Samuli Suominen escribió:
>>>> It would take considerably amount of time to start extracting tarballs,
>>>> installing ebuilds, and reporting bugs about possible
>>>> broken .png files within packages.
>>>> The problem is broken IDAT lenght, an error that libpng15 still
>>>> gracefully ignored, but libpng16 no longer ignores.
>>>>
>>>> The bug, http://bugs.gentoo.org/468386
>>>> List created by Tobias at 2013 May,
>>>> https://bugs.gentoo.org/attachment.cgi?id=347306
>>>> <mailto:klaus...@gentoo.org>
>>>>
>>>> This has been discussed on the ML before, and most important packages
>>>> got already fixed, but there are packages still
>>>> left. Any help addressing the issue is welcome, and I'm sending this
>>>> mail in hopes people will see packages on the lists
>>>> that intrest them, and fix them.
>>>>
>>>> Thanks,
>>>> Samuli
>>>> <mailto:klaus...@gentoo.org>
>>>>
>>> If there exists a tool that detects that broken png files, maybe a QA
>>> portage check (like the one used to detect broken .desktop files) could
>>> be added to help to detect and fix the problematic images :/
>>>
>>>
>> Pretty good idea, there is the script in python, and Portage is python,
>> maybe it can be adopted somehow.
>>
>> The script is at, https://bugs.gentoo.org/show_bug.cgi?id=466190#c11
>>
>> - Samuli
>>
> Probably we will need to open a bug report, do you prefer to report that
> one or should I? ;)
>
>

https://bugs.gentoo.org/show_bug.cgi?id=507172

Re: [gentoo-dev] Some tarballs still ship broken .png images that can't be viewed with libpng16, "Tracker" bug #468386

[Samuli Suominen]

On 08/04/14 22:26, Pacho Ramos wrote:
> El mar, 08-04-2014 a las 16:14 +0300, Samuli Suominen escribió:
>> It would take considerably amount of time to start extracting tarballs,
>> installing ebuilds, and reporting bugs about possible
>> broken .png files within packages.
>> The problem is broken IDAT lenght, an error that libpng15 still
>> gracefully ignored, but libpng16 no longer ignores.
>>
>> The bug, http://bugs.gentoo.org/468386
>> List created by Tobias at 2013 May,
>> https://bugs.gentoo.org/attachment.cgi?id=347306
>> <mailto:klaus...@gentoo.org>
>>
>> This has been discussed on the ML before, and most important packages
>> got already fixed, but there are packages still
>> left. Any help addressing the issue is welcome, and I'm sending this
>> mail in hopes people will see packages on the lists
>> that intrest them, and fix them.
>>
>> Thanks,
>> Samuli
>> <mailto:klaus...@gentoo.org>
>>
> If there exists a tool that detects that broken png files, maybe a QA
> portage check (like the one used to detect broken .desktop files) could
> be added to help to detect and fix the problematic images :/
>
>

Pretty good idea, there is the script in python, and Portage is python,
maybe it can be adopted somehow.

The script is at, https://bugs.gentoo.org/show_bug.cgi?id=466190#c11

- Samuli

Re: [gentoo-dev] Some tarballs still ship broken .png images that can't be viewed with libpng16, "Tracker" bug #468386

[Samuli Suominen]

On 08/04/14 16:14, Samuli Suominen wrote:
> <mailto:klausman...>
> <mailto:klausman...>
>

No idea how that happened. I blame Thunderbird.

[gentoo-dev] Some tarballs still ship broken .png images that can't be viewed with libpng16, "Tracker" bug #468386

[Samuli Suominen]

It would take considerably amount of time to start extracting tarballs,
installing ebuilds, and reporting bugs about possible
broken .png files within packages.
The problem is broken IDAT lenght, an error that libpng15 still
gracefully ignored, but libpng16 no longer ignores.

The bug, http://bugs.gentoo.org/468386
List created by Tobias at 2013 May,
https://bugs.gentoo.org/attachment.cgi?id=347306


This has been discussed on the ML before, and most important packages
got already fixed, but there are packages still
left. Any help addressing the issue is welcome, and I'm sending this
mail in hopes people will see packages on the lists
that intrest them, and fix them.

Thanks,
Samuli

[gentoo-dev] Stabilization of netifrc-0.2.2, "extra testers wanted"

[Samuli Suominen]

Extra testers requested for netifrc-0.2.2 stabilization, also, if you
know a reason this shouldn't go stable, like
regression from 0.1, speak up now.

See, http://bugs.gentoo.org/507070

(I'm purposely special casing this package over others like this.)

- Samuli

Re: [gentoo-dev] Change or revert the "30 days maintainer timeout" stabilization policy

[Samuli Suominen]

On 07/04/14 01:57, Rick "Zero_Chaos" Farina wrote:
> On 04/02/2014 02:22 PM, Mike Gilbert wrote:
> > On Wed, Apr 2, 2014 at 12:52 PM, Samuli Suominen
>  wrote:
> >> The "30 days maintainer time out" stabilization policy isn't working
> >> when package has multiple SLOTs, because
> >> the bugs are filed for only latest SLOT, where as some packages require
> >> stabilization in sync at both SLOTs
> >>
> >> Option 1:
> >>
> >> Either revert the whole policy, and never CC arches on unanswered bugs
> >> when the package has a maintainer,
> >> and let him do it when he finds the time himself, and if that doesn't
> >> happen, wait until it's dropped to maintainer-needed@
> >>
> >> Option 2:
> >>
> >> Or, the person who is CCing the arches in 30 days timeout, needs to
> make
> >> sure the bug covers all SLOT at the same time
> >>
> >>
> >> The status quo no longer allows me to maintain stable version of
> >> dev-libs/girara, app-text/zathura*, and the issue needs
> >> to be addressed, see http://bugs.gentoo.org/502714 for what inspired
> >> this mail
> >>
> >> - Samuli
> >>
>
> > If you want to prevent packages from being "timed out", just leave a
> > comment on the bug saying so. If you don't even have time to do that
> > within a 30 day window, why are you the maintainer?
>
> > Another option would be to add some kind of notation to metadata.xml.
>
>
> I've long been a proponent of freeform notes in the metadata.  

Like you said, doesn't suit this case.

> I think
> leaving a note in there is very helpful for developers, however, in this
> case unless the note is standardized and the auto-stable script is
> updated I fear this won't help anyone.
>

I agree, this is the best solution, something like
no that can
then be parsed by whatever scripts.
I could work with that, and to ease that, I believe it should be part of
the default metadata.xml template in a way of
'yes', so it can then be easily changed to 'no'
I'd just add it to dev-libs/girara, app-text/zathura,
app-text/zathura-meta, and everything it deps on, the plugins.
Also, to every package that has xfce
And to every package I maintain that's important for core system, say,
eg. libffi (albeit I've tried to push that particular
package to toolchain@ for a while now, but ChangeLog speaks for itself)

- Samuli

Re: [gentoo-dev] News item draft for >=sys-fs/udev-209 upgrade

[Samuli Suominen]

On 02/04/14 23:15, Rick "Zero_Chaos" Farina wrote:
> On 02/24/2014 12:32 AM, Samuli Suominen wrote:
> > If it's okay, I'd want to post this fast, before adding KEYWORDS to
> > sys-fs/udev-209's ebuild
>
>
> Should means required now? Man if I only knew that last week...
>

Sorry?

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 02/04/14 23:07, Rick "Zero_Chaos" Farina wrote:
> On 04/02/2014 02:00 AM, Samuli Suominen wrote:
>
> > On 02/04/14 05:02, Matt Turner wrote:
> >> On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman  wrote:
> >>> Projects like the Council, ComRel and QA are there to protect Gentoo;
> >>> and yes, people are (or should be) lining up to protect Gentoo.
> >> ... from QA.
> >>
> >> You don't seem to understand what Samuli is saying. QA is being used
> >> as an offensive weapon. It's a stick to bludgeon others with.
> >>
>
> > Exactly.
>
> > Anyone remembers what happened the last time this was tried?
>
> > The "QA" attempted to force developers who didn't care if removed
> > ebuilds are recorded in the ChangeLog or
> > not, even while there was no policy in place that said they should be
> > recorded there, and nothing was ever broken.
> > People simply had different workflows.
>
> > The whole existing team died with that debacle. I don't expect it to go
> > exactly like that, this time, as the issue and
> > people involved are different, but the point is, nothing good came out
> > of it.
> > If the people who insisted they should be recorded there had been in a
> > productive fashion drive repoman to be
> > patched for --echangelog, or discuss other solutions, we could have
> > skipped the useless mudslinging.
>
> > Force is not hardly ever the correct answer. It might work in a
> > workplace, but not when people are contributing
> > for free.
>
> So forcing changes into the tree by stabilizing a bunch of new virtuals
> and adjusting all the rdeps to use them is fine, but forcing discussion
> is completely inappropriate?
>
> Wow, now that I can see it your way I agree, I'm a horrible person.
> I'll stick to randomly changing the tree as I see fit with no discussion
> since forced discussion is so wrong.

I've been constantly maintaining this has been discussed many times
earlier, and it
was in fact part of what council voted upon when they agreed subslot use
in gentoo-x86
What you tried to do, is force me to open a new thread about it, and I
told you,
you should be opening the thread yourself if you see the discussion
being useful,
because I didn't.

Part of the discussion done in #gentoo-dev, from yesterday:

20:51 <@_AxS_> Zero_Chaos: ping, re subslots and virtuals
20:53 <@_AxS_> Zero_Chaos: before EAPI5, I did a fair bit of testing
with virtuals and subslots, specifically in this case to manage the
split-up between the
three ABIs in xorg-server.  It works fine, the way it's being used by
lib{,g}udev.  Where it doesn't work is in the general case -- when
RDEPEND in
a virtual/* package depends on other libs without specific subslot or
version info, and those other libs bump subslot, then this doesn't
propagate
through to the rdeps of the virtual.
20:55 <@_AxS_> So long as the maintainers of a virtual's deps want to
bump the virtual and ensure its RDEPEND is explicitly linked to the
dep's subslot, this'll
work fine.  It's just a lot of work to do that, is all.
21:11 <@ssuominen> _AxS_: Didn't you blog about the virtuals and
subslots? I remember someone did, and I remember what's where I picked
up the whole idea in the first place.
21:12 <@_AxS_> ssuominen: the subslot section of the wiki, iirc, yes
21:13 <@_AxS_> Also mentioned it in here a few times over, a year or
more ago
21:13 <@ssuominen> There we go then, and the link to the wiki...? was
posted in the threads when the subslots were introduced
21:14 <@ssuominen> Just saying, I've consistently maintained this was
not some new idea, and part of my reasoning was that it was talked
about, and I considered
that part of the subslot use to be part of what council agreed on, when
they allowed the subslots in gentoo-x86
21:17 <@_AxS_> ssuominen: i'm with you on that..  The one thing I don't
follow with this thread is that virtual/lib*udev is still a proper
virtual -- that is,
it's providing choice between multiple packages.  it's not like it's
-only there- to represent the elements of a single package.

See, http://wiki.gentoo.org/wiki/Sub-slots_and_Slot-Operators#Use_Virtuals

Also, I don't think you are a horrible person, and I can surely put this
all past us, but can you?

- Samuli

Re: [gentoo-dev] Change or revert the "30 days maintainer timeout" stabilization policy

[Samuli Suominen]

On 02/04/14 21:22, Mike Gilbert wrote:
> On Wed, Apr 2, 2014 at 12:52 PM, Samuli Suominen  wrote:
>> The "30 days maintainer time out" stabilization policy isn't working
>> when package has multiple SLOTs, because
>> the bugs are filed for only latest SLOT, where as some packages require
>> stabilization in sync at both SLOTs
>>
>> Option 1:
>>
>> Either revert the whole policy, and never CC arches on unanswered bugs
>> when the package has a maintainer,
>> and let him do it when he finds the time himself, and if that doesn't
>> happen, wait until it's dropped to maintainer-needed@
>>
>> Option 2:
>>
>> Or, the person who is CCing the arches in 30 days timeout, needs to make
>> sure the bug covers all SLOT at the same time
>>
>>
>> The status quo no longer allows me to maintain stable version of
>> dev-libs/girara, app-text/zathura*, and the issue needs
>> to be addressed, see http://bugs.gentoo.org/502714 for what inspired
>> this mail
>>
>> - Samuli
>>
> If you want to prevent packages from being "timed out", just leave a

That would require me to take action on the STABLEREQ, which I don't
want to do
if I see someone requesting it stable only because it's newer version,
see below:

> comment on the bug saying so. If you don't even have time to do that
> within a 30 day window, why are you the maintainer?

It's like we handle stabilization for Xfce, we collect enough xfce-base/
and xfce-extra/
packages together to form a longer list, to avoid bothering arch teams
unnecessarily
constantly
This time it's app-text/zathura-meta and it's dependencies, multiple
packages, we'd
like to wait there are enough plugins, and form a list

And this time the package even had 3 maintainers, 2 gentoo developers
and one proxy,
in metadata.xml, yet none of us managed to intervene in time to prevent
the SLOT breakage[1]
done by arches without our consent

[1] Stabilizing headers, but not the library, causing the .h not to
match the .so, causing every
reverse dependency of the library to break

>
> Another option would be to add some kind of notation to metadata.xml.
>

That could work

[gentoo-dev] Change or revert the "30 days maintainer timeout" stabilization policy

[Samuli Suominen]

The "30 days maintainer time out" stabilization policy isn't working
when package has multiple SLOTs, because
the bugs are filed for only latest SLOT, where as some packages require
stabilization in sync at both SLOTs

Option 1:

Either revert the whole policy, and never CC arches on unanswered bugs
when the package has a maintainer,
and let him do it when he finds the time himself, and if that doesn't
happen, wait until it's dropped to maintainer-needed@

Option 2:

Or, the person who is CCing the arches in 30 days timeout, needs to make
sure the bug covers all SLOT at the same time


The status quo no longer allows me to maintain stable version of
dev-libs/girara, app-text/zathura*, and the issue needs
to be addressed, see http://bugs.gentoo.org/502714 for what inspired
this mail

- Samuli

Re: [gentoo-dev] Solving OpenCL /dev/dri/card* sandbox issues w/ ImageMagick

[Samuli Suominen]

On 02/04/14 16:01, Mike Frysinger wrote:
> On Wed 02 Apr 2014 13:01:25 Samuli Suominen wrote:
>> Problem 1:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=472766#c21
>>
>> I'm not sure if wildcards are supported by /etc/sandbox.d/ files
> they are not.  however, path matching is based on prefixes, so there's always 
> an implicit glob at the end.  would be reasonable to change the code to use 
> fnmatch.
>
> e.g. SANDBOX_PREDICT=/dev/dri/card probably works

I hope SANDBOX_PREDICT="/dev/dri/card" with "" is OK too?

>
> however, i think we're relying on sandbox preventing bad code from doing bad 
> things.  there really should be a way for the build to disable the logic in 
> the first place from kicking in.
> -mike

You are right
I believe this started after a major mesa version bump, so I'd start
looking for the culprit
in Mesa's OpenCL code, but I have no idea howto go futher with the
debugging... yet

Meanwhile, =media-gfx/imagemagick-6.8.8.10[opencl] now installs the
sandbox.d file,
workaround is better here than nothing since this is affecting multiple
binaries,
packages :/

- Samuli

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Samuli Suominen]

On 02/04/14 13:45, Andreas K. Huettel wrote:
> Am Mittwoch, 2. April 2014, 10:29:28 schrieb Samuli Suominen:
>> On 02/04/14 11:28, Tom Wijsman wrote:
>>> On Wed, 02 Apr 2014 09:00:19 +0300
>>>
>>> Samuli Suominen  wrote:
>>>> On 02/04/14 05:02, Matt Turner wrote:
>>>>> You don't seem to understand what Samuli is saying. QA is being used
>>>>> as an offensive weapon. It's a stick to bludgeon others with.
>>>> Exactly. Anyone remembers what happened the last time this was tried?
>>>>
>>>> [...]
>>> What does the previous QA team's actions have to do with this topic?
>> It's the previous QA team's actions and mistakes we can learn from.
>> You know, to avoid repeating them.
>>
> Correct me if I'm wrong, but weren't you one of these QA team members, Samuli?
>

Yes, the situation was different in a sense that QA members themself
disagreed back then,
which lead to the back then lead removing members (not only me) without
even notifying them
from the membership list.
So, I have pretty good insight how bad things could go...

- Samuli

[gentoo-dev] Solving OpenCL /dev/dri/card* sandbox issues w/ ImageMagick

[Samuli Suominen]

Problem 1:

https://bugs.gentoo.org/show_bug.cgi?id=472766#c21

I'm not sure if wildcards are supported by /etc/sandbox.d/ files

Problem 2:

I don't know if this bug is ImageMagick+OpenCL _or_ OpenCL alone
specific since emacs
is having similar issues? Assistance required from emacs maintainer to
figure out.

https://bugs.gentoo.org/show_bug.cgi?id=482976#c11

I can propably find out Problem 2 myself, but Problem 1 is harder since
I can't actually test
the solution to the bug as I don't have OpenCL hardware or
/dev/dri/card* for that matter

Thanks,
Samuli
**