Re: [gentoo-dev] [RFC] =udev-217 or =eudev-2.1 upgrade news item
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
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
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
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
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?
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)
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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.
Besides, people should migrate to something with active upstream, like plymouth
Re: [gentoo-dev] don't rely on dynamic deps
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
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
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
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
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
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
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)
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)
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() ?
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
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
'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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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?
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?
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?
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?
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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