Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
On Wed, Jul 24, 2013 at 8:50 PM, "Paweł Hajdan, Jr." wrote: > On 7/24/13 5:53 PM, Rick "Zero_Chaos" Farina wrote: >> On 07/24/2013 03:18 PM, Ciaran McCreesh wrote: >>> On Wed, 24 Jul 2013 21:17:26 +0200 >>> Michał Górny wrote: Other thing is that Portage explicitly ignores PMS in this matter and uses dependencies from ebuilds rather than recorded ones. This is supposedly wrong, supposedly slow but allows us to be lazy. >> >>> It's not slow. It's just wrong, and intermittently leads to very >>> strange behaviour. >> >> ++ > > Shall we revisit that, and try to make portage behave more correctly, > even if it means more revbumps / rebuilding? Just set EMERGE_DEFAULT_DEPS="--dynamic-deps=n" in make.conf if you'd like to test it.
Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
On 7/24/13 5:53 PM, Rick "Zero_Chaos" Farina wrote: > On 07/24/2013 03:18 PM, Ciaran McCreesh wrote: >> On Wed, 24 Jul 2013 21:17:26 +0200 >> Michał Górny wrote: >>> Other thing is that Portage explicitly ignores PMS in this matter >>> and uses dependencies from ebuilds rather than recorded ones. This is >>> supposedly wrong, supposedly slow but allows us to be lazy. > >> It's not slow. It's just wrong, and intermittently leads to very >> strange behaviour. > > ++ Shall we revisit that, and try to make portage behave more correctly, even if it means more revbumps / rebuilding? Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, Jul 24, 2013 at 7:09 PM, Greg KH wrote: > On Wed, Jul 24, 2013 at 04:40:38PM -0400, Rich Freeman wrote: >> It just seems like we should be able to get by without a semiweekly >> kernel upgrade on our "stable" branch. > > You want me to slow down and do releases in larger chunks then? Hah, > not a chance... > To clarify - I wasn't criticizing your release schedule or making all those builds available in ~arch. I was only concerned with the idea of making all those hit stable. I think the kernel team (including yourself) have been doing a great job with the stable kernels in general. Just one other note - stable packages in general don't just benefit from arch testing. They also benefit from users running ~arch and reporting issues. Stable ebuilds are ones that have generally been used by many others for about a month already, so issues are likely to have been caught. I do agree with all that has been said about there being a tradeoff between new regressions and new fixes. Unless we run year-old kernels with tons of backports we're going to have that problem. We aren't RHEL. Rich
Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/24/2013 03:18 PM, Ciaran McCreesh wrote: > On Wed, 24 Jul 2013 21:17:26 +0200 > Michał Górny wrote: >> Other thing is that Portage explicitly ignores PMS in this matter >> and uses dependencies from ebuilds rather than recorded ones. This is >> supposedly wrong, supposedly slow but allows us to be lazy. > > It's not slow. It's just wrong, and intermittently leads to very > strange behaviour. > ++ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR8HcOAAoJEKXdFCfdEflKsT4P/iU2JsDexTxUZ2IJzfTmXG80 1j1RL8fnisQ9Jq83xHE45yUpQzMYbvWqSCayu56WRzmwYmGQgRvysCg749HI3KVV lWRxrY28psGoXplwJf0VKUhBTXo6sp6Yb9Xnhgd2nHg5aPTb9SFYpfg8wnreUXuo OnQ7/EVN+9ZwVqWABRPIrSX9k1byexKRz1JdkNyWyuTDwwQw6GUHIjWet5uvy0tC Wd8NZ8Ow5JA3HB5rfolTdl4fYTKCLMqwVkqOTOr37lBSx4gzu8w9hPAy5SenWcMl wbbB8uKktdcSUE46UHPuxM21D+mYjMP+YzU2MecZVe5pUoHaCvmVBCpDrXf68/Jt wRbZRn5F3I8WJUQe82xR1VRjmwbmMx+mqvdJlQO3VSEF7EcXZiYKt6EyLfz869e+ 57EvlwktW1yh/x4WIJeYfU+KJHKDLMJCbUxn4mmcZBowY0Qiif8vzGhT4r5kdDqo 1ewLImqvgE5o7zzNiPFx2M43ikbWwnU4KCm4nTi5rYdB5+y4D2FzXZyCz/UBGmYZ JvuRteriNwUcF2rW8Mzw2+SP2wxcxyC/8CbJOC2Df8qj/XOWkY9N/0u6Mrj4NmXs OD1Ner2fXfed2xybbC8QIuRQlduspBR+lHU08AYbWH46Q3tbhS7HPdcGF6IO3EPb Dnb8zJNZK5cXe0FanC3a =wstY -END PGP SIGNATURE-
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, Jul 24, 2013 at 04:40:38PM -0400, Rich Freeman wrote: > Also, not all fixes are equal. The ones that are the biggest concern > are security fixes. How do you _know_ which fixes are security fixes? > If you tell me that the kernel has a new exploit > 2x/week then I'll start to wonder when the kernel team started > outsourcing to MS. Most fixes provide no benefit to most users. > Upgrading kernels on Gentoo is not automatic either, especially if you > have an initramfs, complex configuration, modules in outside packages > (nvidia, virtualization, etc), and so on. I'm releasing, on the average, 3 new kernel versions a week, with 100+ patches in them (for different branches.) Sometimes more. Please tell me exactly how you are going to evaluate which fixes I make are security fixes, and you know which to pick and choose from. Trust me, it's a hard problem, people have tried it in the past, and failed horribly :) > It just seems like we should be able to get by without a semiweekly > kernel upgrade on our "stable" branch. You want me to slow down and do releases in larger chunks then? Hah, not a chance... good luck, greg k-h
Re: [gentoo-dev] Vanilla sources stabilization policy change
On 24 July 2013 21:59, Tom Wijsman wrote: > On Wed, 24 Jul 2013 20:16:59 +0200 > Peter Stuge wrote: > >> Alex Xu wrote: >> > >>> Maybe it would make sense to automatically stabilize every v-s >> > >>> kernel right away? >> > >> >> > >> As has been stated, this implies that Gentoo QA has tested the >> > >> packages and found them to be reasonably safe for use. >> > > .. >> > >> Although stable kernels *have* been tested by many people before >> > >> use, Gentoo QA has *not* (officially) tested them, at least not >> > >> on every architecture. >> > > >> > > I don't think that matters. >> > >> > If you don't care too much for Gentoo QA >> >> The point is that when arch teams find that they can not keep up with >> the pace of upstream and choose never to attempt stabilize v-s then >> clearly Gentoo QA will also not be able to keep up with that pace and >> thus Gentoo QA becomes irrelevant for the particular package. > > No, stabilization of vanilla-sources would be an addition in work > required; one can not assume that if gentoo-sources is stable than > vanilla-sources is or vice versa. Also, the premise here is that > vanilla-sources would need to be stabilized every version; and not just > once per branch (we would like two or three though) as gentoo-sources. > >> The original post also mentioned that generally v-s has more fixes >> than anything coming from stabilization efforts. > > More fixes; but also more regressions, new features, more 0-days, ... > >> It seems that for this package Gentoo QA can not realistically add >> any value to this package, hence my suggestion not to pretend that >> they can, and just remove the distinction between ~arch and arch for >> v-s, and make the latest version available to users by default. > > That's a contradiction; their added value is it being deemed stable, > they can't just pretend it is stable, that overrides the distinction. > > For as far that I know there is nowhere in the tree we provide matters > that walk past Gentoo; so, why should they make an exception here? > >> > >> On a technical level, it's not that hard to put >> > >> "sys-kernel/vanilla-sources" in your package.accept_keywords. >> > > >> > > But why should Gentoo users have to do that in order to use v-s? >> > >> > So they acknowledge that vanilla-sources has not been officially >> > tested by Gentoo QA. >> >> Since v-s is a special case that Gentoo QA is known not to handle, >> this overhead seems completely unneccessary to me. And the usability >> is of course poor. > > If Gentoo QA can't handle it, why could our users; if they are to make > a poor sense of stability, that suffices to make it an explicit choice. > >> > > If it is intentional to push g-s onto users then it makes good >> > > sense >> .. >> > I can't comment on that. >> >> I guess this is really the pivotal point. If Gentoo prefers to push >> g-s rather than v-s then adding overhead for v-s kernels is fine. I'd >> prefer Gentoo to push v-s instead. > > If this weren't intentional, we wouldn't be doing this; the kernel team > exists to add value and not just to blindly follow upstream. > > Let me quote the project description: > > "With an ever increasing userbase demanding a higher quality of stable, > production-ready kernel sources and featureful desktop support the > professionalism and staffing of the kernel project is very important. > > Because we as users want the best from Gentoo Linux we supply a > selection of both generic and specialised sources capable of handling > the day-to-day grind to make life a little easier. > > In order to provide a rich choice of high quality kernel trees Gentoo > Linux must apply, write and test several kernel patches to the official > upstream releases before they can offer finished ebuilds to the users. > This is where the Gentoo Kernel project comes into play." > > -- > 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 This thread derailed as usual. The kernel team made a decision. We can simply accept it and move on. Stable keywords imply at least a minimal build and runtime testing by arch teams. Since we have no manpower to do it, then stabilizing them blindly is not appropriate. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, 24 Jul 2013 20:16:59 +0200 Peter Stuge wrote: > Alex Xu wrote: > > >>> Maybe it would make sense to automatically stabilize every v-s > > >>> kernel right away? > > >> > > >> As has been stated, this implies that Gentoo QA has tested the > > >> packages and found them to be reasonably safe for use. > > > .. > > >> Although stable kernels *have* been tested by many people before > > >> use, Gentoo QA has *not* (officially) tested them, at least not > > >> on every architecture. > > > > > > I don't think that matters. > > > > If you don't care too much for Gentoo QA > > The point is that when arch teams find that they can not keep up with > the pace of upstream and choose never to attempt stabilize v-s then > clearly Gentoo QA will also not be able to keep up with that pace and > thus Gentoo QA becomes irrelevant for the particular package. No, stabilization of vanilla-sources would be an addition in work required; one can not assume that if gentoo-sources is stable than vanilla-sources is or vice versa. Also, the premise here is that vanilla-sources would need to be stabilized every version; and not just once per branch (we would like two or three though) as gentoo-sources. > The original post also mentioned that generally v-s has more fixes > than anything coming from stabilization efforts. More fixes; but also more regressions, new features, more 0-days, ... > It seems that for this package Gentoo QA can not realistically add > any value to this package, hence my suggestion not to pretend that > they can, and just remove the distinction between ~arch and arch for > v-s, and make the latest version available to users by default. That's a contradiction; their added value is it being deemed stable, they can't just pretend it is stable, that overrides the distinction. For as far that I know there is nowhere in the tree we provide matters that walk past Gentoo; so, why should they make an exception here? > > >> On a technical level, it's not that hard to put > > >> "sys-kernel/vanilla-sources" in your package.accept_keywords. > > > > > > But why should Gentoo users have to do that in order to use v-s? > > > > So they acknowledge that vanilla-sources has not been officially > > tested by Gentoo QA. > > Since v-s is a special case that Gentoo QA is known not to handle, > this overhead seems completely unneccessary to me. And the usability > is of course poor. If Gentoo QA can't handle it, why could our users; if they are to make a poor sense of stability, that suffices to make it an explicit choice. > > > If it is intentional to push g-s onto users then it makes good > > > sense > .. > > I can't comment on that. > > I guess this is really the pivotal point. If Gentoo prefers to push > g-s rather than v-s then adding overhead for v-s kernels is fine. I'd > prefer Gentoo to push v-s instead. If this weren't intentional, we wouldn't be doing this; the kernel team exists to add value and not just to blindly follow upstream. Let me quote the project description: "With an ever increasing userbase demanding a higher quality of stable, production-ready kernel sources and featureful desktop support the professionalism and staffing of the kernel project is very important. Because we as users want the best from Gentoo Linux we supply a selection of both generic and specialised sources capable of handling the day-to-day grind to make life a little easier. In order to provide a rich choice of high quality kernel trees Gentoo Linux must apply, write and test several kernel patches to the official upstream releases before they can offer finished ebuilds to the users. This is where the Gentoo Kernel project comes into play." -- 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] Vanilla sources stabilization policy change
On Wed, 24 Jul 2013 16:40:38 -0400 Rich Freeman wrote: > Also, not all fixes are equal. The ones that are the biggest concern > are security fixes. Why? Which is worse: a local denial of service attack when every user on your box has sudo access anyway, or a random data corruption bug that can't be triggered manually and is thus not a security issue? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, 24 Jul 2013 21:15:15 +0200 Peter Stuge wrote: > Ben Kohler wrote: > > > I am suggesting that the latest available upstream kernel should > > > perhaps be the default for Gentoo users. > > > > You seem to be ignoring the regressions that often come with new > > kernel releases, the very common breakage caused in stable > > "genkernel all", and other various complications. Unleashing brand > > new kernel.org sources on stable users as soon as they are released > > seems crazy to me. > > I don't know, I think it makes a lot of sense.. > > Users who upgrade their kernels (don't upgrade if you don't want to) > would be able to participate upstream with reports and confirmations. It isn't a necessity to run the latest kernels to be supported, it suffices to test them to see if they fix the situation or not. We look at the fault ourselves, check newer kernels for fixes, bisect and upstream stuff if it is out of our hand; For example with https://bugs.gentoo.org/show_bug.cgi?id=458746#c26 we are contributing to upstream bug https://bugzilla.kernel.org/show_bug.cgi?id=55311#c40 Of course users can do this outside of us; it's up to them, but they should know we're always there to aid them in troubleshooting whereas upstream might not always answer or follow through closely. Just saying, there isn't anything that prohibits them; as long as their version is listed on https://www.kernel.org/ they are fine. > > These releases surely bring more than just "the newest fixes". > > It varies but sure, I think users should inform themselves about the > new version (of any package!) before they actually upgrade it. Some people do, some people don't; it's though to do this for every package and every release, it also requires some basic knowledge of the kernel to understand what is really going in the kernel world. I agree they should inform themselves; also, we should probably also point them at the right resources, maybe http://kernelnewbies.org/ fits better than an incomprehensible git shortlog or changelog. Will look at that in the near future; since some documentation and project pages are moving to the Gentoo Wiki, it makes it more easy and accessible to add useful resources for matters like these. -- 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] Vanilla sources stabilization policy change
On Wed, Jul 24, 2013 at 3:15 PM, Peter Stuge wrote: > Ben Kohler wrote: >> > I am suggesting that the latest available upstream kernel should >> > perhaps be the default for Gentoo users. >> >> You seem to be ignoring the regressions that often come with new kernel >> releases, the very common breakage caused in stable "genkernel all", and >> other various complications. Unleashing brand new kernel.org sources on >> stable users as soon as they are released seems crazy to me. > > I don't know, I think it makes a lot of sense.. > > Users who upgrade their kernels (don't upgrade if you don't want to) > would be able to participate upstream with reports and confirmations. How will users know which kernels they should upgrade to. If the latest is always the greatest then: 1. Why wouldn't users always update 2x/week? 2. Why doesn't every other distro do this? The reality is that there are multiple kernel versions that are getting updates at any time. The latest and greatest is also the one where all the new features are introduced, and likely all the regressions. Fixes are backported to older kernels which are still supported. Stable shouldn't track the latest kernel. At best it should track the latest version of an older kernel series. It need not be an LTS one, but it shouldn't be the current dev branch. Also, not all fixes are equal. The ones that are the biggest concern are security fixes. If you tell me that the kernel has a new exploit 2x/week then I'll start to wonder when the kernel team started outsourcing to MS. Most fixes provide no benefit to most users. Upgrading kernels on Gentoo is not automatic either, especially if you have an initramfs, complex configuration, modules in outside packages (nvidia, virtualization, etc), and so on. It just seems like we should be able to get by without a semiweekly kernel upgrade on our "stable" branch. Rich
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, 24 Jul 2013 21:01:30 +0200 Peter Stuge wrote: > I am suggesting that the latest available upstream kernel should > perhaps be the default for Gentoo users. See my previous e-mail; if you're willing to go through with this suggestion, then please back that up with sufficient reasoning. That is, state what is bad with gentoo-sources and state the advantages that would come with vanilla-sources; but don't forget to document the disadvantages as well, since there is no magic silver bullet here. Would you upgrade more than hundreds to thousands of servers to 3.10.0? Take a look at the whole picture; for example, Nouveau worked great in late 3.6 and regressed over a lot of people in early 3.7, so they had to wait for fixes to land in late 3.7 again. Another example? Here: https://bugs.gentoo.org/show_bug.cgi?id=468078#c0 And there thousands of bugs to find on all the bug trackers out there that share this kind of nature; so, this is why you can't simple mark what upstream deems stable, but rather what our QA process deems stable. Changing that QA process doesn't happen from one day onto the other; it has to be carefully thought out, documented, planned and announced. If not, it could affect Gentoo's image. -- 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] Vanilla sources stabilization policy change
On Wed, 24 Jul 2013 19:54:10 +0200 Peter Stuge wrote: > Rich Freeman wrote: > > > As has been stated, this implies that Gentoo QA has tested the > > > packages and found them to be reasonably safe for use. > > > > ++ > > While good in theory, it seems that newer v-s are actually more > "reasonably safe" than any g-s. Depends; a version like 3.10.0 could introduce 0-days that might not get fixed till 3.10.6, whereas a version like 3.9.11 received many fixes and doesn't have these 0-days yet. Reasonably safe is subjective. But that's just "safe" as in security, there's also "safe" as in stable; versions like 3.10.0 - 3.10.2 come with a lot of rewrites, new features and what not, a collection of stuff that was just written and just passed the release candidate and stable queue. 3.10.0 breaks stuff. Fixes for the introduced bugs will take a few more releases; that 3.10.3 that comes up? A whopping 100+ patches. Compare that to a version like 3.9.11 that has not seen anything new and received lots of fixes. This is why, for gentoo-sources, we pick kernels near the end of a branch; they can be seen as more secure and stable than the latest upstream stable kernel, especially since we backport important security fixes. Like for instance has been seen with 3.7 and similar. Now, you might wonder, why not stabilize 3.10.6 instead of waiting for something like 3.10.12 that could be EOL? Well, while that is certainly something we would like to do, and I have tried in the past; it didn't work out because the stabilization teams are a bit undermanned to keep up with stabilizing kernels this frequently. Don't forget there is hardened-sources, you can see that they also have one kernel per branch; their last stable kernel, awfully sits at 3.9.5. So... Arch teams need more resources; as in man power and machine power. -- 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] Re: revbumping ebuilds after USE dependency changes
On Wed, 24 Jul 2013 13:40:48 -0600 Ryan Hill wrote: > > Actually per PMS you are required to revbump (and therefore require > > upgrade on users' side) whenever you change the deps and don't > > expect to add a new version soon enough. Otherwise your changes > > don't get spread and users end up with never-ending blockers and > > stuff like that. > > > > Other thing is that Portage explicitly ignores PMS in this matter > > and uses dependencies from ebuilds rather than recorded ones. This > > is supposedly wrong, supposedly slow but allows us to be lazy. > > Thank god. That is insane. > > Let's not document that one in the manual. The issue's not as simple as one might initially think, and both ways have their drawbacks. The only drawback of "use dependencies at the time the package was installed" is that developers can't retroactively change dependencies without a revbump. The drawbacks of "use VDB" are: * That ebuilds can be updated without revbumps to have "changed" dependencies. The example that comes up most is pkg_prerm changes to use or stop using a foo-config type app. If a package mangler then uses the "changed" dependencies, it can lead to premature uninstallation of a foo-config that's needed to safely uninstall something. * That it assumes there's a one-to-one correspondence between "installed ebuild" and "installable ebuild". This means that whenever ebuild versions are cleaned up in the tree, suddenly the dependencies of your installed packages change. It gets even trickier when overlays and binaries are involved. * The way Portage does it doesn't work if there are := dependencies. So the tradeoff is between "require more revbumps" or "randomly broken dependency handling", and neither is ideal. Portage currently leans towards the latter, on the grounds that users expect broken dependencies and strange failures every now and again, but hate "wasting time" on "unnecessary" revbumps. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: revbumping ebuilds after USE dependency changes
On Wed, 24 Jul 2013 21:17:26 +0200 Michał Górny wrote: > Dnia 2013-07-24, o godz. 13:23:15 > Ryan Hill napisał(a): > > > On Wed, 24 Jul 2013 08:48:14 -0700 > > ""Paweł Hajdan, Jr."" wrote: > > > > > On 7/24/13 8:31 AM, Alex Alexander wrote: > > > > On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote: > > > >> Actually, Portage normally handles this situation gracefully by using > > > >> the dependencies from the portage tree instead of vdb. However, in the > > > >> case of a slot-operator dep, it always uses vdb. > > > >> > > > >> See bug 477544. > > > >> > > > >> https://bugs.gentoo.org/show_bug.cgi?id=477544 > > > > > > > > Aha, thanks for the bug, missed it. Well, my recommendation is still > > > > valid until portage gets fixed. Glad to know someone's looking into > > > > it though. > > > > > > Can we get that recommendation to the devmanual possibly? > > > > > > I'm still a little bit confused what exactly would warrant such a > > > revision bump, and why. > > > > Revision bumps are necessary when there are changes made to the files that > > are installed by a package. That's it. > > > > When bumping to EAPI 5 it is recommended to do a rev bump so this sub-slot > > business can be recorded in the vdb. > > > > Are there any others that aren't personal opinion? > > > > Course you can do a rev bump for whatever reason you want, but some people > > will frown on it unless you have a good reason. eg. if you revbump a > > stable ebuild for a build fix i will spend some time sighing at my screen. > > Actually per PMS you are required to revbump (and therefore require > upgrade on users' side) whenever you change the deps and don't expect > to add a new version soon enough. Otherwise your changes don't get > spread and users end up with never-ending blockers and stuff like that. > > Other thing is that Portage explicitly ignores PMS in this matter > and uses dependencies from ebuilds rather than recorded ones. This is > supposedly wrong, supposedly slow but allows us to be lazy. Thank god. That is insane. Let's not document that one in the manual. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
On Wed, 24 Jul 2013 21:17:26 +0200 Michał Górny wrote: > Other thing is that Portage explicitly ignores PMS in this matter > and uses dependencies from ebuilds rather than recorded ones. This is > supposedly wrong, supposedly slow but allows us to be lazy. It's not slow. It's just wrong, and intermittently leads to very strange behaviour. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: revbumping ebuilds after USE dependency changes
Dnia 2013-07-24, o godz. 13:23:15 Ryan Hill napisał(a): > On Wed, 24 Jul 2013 08:48:14 -0700 > ""Paweł Hajdan, Jr."" wrote: > > > On 7/24/13 8:31 AM, Alex Alexander wrote: > > > On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote: > > >> Actually, Portage normally handles this situation gracefully by using > > >> the dependencies from the portage tree instead of vdb. However, in the > > >> case of a slot-operator dep, it always uses vdb. > > >> > > >> See bug 477544. > > >> > > >> https://bugs.gentoo.org/show_bug.cgi?id=477544 > > > > > > Aha, thanks for the bug, missed it. Well, my recommendation is still > > > valid until portage gets fixed. Glad to know someone's looking into > > > it though. > > > > Can we get that recommendation to the devmanual possibly? > > > > I'm still a little bit confused what exactly would warrant such a > > revision bump, and why. > > Revision bumps are necessary when there are changes made to the files that are > installed by a package. That's it. > > When bumping to EAPI 5 it is recommended to do a rev bump so this sub-slot > business can be recorded in the vdb. > > Are there any others that aren't personal opinion? > > Course you can do a rev bump for whatever reason you want, but some people > will > frown on it unless you have a good reason. eg. if you revbump a stable ebuild > for a build fix i will spend some time sighing at my screen. Actually per PMS you are required to revbump (and therefore require upgrade on users' side) whenever you change the deps and don't expect to add a new version soon enough. Otherwise your changes don't get spread and users end up with never-ending blockers and stuff like that. Other thing is that Portage explicitly ignores PMS in this matter and uses dependencies from ebuilds rather than recorded ones. This is supposedly wrong, supposedly slow but allows us to be lazy. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
Ben Kohler wrote: > > I am suggesting that the latest available upstream kernel should > > perhaps be the default for Gentoo users. > > You seem to be ignoring the regressions that often come with new kernel > releases, the very common breakage caused in stable "genkernel all", and > other various complications. Unleashing brand new kernel.org sources on > stable users as soon as they are released seems crazy to me. I don't know, I think it makes a lot of sense.. Users who upgrade their kernels (don't upgrade if you don't want to) would be able to participate upstream with reports and confirmations. > These releases surely bring more than just "the newest fixes". It varies but sure, I think users should inform themselves about the new version (of any package!) before they actually upgrade it. //Peter
[gentoo-dev] Re: revbumping ebuilds after USE dependency changes
On Wed, 24 Jul 2013 08:48:14 -0700 ""Paweł Hajdan, Jr."" wrote: > On 7/24/13 8:31 AM, Alex Alexander wrote: > > On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote: > >> Actually, Portage normally handles this situation gracefully by using > >> the dependencies from the portage tree instead of vdb. However, in the > >> case of a slot-operator dep, it always uses vdb. > >> > >> See bug 477544. > >> > >> https://bugs.gentoo.org/show_bug.cgi?id=477544 > > > > Aha, thanks for the bug, missed it. Well, my recommendation is still > > valid until portage gets fixed. Glad to know someone's looking into > > it though. > > Can we get that recommendation to the devmanual possibly? > > I'm still a little bit confused what exactly would warrant such a > revision bump, and why. Revision bumps are necessary when there are changes made to the files that are installed by a package. That's it. When bumping to EAPI 5 it is recommended to do a rev bump so this sub-slot business can be recorded in the vdb. Are there any others that aren't personal opinion? Course you can do a rev bump for whatever reason you want, but some people will frown on it unless you have a good reason. eg. if you revbump a stable ebuild for a build fix i will spend some time sighing at my screen. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, Jul 24, 2013 at 2:01 PM, Peter Stuge wrote: > > > To be clear: I am not suggesting to change the meaning of stable, > I am suggesting that the latest available upstream kernel should > perhaps be the default for Gentoo users. How to make that happen > is less important, the idea to automatically mark v-s stable is > only that, an idea. :) > > > //Peter > > You seem to be ignoring the regressions that often come with new kernel releases, the very common breakage caused in stable "genkernel all", and other various complications. Unleashing brand new kernel.org sources on stable users as soon as they are released seems crazy to me. These releases surely bring more than just "the newest fixes". Going straight to stable is (in my eyes) so far from being a viable option, that "always unstable, allow unstable if you're ok with the risk/benefit tradeoff" seems like the best bet, to me. -Ben
Re: [gentoo-dev] Vanilla sources stabilization policy change
Rich Freeman wrote: > >> Stable should mean something > > > > For users, stable means "older" in practice. Always did, always will. > > Don't change the meaning of stable, however, for those who find it useful. This is a good point, but the original post suggested to me that actually every new release of v-s is preferable over every older one and perhaps even over g-s because there are more fixes. > Defining stable to mean "no testing at all except by the maintainer" > just makes the keyword meaningless I do think it's meaningless, though in a different way than you mean. But back on track: 1. "stable" in Gentoo means "Gentoo QA-approved" and it is the default 2. v-s will never be stable 3. g-s will always be behind v-s, the latter having more fixes It just seems to me that stable isn't a good default for the kernel because of 2 and 3, and as a result users end up having fewer fixes, since g-s is older. > The main distinction between stable and testing is fewer updates. If QA had infinite resources I suppose that wouldn't be the case. I think it's important to stick to the actual definition of stable meaning QA-approved. > If gentoo-sources isn't complying with our GLSA standards I think > that is worth bringing attention (and help) to, but I've yet to > hear that mentioned. Is that somehow implied by the original post, which states that g-s can be expected to always lack the newest fixes in v-s? I realize that this isn't such a simple matter, but I think it's worth consideration. To be clear: I am not suggesting to change the meaning of stable, I am suggesting that the latest available upstream kernel should perhaps be the default for Gentoo users. How to make that happen is less important, the idea to automatically mark v-s stable is only that, an idea. :) //Peter
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
El mié, 24-07-2013 a las 11:34 -0400, Ian Stakenvicius escribió: > On 24/07/13 10:33 AM, Alexandre Rostovtsev wrote: > > > > Runtime warnings would require non-trivial patching of the > > packages in question, so it's not a realistic alternative. > > > > It should be done anyways, though, unless the runtime errors > themselves are obvious enough to understand. > > A News item would be good, too. In fact, perhaps this pkg_postinst() > warning should exist no matter what the end-user is running, just so > they know they can't trivially switch back to sysvinit/openrc?? > A news item will be added for sure before Gnome 3.8 gets stabilized, this was more to be even more sure people know that information
Re: [gentoo-dev] vserver herd is empty
El mié, 24-07-2013 a las 12:44 +0400, Peter Volkov escribió: > В Вс, 21/07/2013 в 10:23 +0200, Pacho Ramos пишет: > > Will remove the herd if nobody joins in a week. > > I talked to hollow and we think it's worth to remove this herd. > > Actually only openvz and vserver packages are in this herd and they are > maintained completely independently for a long time... I'll drop this > herd from metadata.xml in few days. > > -- > Peter. > If you do that, please remember to also update metadata.xml from packages maintained by that herd and reassign bugs Thanks!
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, Jul 24, 2013 at 1:54 PM, Peter Stuge wrote: > Rich Freeman wrote: > >> Stable should mean something > > For users, stable means "older" in practice. Always did, always will. If you don't like stable, then don't run stable. Don't change the meaning of stable, however, for those who find it useful. I've never had a problem with Gentoo stable. If it doesn't work, it should be dropped entirely on the arches that don't keep up (even if that means all of them). Defining stable to mean "no testing at all except by the maintainer" just makes the keyword meaningless - ~arch packages are supposed to be tested by the maintainer already. The main distinction between stable and testing is fewer updates. I'm sure the average person who runs mythtv with versions synced across 3 systems doesn't need every monthly patch set I push out, but once in a while I'll stabilize a keeper, and if somebody wants a particular feature sooner they can do the extra work. If a security update comes out the stable users still get them. If gentoo-sources isn't complying with our GLSA standards I think that is worth bringing attention (and help) to, but I've yet to hear that mentioned. Rich
Re: [gentoo-dev] Vanilla sources stabilization policy change
Alex Xu wrote: > >>> Maybe it would make sense to automatically stabilize every v-s kernel > >>> right away? > >> > >> As has been stated, this implies that Gentoo QA has tested the packages > >> and found them to be reasonably safe for use. > > .. > >> Although stable kernels *have* been tested by many people before use, > >> Gentoo QA has *not* (officially) tested them, at least not on every > >> architecture. > > > > I don't think that matters. > > If you don't care too much for Gentoo QA The point is that when arch teams find that they can not keep up with the pace of upstream and choose never to attempt stabilize v-s then clearly Gentoo QA will also not be able to keep up with that pace and thus Gentoo QA becomes irrelevant for the particular package. There will never be Gentoo QA on v-s. The original post also mentioned that generally v-s has more fixes than anything coming from stabilization efforts. It seems that for this package Gentoo QA can not realistically add any value to this package, hence my suggestion not to pretend that they can, and just remove the distinction between ~arch and arch for v-s, and make the latest version available to users by default. > >> On a technical level, it's not that hard to put > >> "sys-kernel/vanilla-sources" in your package.accept_keywords. > > > > But why should Gentoo users have to do that in order to use v-s? > > So they acknowledge that vanilla-sources has not been officially tested > by Gentoo QA. Since v-s is a special case that Gentoo QA is known not to handle, this overhead seems completely unneccessary to me. And the usability is of course poor. > > If it is intentional to push g-s onto users then it makes good sense .. > I can't comment on that. I guess this is really the pivotal point. If Gentoo prefers to push g-s rather than v-s then adding overhead for v-s kernels is fine. I'd prefer Gentoo to push v-s instead. //Peter pgprinbDx2lyW.pgp Description: PGP signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
On 24/07/13 01:49 PM, Peter Stuge wrote: > Alex Xu wrote: >>> Maybe it would make sense to automatically stabilize every v-s kernel >>> right away? >> >> As has been stated, this implies that Gentoo QA has tested the packages >> and found them to be reasonably safe for use. > .. >> Although stable kernels *have* been tested by many people before use, >> Gentoo QA has *not* (officially) tested them, at least not on every >> architecture. > > I don't think that matters. If you don't care too much for Gentoo QA, then you are free to run global ~arch on your system. It works reasonably well (no sarcasm), and almost always, someone has tested most packages on most architectures. At least it's been tested by the programmer and maintainer. But that's how KEYWORDS have always been used in Gentoo, as far as I know. >> On a technical level, it's not that hard to put >> "sys-kernel/vanilla-sources" in your package.accept_keywords. > > But why should Gentoo users have to do that in order to use v-s? So they acknowledge that vanilla-sources has not been officially tested by Gentoo QA. You are free to do the simple procedure once and trust the kernel community to have done adequate testing. > If it is intentional to push g-s onto users then it makes good sense - > but if I were the sys-kernel team I wouldn't bother with g-s at all > and just make v-s as easily available to users as possible.. I can't comment on that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
Rich Freeman wrote: > > As has been stated, this implies that Gentoo QA has tested the packages > > and found them to be reasonably safe for use. > > ++ While good in theory, it seems that newer v-s are actually more "reasonably safe" than any g-s. > Stable should mean something For users, stable means "older" in practice. Always did, always will. > If gentoo-sources is where our stable efforts will be, then the > keywords should reflect this. We're not getting rid of > vanilla-sources. Ideally distribution efforts to stabilize packages should go upstream instead of staying within the distribution. Sadly not all upstreams are competent enough to handle that. :\ //Peter
Re: [gentoo-dev] revbumping ebuilds after USE dependency changes
On Wed, Jul 24, 2013 at 9:15 AM, Mike Gilbert wrote: > On Wed, Jul 24, 2013 at 8:49 AM, Alex Alexander wrote: >> Hello, >> >> Please revbump an ebuild after changing its USE dependencies. >> >> Using net-p2p/transmission as an example, it used to depend on >> dev-qt/qtgui:4=[dbus] >> however, qtgui lost the dbus useflag, so the dependency was changed to >> dev-qt/qtgui:4=[dbus(+)] >> without revbumping the transmission ebuild. [0] >> >> Portage fails to notice this when resolving dependencies if the package was >> installed prior to the change, resulting in errors like the following: >> (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts >> with dev-qt/qtgui:4/4=[dbus] required by >> (net-p2p/transmission-2.80::gentoo, installed) >> >> which, I imagine, could be very frustrating for a user who doesn't mess >> with the internals of Gentoo often. >> >> You might think that such a revbump is overkill, but in reality the user will >> have to re-emerge the package anyway in order to get rid of the error, so >> there >> is no point in avoiding it, unless portage changes the way it handles these >> changes. >> >> [0] >> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2 >> > > Actually, Portage normally handles this situation gracefully by using > the dependencies from the portage tree instead of vdb. However, in the > case of a slot-operator dep, it always uses vdb. > > See bug 477544. > > https://bugs.gentoo.org/show_bug.cgi?id=477544 > Moreover, a slot operator dep on Qt libraries is pointless. Please remove the '='. Thanks, Davide
Re: [gentoo-dev] Vanilla sources stabilization policy change
Alex Xu wrote: > > Maybe it would make sense to automatically stabilize every v-s kernel > > right away? > > As has been stated, this implies that Gentoo QA has tested the packages > and found them to be reasonably safe for use. .. > Although stable kernels *have* been tested by many people before use, > Gentoo QA has *not* (officially) tested them, at least not on every > architecture. I don't think that matters. > On a technical level, it's not that hard to put > "sys-kernel/vanilla-sources" in your package.accept_keywords. But why should Gentoo users have to do that in order to use v-s? If it is intentional to push g-s onto users then it makes good sense - but if I were the sys-kernel team I wouldn't bother with g-s at all and just make v-s as easily available to users as possible.. //Peter pgpdBl65QVL_k.pgp Description: PGP signature
Re: [gentoo-dev] Vanilla sources stabilization policy change
Mike Pagano wrote: > Team members working alongside upstream (and downstream) developer Greg k-h > have decided to no longer request stabilization of the vanilla sources > kernel. > Team members and arch teams (understandably) are unable to keep up with the > 1-2 weekly kernel releases, and therefore will now direct users to always run > the latest vanilla sources Maybe it would make sense to automatically stabilize every v-s kernel right away? //Peter
Re: [gentoo-dev] Vanilla sources stabilization policy change
On Wed, Jul 24, 2013 at 1:43 PM, Alex Xu wrote: > As has been stated, this implies that Gentoo QA has tested the packages > and found them to be reasonably safe for use. ++ Stable should mean something, and those who understand the tradeoffs can accept unstable packages where needed (far more easily than on most other distros I might add). If gentoo-sources is where our stable efforts will be, then the keywords should reflect this. We're not getting rid of vanilla-sources. Rich
Re: [gentoo-dev] Vanilla sources stabilization policy change
On 24/07/13 01:37 PM, Peter Stuge wrote: > Mike Pagano wrote: >> Team members working alongside upstream (and downstream) developer Greg k-h >> have decided to no longer request stabilization of the vanilla sources >> kernel. >> Team members and arch teams (understandably) are unable to keep up with the >> 1-2 weekly kernel releases, and therefore will now direct users to always >> run >> the latest vanilla sources > > Maybe it would make sense to automatically stabilize every v-s kernel > right away? > > > //Peter > As has been stated, this implies that Gentoo QA has tested the packages and found them to be reasonably safe for use. Although stable kernels *have* been tested by many people before use, Gentoo QA has *not* (officially) tested them, at least not on every architecture. On a technical level, it's not that hard to put "sys-kernel/vanilla-sources" in your package.accept_keywords. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
Dnia 2013-07-24, o godz. 16:17:47 Ulrich Mueller napisał(a): > > On Wed, 24 Jul 2013, Michał Górny wrote: > > > Pacho requested that to be able to warn users in GNOME packages that > > do not work anymore without systemd. > > Why is the host where the package is built required to run systemd? > Wouldn't a warning at runtime better suit the purpose? Warning at pkg_postinst() for non-pure-package build seems best. A warning at meantime seems not meaningful. It would just be a small warning compared to the big runtime problem that package does not work anymore. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] revbumping ebuilds after USE dependency changes
On 7/24/13 8:31 AM, Alex Alexander wrote: > On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote: >> Actually, Portage normally handles this situation gracefully by using >> the dependencies from the portage tree instead of vdb. However, in the >> case of a slot-operator dep, it always uses vdb. >> >> See bug 477544. >> >> https://bugs.gentoo.org/show_bug.cgi?id=477544 > > Aha, thanks for the bug, missed it. Well, my recommendation is still > valid until portage gets fixed. Glad to know someone's looking into > it though. Can we get that recommendation to the devmanual possibly? I'm still a little bit confused what exactly would warrant such a revision bump, and why. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/07/13 10:33 AM, Alexandre Rostovtsev wrote: > > Runtime warnings would require non-trivial patching of the > packages in question, so it's not a realistic alternative. > It should be done anyways, though, unless the runtime errors themselves are obvious enough to understand. A News item would be good, too. In fact, perhaps this pkg_postinst() warning should exist no matter what the end-user is running, just so they know they can't trivially switch back to sysvinit/openrc?? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlHv8/YACgkQ2ugaI38ACPAFzAD/XfUg1IjWB4dBCCq32rFuy74A +W42E6fXnBdgfTDFA38A/RZfHDjdPDTydt8FBc0IS/+h/22qlbbuPEJypv04VgAa =Imh1 -END PGP SIGNATURE-
Re: [gentoo-dev] revbumping ebuilds after USE dependency changes
On Wed, Jul 24, 2013 at 10:15:51AM -0400, Mike Gilbert wrote: > On Wed, Jul 24, 2013 at 8:49 AM, Alex Alexander wrote: > > Hello, > > > > Please revbump an ebuild after changing its USE dependencies. > > > > Using net-p2p/transmission as an example, it used to depend on > > dev-qt/qtgui:4=[dbus] > > however, qtgui lost the dbus useflag, so the dependency was changed to > > dev-qt/qtgui:4=[dbus(+)] > > without revbumping the transmission ebuild. [0] > > > > Portage fails to notice this when resolving dependencies if the package was > > installed prior to the change, resulting in errors like the following: > > (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts > > with dev-qt/qtgui:4/4=[dbus] required by > > (net-p2p/transmission-2.80::gentoo, installed) > > > > which, I imagine, could be very frustrating for a user who doesn't mess > > with the internals of Gentoo often. > > > > You might think that such a revbump is overkill, but in reality the user > > will > > have to re-emerge the package anyway in order to get rid of the error, so > > there > > is no point in avoiding it, unless portage changes the way it handles these > > changes. > > > > [0] > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2 > > > > Actually, Portage normally handles this situation gracefully by using > the dependencies from the portage tree instead of vdb. However, in the > case of a slot-operator dep, it always uses vdb. > > See bug 477544. > > https://bugs.gentoo.org/show_bug.cgi?id=477544 Aha, thanks for the bug, missed it. Well, my recommendation is still valid until portage gets fixed. Glad to know someone's looking into it though. -- Alex Alexander | wired@gentoo + www.linuxized.com ++ www.leetworks.com signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
On 24/07/13 10:33 AM, Alexandre Rostovtsev wrote: > On Wed, 2013-07-24 at 16:17 +0200, Ulrich Mueller wrote: >>> On Wed, 24 Jul 2013, Michał Górny wrote: >> >>> Pacho requested that to be able to warn users in GNOME packages that >>> do not work anymore without systemd. >> >> Why is the host where the package is built required to run systemd? >> Wouldn't a warning at runtime better suit the purpose? > > The purpose of systemd_is_booted() is to provide helpful postinst > messages to users depending on whether or not they are running systemd, > and for the vast majority of users, the machine where the package is > built is the machine where the package will be run. > > Runtime warnings would require non-trivial patching of the packages in > question, so it's not a realistic alternative. > > Those who have separate build hosts are probably sufficiently > technically proficient to understand if the message does not apply to > their case. > > So it is sufficient to add e.g. ewarn_systemd_is_not_booted() (possibly with a better name) to discourage inappropriate use cases? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
On Wed, 2013-07-24 at 16:17 +0200, Ulrich Mueller wrote: > > On Wed, 24 Jul 2013, Michał Górny wrote: > > > Pacho requested that to be able to warn users in GNOME packages that > > do not work anymore without systemd. > > Why is the host where the package is built required to run systemd? > Wouldn't a warning at runtime better suit the purpose? The purpose of systemd_is_booted() is to provide helpful postinst messages to users depending on whether or not they are running systemd, and for the vast majority of users, the machine where the package is built is the machine where the package will be run. Runtime warnings would require non-trivial patching of the packages in question, so it's not a realistic alternative. Those who have separate build hosts are probably sufficiently technically proficient to understand if the message does not apply to their case.
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/07/13 10:17 AM, Ulrich Mueller wrote: >> On Wed, 24 Jul 2013, Michał Górny wrote: > >> Pacho requested that to be able to warn users in GNOME packages >> that do not work anymore without systemd. > > Why is the host where the package is built required to run > systemd? Wouldn't a warning at runtime better suit the purpose? > > Ulrich > Agreed -- although this function could still have uses, ie, in pkg_postinst to do certain things if systemd is running, no? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlHv4osACgkQ2ugaI38ACPCNeAEAlqSpCrIcH5gdXFwNI4mna9yw VziYKhZrDB+4+8h40SoA/RXkCjLOhnVmVBSZP5zKmu3qih2H7mJcob/7dGkIp5Cw =4Wtp -END PGP SIGNATURE-
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
> On Wed, 24 Jul 2013, Michał Górny wrote: > Pacho requested that to be able to warn users in GNOME packages that > do not work anymore without systemd. Why is the host where the package is built required to run systemd? Wouldn't a warning at runtime better suit the purpose? Ulrich
Re: [gentoo-dev] revbumping ebuilds after USE dependency changes
On Wed, Jul 24, 2013 at 8:49 AM, Alex Alexander wrote: > Hello, > > Please revbump an ebuild after changing its USE dependencies. > > Using net-p2p/transmission as an example, it used to depend on > dev-qt/qtgui:4=[dbus] > however, qtgui lost the dbus useflag, so the dependency was changed to > dev-qt/qtgui:4=[dbus(+)] > without revbumping the transmission ebuild. [0] > > Portage fails to notice this when resolving dependencies if the package was > installed prior to the change, resulting in errors like the following: > (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts > with dev-qt/qtgui:4/4=[dbus] required by > (net-p2p/transmission-2.80::gentoo, installed) > > which, I imagine, could be very frustrating for a user who doesn't mess > with the internals of Gentoo often. > > You might think that such a revbump is overkill, but in reality the user will > have to re-emerge the package anyway in order to get rid of the error, so > there > is no point in avoiding it, unless portage changes the way it handles these > changes. > > [0] > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2 > Actually, Portage normally handles this situation gracefully by using the dependencies from the portage tree instead of vdb. However, in the case of a slot-operator dep, it always uses vdb. See bug 477544. https://bugs.gentoo.org/show_bug.cgi?id=477544
[gentoo-dev] Vanilla sources stabilization policy change
tl;dr Summary Team members working alongside upstream (and downstream) developer Greg k-h have decided to no longer request stabilization of the vanilla sources kernel. Team members and arch teams (understandably) are unable to keep up with the 1-2 weekly kernel releases, and therefore will now direct users to always run the latest vanilla sources, or to run gentoo-sources for a fully Gentoo supported kernel. We will continue to do our best effort to request and get stabililzed g-s versions. Details Some facts: 1. Upstream release rate is now a much higher 1-2 kernels a week. 2. Very frequently, these releases contain security fixes. 3. This rate of release puts arch teams in a difficult position, since it is unsustainable to try to keep up to date with stabilization 4. By continuing the policy of providing a stable vanilla kernel version, Gentoo is giving a false sense of security to its users, since by the time the kernel does get stabilized, a newer version with more security fixes is almost always already released Eventually, we will be updating our project pages to reflect these changes. As always with me, constructive dialog concerning this policy is welcome. Original thread of discussion: http://thread.gmane.org/gmane.linux.gentoo.kernel/697 -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3&op=index
[gentoo-dev] revbumping ebuilds after USE dependency changes
Hello, Please revbump an ebuild after changing its USE dependencies. Using net-p2p/transmission as an example, it used to depend on dev-qt/qtgui:4=[dbus] however, qtgui lost the dbus useflag, so the dependency was changed to dev-qt/qtgui:4=[dbus(+)] without revbumping the transmission ebuild. [0] Portage fails to notice this when resolving dependencies if the package was installed prior to the change, resulting in errors like the following: (dev-qt/qtgui-4.8.5::gentoo, ebuild scheduled for merge) conflicts with dev-qt/qtgui:4/4=[dbus] required by (net-p2p/transmission-2.80::gentoo, installed) which, I imagine, could be very frustrating for a user who doesn't mess with the internals of Gentoo often. You might think that such a revbump is overkill, but in reality the user will have to re-emerge the package anyway in order to get rid of the error, so there is no point in avoiding it, unless portage changes the way it handles these changes. [0] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-p2p/transmission/transmission-2.80.ebuild?r1=1.1&r2=1.2 Thanks, -- Alex Alexander | wired@gentoo + www.linuxized.com ++ www.leetworks.com signature.asc Description: Digital signature
Re: [gentoo-dev] vserver herd is empty
В Вс, 21/07/2013 в 10:23 +0200, Pacho Ramos пишет: > Will remove the herd if nobody joins in a week. I talked to hollow and we think it's worth to remove this herd. Actually only openvz and vserver packages are in this herd and they are maintained completely independently for a long time... I'll drop this herd from metadata.xml in few days. -- Peter.
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
Dnia 2013-07-24, o godz. 11:36:12
Sergei Trofimovich napisał(a):
> On Wed, 24 Jul 2013 09:18:13 +0200
> Michał Górny wrote:
>
>
> > +# @FUNCTION: systemd_is_booted
> > +systemd_update_catalog() {
>
> Looks like a typo :]
Thanks for noticing. Does anyone else feel that eclassdoc is utterly
irritating and encourages that kind of mistakes?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
On Wed, 24 Jul 2013 09:18:13 +0200
Michał Górny wrote:
> +# @FUNCTION: systemd_is_booted
> +systemd_update_catalog() {
Looks like a typo :]
--
Sergei
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
On Wed, 24 Jul 2013 09:18:13 +0200 Michał Górny wrote: > Pacho requested that to be able to warn users in GNOME packages that > do not work anymore without systemd. > > +# @FUNCTION: systemd_is_booted > +# @DESCRIPTION: > +# Check whether the system was booted using systemd. Can we have a short mention of that kind of usage in the description? There is some set of possible wrong usages, some of which are nasty, that this function should not be used for; for example, someone could use this as a check to install a file which I believe isn't permitted. Are there even other legit usages your original function would permit? Alternatively, you could change the function altogether into something more specific; eg. ewarn_systemd_boot and ewarn_no_systemd_boot. These functions would then take a message as parameter; then the resulting behavior of this function is in your hands, not the consumer. -- 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
[gentoo-dev] [PATCH systemd.eclass] Introduce systemd_is_booted().
Pacho requested that to be able to warn users in GNOME packages that do
not work anymore without systemd.
---
gx86/eclass/systemd.eclass | 17 +
1 file changed, 17 insertions(+)
diff --git a/gx86/eclass/systemd.eclass b/gx86/eclass/systemd.eclass
index 166c7be..a2750d7 100644
--- a/gx86/eclass/systemd.eclass
+++ b/gx86/eclass/systemd.eclass
@@ -252,3 +252,20 @@ systemd_update_catalog() {
debug-print "${FUNCNAME}: journalctl not found."
fi
}
+
+# @FUNCTION: systemd_is_booted
+# @DESCRIPTION:
+# Check whether the system was booted using systemd.
+#
+# Returns 0 if systemd is used to boot the system, 1 otherwise.
+#
+# See: man sd_booted
+systemd_update_catalog() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ [[ -d /run/systemd/system ]]
+ local ret=${?}
+
+ debug-print "${FUNCNAME}: [[ -d /run/systemd/system ]] -> ${ret}"
+ return ${ret}
+}
--
1.8.3.2
