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

2014-11-07 Thread 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 packages no longer/now do
 thing. [thing is description of thing.] if you need thing, do
 steps. if you do not need thing, do steps.

 [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

2014-11-07 Thread 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 packages no longer/now do
 thing. [thing is description of thing.] if you need thing, do
 steps. if you do not need thing, do steps.

 [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



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

2014-10-29 Thread 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 ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2014-10-29
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-fs/udev-217
Display-If-Installed: sys-fs/eudev-2.1

If you need firmware loading support, you need to run at least Linux = 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


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

2014-09-17 Thread 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



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

2014-09-17 Thread Samuli Suominen
I could use some help with bugs at,

http://bugs.gentoo.org/showdependencytree.cgi?id=479818hide_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] Does the scm ebuild masking policy make sense for git?

2014-09-09 Thread 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)



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

2014-08-31 Thread 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.317r2=1.318
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.ebuild?r1=1.318r2=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] udev-9999 (and upcoming 217) no longer has userspace firmware loader (will need Linux 3.7 for firmware's to be loaded)

2014-08-31 Thread 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.317r2=1.318
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/sys-fs/udev/udev-.ebuil
 d?r1=1.318r2=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



Re: [gentoo-dev] The future of dohtml

2014-08-28 Thread 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 mgo...@gentoo.org 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] The future of dohtml

2014-08-28 Thread Samuli Suominen

On 28/08/14 18:58, Michał Górny wrote:
 Dnia 2014-08-28, o godz. 00:37:48
 Michał Górny mgo...@gentoo.org 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



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

2014-08-21 Thread 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] jpeg-9a in ~arch after half an year in package.mask

2014-08-21 Thread 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



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

2014-08-03 Thread 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

2014-07-30 Thread 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

2014-07-30 Thread Samuli Suominen

On 30/07/14 14:18, Rich Freeman wrote:
 On Wed, Jul 30, 2014 at 3:38 AM, Paweł Hajdan, Jr.
 phajdan...@gentoo.org 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

2014-07-30 Thread 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: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-29 Thread Samuli Suominen

On 29/07/14 03:15, Denis Dupeyron wrote:
 On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org 
 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] Re: don't rely on dynamic deps

2014-07-29 Thread Samuli Suominen

On 30/07/14 07:45, Alexander Tsoy wrote:
 В Sun, 27 Jul 2014 14:42:24 +0300
 Samuli Suominen ssuomi...@gentoo.org пишет:

 On 26/07/14 15:49, Ciaran McCreesh wrote:
 On Sat, 26 Jul 2014 12:41:16 + (UTC)
 Martin Vaeth mar...@mvath.de wrote:
 hasufell hasuf...@gentoo.org 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: don't rely on dynamic deps

2014-07-28 Thread Samuli Suominen

On 27/07/14 16:47, Michał Górny wrote:
 Dnia 2014-07-27, o godz. 14:42:24
 Samuli Suominen ssuomi...@gentoo.org napisał(a):

 On 26/07/14 15:49, Ciaran McCreesh wrote:
 On Sat, 26 Jul 2014 12:41:16 + (UTC)
 Martin Vaeth mar...@mvath.de wrote:
 hasufell hasuf...@gentoo.org 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] 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

2014-07-28 Thread Samuli Suominen

On 27/07/14 14:33, Pacho Ramos wrote:
 # Pacho Ramos pa...@gentoo.org (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)




[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

2014-07-28 Thread 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] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild

2014-07-28 Thread 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.



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

2014-07-28 Thread Samuli Suominen

On 28/07/14 09:38, Samuli Suominen wrote:
 On 27/07/14 14:33, Pacho Ramos wrote:
 # Pacho Ramos pa...@gentoo.org (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: don't rely on dynamic deps

2014-07-27 Thread Samuli Suominen

On 26/07/14 15:49, Ciaran McCreesh wrote:
 On Sat, 26 Jul 2014 12:41:16 + (UTC)
 Martin Vaeth mar...@mvath.de wrote:
 hasufell hasuf...@gentoo.org 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] Re: don't rely on dynamic deps

2014-07-27 Thread 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 mar...@mvath.de wrote:
 hasufell hasuf...@gentoo.org 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] About current ppc/ppc64 status

2014-07-26 Thread 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

2014-07-25 Thread 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=506034hide_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

2014-07-24 Thread 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=506034hide_resolved=1



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

2014-07-22 Thread 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] Re: don't rely on dynamic deps

