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] RFC: Removing src_test from www-client/chromium
On 5/29/14, 12:46 PM, Tom Wijsman wrote: In general it has always worked well after a compile; but, there's every now and then one or another annoying regression, like recent Chromium had some font issues or some random tabs crash some versions ago and ... If a test catches one of these, you can immediately report the problem; if it is left untested, you'll have to do a debugging adventure instead. This is one of my points: I don't remember a single chromium bug filed in Gentoo that would be caught by a test or that a failing test actually detected. By the way, I don't remember seeing many reports about font issues or tab crashes. Please make sure to file them when they occur, or just point me to them in case I somehow missed them. While I don't run tests myself; the need for them is clear, for those that aim for more production ready systems (eg. university network PCs). This seems too theoretical to me. I'd be fine with someone volunteering to maintain chromium's src_test in Gentoo. Unless we have such a person though, it seems to mostly take valuable focus away from bugs that definitely *do* affect our users, for no provable benefit for Gentoo. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Removing src_test from www-client/chromium
On Sat, 31 May 2014 19:50:20 +0200 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: On 5/29/14, 12:46 PM, Tom Wijsman wrote: In general it has always worked well after a compile; but, there's every now and then one or another annoying regression, like recent Chromium had some font issues or some random tabs crash some versions ago and ... If a test catches one of these, you can immediately report the problem; if it is left untested, you'll have to do a debugging adventure instead. This is one of my points: I don't remember a single chromium bug filed in Gentoo that would be caught by a test or that a failing test actually detected. Your point covers the lack of tests, or tests that are non-fatal; however, it doesn't cover tests that are fatal, what if they fail? By the way, I don't remember seeing many reports about font issues or tab crashes. Please make sure to file them when they occur, or just point me to them in case I somehow missed them. They usually go straight to upstream, though I've managed to somehow fix it up; as for Gentoo, some people create forum threads about them. (One was due to a library compiled with a less common flag, the other due to fontconfig being a regression magnet; both fun to debug, the former a test wolud've caught, the latter is due to the lack thereof) While I don't run tests myself; the need for them is clear, for those that aim for more production ready systems (eg. university network PCs). This seems too theoretical to me. I'd be fine with someone volunteering to maintain chromium's src_test in Gentoo. Unless we have such a person though, it seems to mostly take valuable focus away from bugs that definitely *do* affect our users, for no provable benefit for Gentoo. What about provable benefit for upstream? Does upstream /dev/null them? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
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). -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
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 May 31, 2014 8:42 PM, Robin H. Johnson robb...@gentoo.org 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. It would be better if those would be put in individual source pkgs in a way that they can be picked up by genkernel. Kernel config belongs to kernel pkgs, pretty much like init scripts or config files belong to their own project pkgs. 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). -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
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 . -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Sat, May 31, 2014 at 08:51:39PM +0100, Fabio Erculiani wrote: On May 31, 2014 8:42 PM, Robin H. Johnson robb...@gentoo.org 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. It would be better if those would be put in individual source pkgs in a way that they can be picked up by genkernel. Kernel config belongs to kernel pkgs, pretty much like init scripts or config files belong to their own project pkgs. No, I don't agree that kernel configs belong to kernel packages. In general, barring the crazy option explosion, these are meant to be stock working configs that should in combination with ANY kernel package, produce a working kernel. As for the rest of the 'kernel seeds' stuff; it never made it properly into the tree, and because of that, didn't get much traction. Infra has recently put together their own ebuild-that-runs-genkernel setup, so we could roll out kernels more consistently, and if I can solve one bug [1], I'm strongly considering putting that functionality into an eclass, and giving ALL sys-kernel/*sources the ability to spit out a built kernel with genkernel, for the price of an emerge. [1] Taking binaries from the host system can lead to problems if you want the initramfs to work reliably everywhere. glibc compiled with SSE4.2 bit infra, because libm got linked into stuff being built with -march=generic. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
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?
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Sat, May 31, 2014 at 9:06 PM, Robin H. Johnson robb...@gentoo.org wrote: No, I don't agree that kernel configs belong to kernel packages. In general, barring the crazy option explosion, these are meant to be stock working configs that should in combination with ANY kernel package, produce a working kernel. Then you are just moving the problem around. I believe that kernel configs should be provided by their own kernel packages (and there are some, not just gentoo-sources) because it is much easier to keep them in sync on every new release and deal with each version separately if/as needed (including testing!). How are you dealing with config var name changes between different kernel versions or just different pkgs then? You cannot possibly support all kernel versions for all kernel pkgs available in tree with just one single config file in a sane, clean and maintainable way, hoping that a change in this file will not affect previous or future kernel releases. How are you going to test your config changes against old kernel pkgs? Each test is quite expensive to run. Good luck with that :-) [...] -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 -- Fabio Erculiani
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Sat, 31 May 2014 22:42:17 +0100 Fabio Erculiani lx...@gentoo.org wrote: On Sat, May 31, 2014 at 9:06 PM, Robin H. Johnson robb...@gentoo.org wrote: No, I don't agree that kernel configs belong to kernel packages. In general, barring the crazy option explosion, these are meant to be stock working configs that should in combination with ANY kernel package, produce a working kernel. Then you are just moving the problem around. I believe that kernel configs should be provided by their own kernel packages (and there are some, not just gentoo-sources) because it is much easier to keep them in sync on every new release and deal with each version separately if/as needed (including testing!). How are you dealing with config var name changes between different kernel versions or just different pkgs then? Different packages is not a problem; since the difference in terms of config between separate packages is small enough, a dozen of options. Different version may be a problem, a rather small one; nothing prevents one from keeping config options around for both versions. You cannot possibly support all kernel versions for all kernel pkgs available in tree with just one single config file in a sane, clean and maintainable way, hoping that a change in this file will not affect previous or future kernel releases. How are you going to test your config changes against old kernel pkgs? Each test is quite expensive to run. Good luck with that :-) Does it really need to be sane, clean and maintainable for it to work? Yes, maybe; but how sane, clean and maintainable? We can do better... A fork (eg. hardened-sources config, geek-sources config) where needed might still be a way out; however, one should consider to look into a better architecture than plain forks. For example, a config that sources a generic config and adds hardened changes on top of that; kind of like the way GRUB 2's /etc/grub.d/ config generation works. We should introduce this only when needed to avoid to over-design it. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Sat, May 31, 2014 at 11:16:35PM +0300, Samuli Suominen wrote: 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? Bug 511992; amd64 x86 done already. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Anyone with access to genkernel repository? Or should genkernel be p.masked on amd64 profiles?
On Sat, May 31, 2014 at 10:42:17PM +0100, Fabio Erculiani wrote: On Sat, May 31, 2014 at 9:06 PM, Robin H. Johnson robb...@gentoo.org wrote: No, I don't agree that kernel configs belong to kernel packages. In general, barring the crazy option explosion, these are meant to be stock working configs that should in combination with ANY kernel package, produce a working kernel. Then you are just moving the problem around. I believe that kernel configs should be provided by their own kernel packages (and there are some, not just gentoo-sources) because it is much easier to keep them in sync on every new release and deal with each version separately if/as needed (including testing!). How are you dealing with config var name changes between different kernel versions or just different pkgs then? You cannot possibly support all kernel versions for all kernel pkgs available in tree with just one single config file in a sane, clean and maintainable way, hoping that a change in this file will not affect previous or future kernel releases. How are you going to test your config changes against old kernel pkgs? Each test is quite expensive to run. I never said I was going to support all different kernel sources. genkernel only officially supports gentoo-sources hardened-sources. (and those are supersets of the vanilla tree). The stock genkernel config actually works for most users, on most kernel sources, on most systems; and parts of it date back to 2.6.14. Sure it doesn't turn on all of the features requested, but it does actually work. That said, I do intend to included an official kernel config for each major kernel release 3.x; for both hardened gentoo-sources. Infra uses the hardened one, and releng uses the gentoo-sources one. The only change really is that the packaging is going to be separate from genkernel, and it'll get a bit more care than before. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