2014-07-22 Thread Samuli Suominen

On 22/07/14 20:11, Ciaran McCreesh wrote:
 On Tue, 22 Jul 2014 19:03:16 +0200
 Sven Vermeulen sw...@gentoo.org 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] don't rely on dynamic deps

2014-07-22 Thread 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] Automated Package Removal and Addition Tracker, for the week ending 2014-07-20 23h59 UTC

2014-07-21 Thread Samuli Suominen

On 21/07/14 12:30, Tom Wijsman wrote:
 On Mon, 21 Jul 2014 02:35:45 -0500
 Dale rdalek1...@gmail.com wrote:

 Diamond wrote:
 On Mon, 21 Jul 2014 00:25:02 +
 Robin H. Johnson robb...@gentoo.org 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



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

2014-07-21 Thread 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-gfx/splashutils-1.5.4.3-r3: internal copy of vuln.
libpng (CVE-2010-1205) 2013-10-13
307525 Gentoo S Auditing secur...@gentoo.org IN_P   
 --- media-gfx/splashutils-1.5.4.3-r2: statically links to
vulnerable jpeg and freetype 2013-06-16
354157 Gentoo L Core sys asaf.g...@gmail.com CONF   
 --- media-gfx/splashutils-1.5.4.3-r3: does not copy the
initrd.splash into the initrd 2013-06-16
354639 Gentoo L Applicat asaf.g...@gmail.com CONF   
 --- media-gfx/splashutils-1.5.4.3-r3 does not go into verbose mode
with 'nox' boot option 2013-06-16
233267 Gentoo L Unspecif asaf.g...@gmail.com CONF   
 --- media-gfx/splashutils: fsck vs bootsplash 2013-06-16
271835 Gentoo L Applicat asaf.g...@gmail.com CONF   
 --- media-gfx/splashutils: some password prompt would be great for
silent mode 2013-06-16
434368 Gentoo L Unspecif asaf.g...@gmail.com CONF   
 --- media-gfx/splashutils-1.5.4.4-r1: linking to freetype fails due
to missing static library zlib (-lz) 18:49:49
443856 Gentoo L Applicat asaf.g...@gmail.com UNCO   
 --- media-gfx/splashutils-1.5.4.4-r2 failed to build -
asm/posix_types.h: No such file or directory 2014-07-01
473512 Gentoo L Applicat asaf.g...@gmail.com IN_P   
 --- media-gfx/splashutils-1.5.4.4-r2 /usr/bin/i686-pc-linux-gnu-ld:
error in /usr/lib/klibc/lib/libc.so(.eh_frame); no .eh_frame_hdr table
will be created. 2014-02-18
488524 Gentoo L Applicat asaf.g...@gmail.com UNCO   
 --- =media-gfx/splashutils-1.5.4.4-r1 - splash_geninitramfs
--append corrupts initramfs with kernel-3.10.16 2013-10-19
490530 Gentoo L Applicat asaf.g...@gmail.com CONF   
 --- =media-gfx/splashutils-1.5.4.4-r4 needs freetype2 fixed as it
has gained a libpng dependency 2014-04-01
499654 Gentoo L Applicat asaf.g...@gmail.com UNCO   
 --- media-gfx/splashutils-1.5.4.4-r4 with
media-libs/libmng-2.0.2-r1 - .../work/libmng-2.0.2/libmng_cms.c:160:
undefined reference to `cmsFreeToneCurve' 2014-06-17
506124 Gentoo L Applicat asaf.g...@gmail.com CONF   
 --- media-gfx/splashutils[truetype] fails to build with
=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] Enable format-security in the dev profiles

2014-07-21 Thread 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



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

2014-07-21 Thread Samuli Suominen
Besides, people should migrate to something with active upstream, like
plymouth



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

2014-07-21 Thread 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] don't rely on dynamic deps

2014-07-21 Thread Samuli Suominen

On 21/07/14 22:50, Ciaran McCreesh wrote:
 On Mon, 21 Jul 2014 22:42:23 +0300
 Samuli Suominen ssuomi...@gentoo.org 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

2014-07-21 Thread 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
  ssuomi...@gentoo.org 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

2014-07-21 Thread 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

2014-07-21 Thread 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] Enable format-security in the dev profiles

2014-07-20 Thread 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] Prevent to need to change all keywords at the same time

2014-07-18 Thread 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





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

2014-07-18 Thread 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] New global USE flags upower and udisks (split from udev in some cases)

2014-07-18 Thread Samuli Suominen

On 18/07/14 23:58, Georg Rudoy wrote:
 2014-07-19 0:19 GMT+04:00 Samuli Suominen ssuomi...@gentoo.org:
 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)



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

2014-07-15 Thread 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] The request to abolish games team policy

2014-07-15 Thread 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] The request to abolish games team policy

2014-07-15 Thread 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] Re: The request to abolish games team policy

2014-07-09 Thread 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

2014-07-09 Thread 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

2014-07-08 Thread Samuli Suominen

On 08/07/14 17:18, Maxim Koltsov wrote:



 2014-07-08 16:10 GMT+04:00 Rich Freeman ri...@gentoo.org
 mailto:ri...@gentoo.org:

 On Tue, Jul 8, 2014 at 7:38 AM, Michał Górny mgo...@gentoo.org
 mailto:mgo...@gentoo.org 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] Re: The request to abolish games team policy

2014-07-08 Thread 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] Is || ( Atom... ) broken?

2014-07-07 Thread 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

2014-07-01 Thread 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



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

2014-06-22 Thread 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.3view=markup
 plain: 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmfishtime/files/wmfishtime-1.24-gtk.patch?rev=1.3content-type=text/plain
 diff : 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/x11-plugins/wmfishtime/files/wmfishtime-1.24-gtk.patch?r1=1.2r2=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: [gentoo-commits] gentoo-x86 commit in x11-plugins/wmfishtime/files: wmfishtime-1.24-gtk.patch

2014-06-22 Thread Samuli Suominen

On 23/06/14 05:01, Jeroen Roovers wrote:
 On Sun, 22 Jun 2014 20:08:41 +0300
 Samuli Suominen ssuomi...@gentoo.org 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.



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

2014-06-04 Thread 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 alan.mckin...@gmail.com
 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] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore

2014-06-03 Thread 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



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

2014-06-03 Thread Samuli Suominen

On 03/06/14 15:08, Tom Wijsman wrote:
 On Tue, 3 Jun 2014 07:35:42 -0400
 Rich Freeman ri...@gentoo.org 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

2014-06-03 Thread 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 ssuomi...@gentoo.org
   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

2014-06-03 Thread Samuli Suominen

On 03/06/14 16:40, Tom Wijsman wrote:
 On Tue, 03 Jun 2014 16:28:47 +0300
 Samuli Suominen ssuomi...@gentoo.org 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 ssuomi...@gentoo.org
   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

2014-06-03 Thread Samuli Suominen

On 03/06/14 16:53, Rich Freeman wrote:
 On Tue, Jun 3, 2014 at 9:46 AM, Samuli Suominen ssuomi...@gentoo.org 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

2014-06-03 Thread 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




[gentoo-dev] RFC: news item for upower

2014-06-03 Thread 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 ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2014-06-03
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-power/upower-0.99.0

UPower discontinued hibernate and suspend support in favor of systemd.
Because of this, we have created a compability package at
sys-power/upower-pm-utils which will give you the old UPower with
sys-power/pm-utils support back.
Some desktops have integrated the sys-power/pm-utils support directly
to their code, like Xfce, and as a result, they work also with the new
UPower as expected.

All users are recommended to choose between:

# emerge --noreplace 'sys-power/upower-pm-utils'

or

# emerge --noreplace '=sys-power/upower-0.99.0'


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

2014-06-03 Thread 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 ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2014-06-03
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-power/upower-0.99.0

UPower discontinued hibernate and suspend support in favor of systemd.
Because of this, we have created a compability package at
sys-power/upower-pm-utils which will give you the old UPower with
sys-power/pm-utils support back.
Some desktops have integrated the sys-power/pm-utils support directly
to their code, like Xfce, and as a result, they work also with the new
UPower as expected.

All non-systemd users are recommended to choose between:

# emerge --noreplace 'sys-power/upower-pm-utils'

or

# emerge --noreplace '=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

2014-06-03 Thread Samuli Suominen

On 03/06/14 19:26, Tom Wijsman wrote:
 On Tue, 03 Jun 2014 18:53:26 +0300
 Samuli Suominen ssuomi...@gentoo.org 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

2014-06-03 Thread 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 ssuomi...@gentoo.org
Content-Type: text/plain
Posted: 2014-06-03
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-power/upower-0.99.0

UPower discontinued hibernate and suspend support in favor of systemd.
Because of this, we have created a compability package at
sys-power/upower-pm-utils which will give you the old UPower with
sys-power/pm-utils support back.
Some desktops have integrated the sys-power/pm-utils support directly
to their code, like Xfce, and as a result, they work also with the new
UPower as expected.

All non-systemd users are recommended to choose between:

# emerge --oneshot --noreplace 'sys-power/upower-pm-utils'

or

# emerge --oneshot --noreplace '=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

2014-06-03 Thread 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

2014-06-03 Thread 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 alan.mckin...@gmail.com 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 this'

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

2014-06-03 Thread 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



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

2014-06-02 Thread 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



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

2014-06-01 Thread 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] alpha, ia64, ppc, ppc64, sparc developers, need your attention

2014-06-01 Thread 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



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

2014-05-31 Thread 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 ssuomi...@gentoo.org 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?

2014-05-31 Thread 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] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?

2014-05-31 Thread 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?



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

2014-05-30 Thread 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] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?

2014-05-30 Thread Samuli Suominen

On 30/05/14 19:10, Tom Wijsman wrote:
 On Fri, 30 May 2014 18:10:40 +0300
 Samuli Suominen ssuomi...@gentoo.org 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

:(



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

2014-05-30 Thread 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 ssuomi...@gentoo.org 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] UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore

2014-05-27 Thread Samuli Suominen

On 27/05/14 08:34, Michał Górny wrote:
 Dnia 2014-05-26, o godz. 23:15:34
 Samuli Suominen ssuomi...@gentoo.org 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] UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore

2014-05-26 Thread 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 sys-power/upower-pm-utils ) where only
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] Re: UPower upstream (git master) and 0.99 release - No sys-power/pm-utils support anymore

2014-05-26 Thread 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
 || ( sys-power/upower-0.99 sys-power/upower-pm-utils ) where only
 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] Re: [gentoo-commits] gentoo-x86 commit in media-libs/libsdl2/files: libsdl2-2.0.3-static-libs.patch

2014-05-12 Thread 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.1view=markup
 plain: 
 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/media-libs/libsdl2/files/libsdl2-2.0.3-static-libs.patch?rev=1.1content-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] Re: Banning modification of pkg-config files

2014-05-12 Thread 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.)



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

2014-05-12 Thread 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] RFC: using .xz for doc/man/info compression

2014-05-11 Thread 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

2014-05-10 Thread 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 hwoar...@gentoo.org wrote:
 On 05/09/2014 09:32 PM, Tom Wijsman wrote:
 On Fri, 9 May 2014 16:15:58 -0400
 Rich Freeman ri...@gentoo.org 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



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

2014-04-08 Thread 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
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



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

2014-04-08 Thread Samuli Suominen

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


No idea how that happened. I blame Thunderbird.



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

2014-04-08 Thread 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

2014-04-08 Thread 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



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

2014-04-07 Thread 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

2014-04-06 Thread 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
 ssuomi...@gentoo.org 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
automaticstableno/automaticstable 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 herdxfce/herd
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] New virtuals for libudev and libgudev

2014-04-02 Thread Samuli Suominen

On 02/04/14 05:02, Matt Turner wrote:
 On Tue, Apr 1, 2014 at 9:38 AM, Tom Wijsman tom...@gentoo.org 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.

- Samuli



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

2014-04-02 Thread Samuli Suominen

On 02/04/14 11:28, Tom Wijsman wrote:
 On Wed, 02 Apr 2014 09:00:19 +0300
 Samuli Suominen ssuomi...@gentoo.org 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.


 Force is not hardly ever the correct answer. It might work in a
 workplace, but not when people are contributing for free.
 In the workplace; people say no, stand up and leave the room.

That's reality only for small percentage of working people.
The majority will do as they are told, and don't even consider saying
no as that
would risk their job, and thus, salary, and the way you pay your
mortgage, your house,
and feed your family.

- Samuli



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

2014-04-02 Thread 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
** https://bugs.gentoo.org/show_bug.cgi?id=472766



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

2014-04-02 Thread 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 ssuomi...@gentoo.org 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



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

2014-04-02 Thread 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



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

2014-04-02 Thread 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] Change or revert the 30 days maintainer timeout stabilization policy

2014-04-02 Thread Samuli Suominen

On 02/04/14 21:22, Mike Gilbert wrote:
 On Wed, Apr 2, 2014 at 12:52 PM, Samuli Suominen ssuomi...@gentoo.org 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



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

2014-04-02 Thread 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 tom...@gentoo.org 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



  1   2   3   4   5   6   7   8   9   10   >