Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On 06/29/14 17:33, Markos Chandras wrote: > On 06/29/2014 10:23 AM, Patrick Lauer wrote: >> On Sunday 29 June 2014 17:03:52 Patrick Lauer wrote: >>> On Sunday 29 June 2014 10:12:22 Tom Wijsman wrote: On Sun, 29 Jun 2014 09:09:36 +0100 Markos Chandras wrote: > It's been a long time. To be honest I don't remember masking docker > but I most likely did it because I was asked to mask >=lxc-1.0.0 by > the virtualization team (and Diego (flameeyes). And docker depends on > lxc-1.0.0 according to the ebuild. But now that you have unmasked > docker, i think the deptree will be broken since lxc is still masked. Repoman is monitored; therefore, someone from the QA team or so has probably masked Docker. Given that broken dependency tree again it is likely to happen again. So, please set it up a satisfiable state. :) >>> >>> AutoRepoman :) >>> >>> So that was me fixing the depgraph, taking the easy way out of adding an >>> unsatisfiable package to an existing related package.mask. >>> >>> If people can't be bothered to even run repoman full or commit without >>> --force they'll get annoyed by my corrections - maybe it has an educational >>> effect ;) >>> >>> Have fun, >>> >>> Patrick >> >> Tadaah: >> >> dependency.bad22 >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/desktop) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/desktop/gnome) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/desktop/gnome/systemd) ['>=app- >> emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/desktop/kde) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/desktop/kde/systemd) ['>=app- >> emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/developer) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(hardened/linux/amd64) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(hardened/linux/amd64/no-multilib) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(hardened/linux/amd64/no-multilib/selinux) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: >> ~amd64(hardened/linux/amd64/selinux) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/desktop) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/desktop/gnome) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/desktop/gnome/systemd) ['>=app- >> emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/desktop/kde) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/desktop/kde/systemd) ['>=app- >> emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(default/linux/amd64/13.0/developer) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(hardened/linux/amd64) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(hardened/linux/amd64/no-multilib) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(hardened/linux/amd64/no-multilib/selinux) ['>=app-emulation/lxc-1.0'] >>app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: >> ~amd64(hardened/linux/amd64/selinux) ['>=app-emulation/lxc-1.0'] >> >> > > Yeah, lets wait for Greg or Tianon to reply and if docker+lxc works for > them we can unmask lxc. > Well, since apparently no one cares about having satisfiable dependencies I just unmasked lxc so that the already-unmasked docker is happy. I have no idea why people enjoy breaking things so much, but at least it won't get boring for me!
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sun, Jun 29, 2014 at 8:36 AM, hasufell wrote: > This is still too vague for me. If it's expected to be short-term, then > it can as well just land in ~arch. A package that hasn't been tested AT ALL doesn't belong in ~arch. Suppose the maintainer is unable to test some aspect of the package, or any aspect of the package? Do we want it to break completely for ~arch? In that event, nobody will run ~arch for that package, and then it still isn't getting tested. I agree that masking for testing is like having a 3rd branch, but I'm not convinced that this is a bad thing. ~arch should be for packages that have received rudimentary testing and which are ready for testing by a larger population. Masking should be used for packages that haven't received rudimentary testing - they might not have been tested at all. Sure, it could go into an overlay, but for that matter so could all of ~arch. I guess the question is, what exactly are we trying to fix? Even if occasionally a maintainer drops the ball and leaves something masked for a year, how is that different from a maintainer dropping the ball and not adding a new release to the main tree for a year? Would we be better off if Docker 1 wasn't in the tree at all? If it happened to have a known issue would ~arch users be better off if some other dev came along and helpfully added it to the tree unmasked no realizing that somebody else was already working on it? Rich
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
Rich Freeman: > On Sun, Jun 29, 2014 at 8:12 AM, hasufell wrote: >> Also, those masks are rarely short-term in practice, because well, see >> this thread. > > Is there any evidence to support this statement? You only notice > masks when they're a problem, and these kinds of masks tend to be a > problem only if they're long-term. > Yeah, I'v been collecting and analyzing data over the years to come up with the results just now ;) I was just giving my own perception of things. >> Developer overlays are widely used. So yes, ~arch users will be testing >> it, probably even arch users. It also limits the potential damage for >> the user, because he can very easily toss out the crap by just >> removing/masking the whole overlay instead of going on adventure reading >> broken portage output. >> > > If I want three users following a bug to test something, it is far > easier to tell them to just unmask it than to tell them to go install > my developer overlay. Also, right now you can't easily pull in just > one package from an overlay, so they get the benefit of installing > whatever else is in my overlay. > 'layman -a overlay && flaggie foo +~amd64 && emerge -av1 foo' can be easier than figuring out masks that maybe even go across multiple dependencies (need to remind anyone of multilib masks and how screwed anyone was/is who mixes only a few ~arch packages with arch?). Also, pulling in just one package from an overlay is almost the same as unmasking a tree ebuild. > And as I stated previously creating an overlay for one package is > unnecessary work. > For single packages, you use your developer overlay. For more complex things like multilib, you create a separate one. > I'm not saying that we should be leaving stuff in the tree for six > months for "testing" - just that there are cases where it can be > convenient to have a short-term mask. This is still too vague for me. If it's expected to be short-term, then it can as well just land in ~arch. If it's not expected to be short-term, then I cannot follow the argument.
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sun, Jun 29, 2014 at 8:12 AM, hasufell wrote: > Also, those masks are rarely short-term in practice, because well, see > this thread. Is there any evidence to support this statement? You only notice masks when they're a problem, and these kinds of masks tend to be a problem only if they're long-term. I certainly have no issues with avoiding masks for testing long-term, unless it is for something like an upstream beta series of releases (but I'd call that masking for beta, not testing). > Developer overlays are widely used. So yes, ~arch users will be testing > it, probably even arch users. It also limits the potential damage for > the user, because he can very easily toss out the crap by just > removing/masking the whole overlay instead of going on adventure reading > broken portage output. > If I want three users following a bug to test something, it is far easier to tell them to just unmask it than to tell them to go install my developer overlay. Also, right now you can't easily pull in just one package from an overlay, so they get the benefit of installing whatever else is in my overlay. And as I stated previously creating an overlay for one package is unnecessary work. I'm not saying that we should be leaving stuff in the tree for six months for "testing" - just that there are cases where it can be convenient to have a short-term mask. Rich
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
Rich Freeman: > > If the only one testing it is the maintainer then it probably > shouldn't go in the tree. However, if the maintainer is working with > others to actually test the package, then a short-term mask is > probably fine. > IMO, if you are testing with others without knowing the outcome yet, then a mask does not make sense. This is actually another story of broken workflow with a minor subplot in VCS. Also, those masks are rarely short-term in practice, because well, see this thread. > In neither case will ~arch users be testing it. Developer overlays are widely used. So yes, ~arch users will be testing it, probably even arch users. It also limits the potential damage for the user, because he can very easily toss out the crap by just removing/masking the whole overlay instead of going on adventure reading broken portage output.
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sun, Jun 29, 2014 at 7:36 AM, hasufell wrote: > If something is that fragile that you want to add it to the tree masked, > maybe it isn't even ready for it yet. > Fun-stuff, alpha-software and other broken things have a good place in > overlays. How is not putting it in the tree at all better than putting it into the tree in a masked state? In neither case will ~arch users be testing it. I think the right approach depends on the situation. If you're taking about something where you have 47 packages that need coordination/testing/etc then an overlay makes sense. If you're talking about an isolated package, then creating an overlay for it seems like overkill. If the only one testing it is the maintainer then it probably shouldn't go in the tree. However, if the maintainer is working with others to actually test the package, then a short-term mask is probably fine. As I said earlier, though, it only makes sense if you're actually going to TEST the package. Adding it, masking it, and walking away for six months doesn't make sense. If a package is being masked because a dependency is being masked, that would be something worth noting in the Changelog. I also have no issues with requiring a bug reference. The purpose of the Changelog is to communicate, so we should be doing that. Rich
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sun, 29 Jun 2014 09:25:16 +0100 Markos Chandras wrote: > It's been a long time and sources.g.o is down so i can't check the > history of that file. $ cvsps -u -f package.mask -l '.*docker.*' -q -g ... --- gentoo-x86/profiles/package.mask:1.15773Tue Jun 10 02:03:02 2014 +++ gentoo-x86/profiles/package.mask Tue Jun 10 02:10:24 2014 @@ -1,5 +1,5 @@ -# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.15773 2014/06/10 02:03:02 floppym Exp $ +# $Header: /var/cvsroot/gentoo-x86/profiles/package.mask,v 1.15774 2014/06/10 02:10:24 patrick Exp $ # # When you add an entry to the top of this file, add your name, the date, and # an explanation of why something is getting masked. Please be extremely @@ -201,6 +201,7 @@ # Markos Chandras (03 May 2014) # Masked for further testing >=app-emulation/lxc-1.0.0 +>=app-emulation/docker-1.0.0 # Tom Wijsman (03 May 2014) # Needs to be further tested and revised by both Java and Ruby herds. ... -- 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] Docker 1.0.0 masked for no known reason?
Greg KH: > On Sun, Jun 29, 2014 at 05:17:36AM +0200, Jeroen Roovers wrote: >> On Sat, 28 Jun 2014 19:58:22 -0700 >> Greg Kroah-Hartman wrote: >> >>> Hi Markos, >>> >>> I was wondering why docker 1.0.0 wasn't seeming to get updated on my >>> boxes recently, despite me commiting the update to the cvs tree, and >>> Tianon noticed that it was masked at the moment: >>> >>> # Markos Chandras (03 May 2014) >>> # Masked for further testing >> >> Oh, that good old "masked for testing", which actually never works. > > Exactly. > Yes, people should stop abusing package.mask for testing purposes. If someone has tested something or it is already known to be broken, then a mask is reasonable. If something is that fragile that you want to add it to the tree masked, maybe it isn't even ready for it yet. Fun-stuff, alpha-software and other broken things have a good place in overlays. That said, we should probably set up a policy to get this into peoples heads: don't mask anything without a bug reference. Sure... there are always exceptions. That's why we would call it a policy. If gentoo users run ~arch they have to accept the fact of downgrades, manual intervention etc. That's what ~arch is for and I am using it exactly like that. Doing the opposite * increases the workload, because we are effectively running 3 branches * decreases the amount of testing for that time period, because... it's masked * causes confusion (see this thread) * decreases the quality of our stable branch, because people suddenly expect the unstable branch to be ...stable and don't bother with filing stabilization requests anymore * makes the whole testing/stabilization iteration actually slower, possibly even causing unnecessary exposures to security issues
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On 06/29/2014 10:23 AM, Patrick Lauer wrote: > On Sunday 29 June 2014 17:03:52 Patrick Lauer wrote: >> On Sunday 29 June 2014 10:12:22 Tom Wijsman wrote: >>> On Sun, 29 Jun 2014 09:09:36 +0100 >>> >>> Markos Chandras wrote: It's been a long time. To be honest I don't remember masking docker but I most likely did it because I was asked to mask >=lxc-1.0.0 by the virtualization team (and Diego (flameeyes). And docker depends on lxc-1.0.0 according to the ebuild. But now that you have unmasked docker, i think the deptree will be broken since lxc is still masked. >>> >>> Repoman is monitored; therefore, someone from the QA team or so has >>> probably masked Docker. Given that broken dependency tree again it is >>> likely to happen again. So, please set it up a satisfiable state. :) >> >> AutoRepoman :) >> >> So that was me fixing the depgraph, taking the easy way out of adding an >> unsatisfiable package to an existing related package.mask. >> >> If people can't be bothered to even run repoman full or commit without >> --force they'll get annoyed by my corrections - maybe it has an educational >> effect ;) >> >> Have fun, >> >> Patrick > > Tadaah: > > dependency.bad22 >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/gnome) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/gnome/systemd) ['>=app- > emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/kde) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/kde/systemd) ['>=app- > emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/developer) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/no-multilib) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/no-multilib/selinux) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/selinux) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/gnome) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/gnome/systemd) ['>=app- > emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/kde) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/desktop/kde/systemd) ['>=app- > emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(default/linux/amd64/13.0/developer) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/no-multilib) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/no-multilib/selinux) ['>=app-emulation/lxc-1.0'] >app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: > ~amd64(hardened/linux/amd64/selinux) ['>=app-emulation/lxc-1.0'] > > Yeah, lets wait for Greg or Tianon to reply and if docker+lxc works for them we can unmask lxc. -- Regards, Markos Chandras
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On 06/29/2014 10:03 AM, Patrick Lauer wrote: > On Sunday 29 June 2014 10:12:22 Tom Wijsman wrote: >> On Sun, 29 Jun 2014 09:09:36 +0100 >> >> Markos Chandras wrote: >>> It's been a long time. To be honest I don't remember masking docker >>> but I most likely did it because I was asked to mask >=lxc-1.0.0 by >>> the virtualization team (and Diego (flameeyes). And docker depends on >>> lxc-1.0.0 according to the ebuild. But now that you have unmasked >>> docker, i think the deptree will be broken since lxc is still masked. >> >> Repoman is monitored; therefore, someone from the QA team or so has >> probably masked Docker. Given that broken dependency tree again it is >> likely to happen again. So, please set it up a satisfiable state. :) > > AutoRepoman :) > > So that was me fixing the depgraph, taking the easy way out of adding an > unsatisfiable package to an existing related package.mask. > > If people can't be bothered to even run repoman full or commit without > --force > they'll get annoyed by my corrections - maybe it has an educational effect ;) > > Have fun, > > Patrick > Thanks for the explanation Patrick -- Regards, Markos Chandras
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sunday 29 June 2014 17:03:52 Patrick Lauer wrote: > On Sunday 29 June 2014 10:12:22 Tom Wijsman wrote: > > On Sun, 29 Jun 2014 09:09:36 +0100 > > > > Markos Chandras wrote: > > > It's been a long time. To be honest I don't remember masking docker > > > but I most likely did it because I was asked to mask >=lxc-1.0.0 by > > > the virtualization team (and Diego (flameeyes). And docker depends on > > > lxc-1.0.0 according to the ebuild. But now that you have unmasked > > > docker, i think the deptree will be broken since lxc is still masked. > > > > Repoman is monitored; therefore, someone from the QA team or so has > > probably masked Docker. Given that broken dependency tree again it is > > likely to happen again. So, please set it up a satisfiable state. :) > > AutoRepoman :) > > So that was me fixing the depgraph, taking the easy way out of adding an > unsatisfiable package to an existing related package.mask. > > If people can't be bothered to even run repoman full or commit without > --force they'll get annoyed by my corrections - maybe it has an educational > effect ;) > > Have fun, > > Patrick Tadaah: dependency.bad22 app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/gnome) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/gnome/systemd) ['>=app- emulation/lxc-1.0'] app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/kde) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/kde/systemd) ['>=app- emulation/lxc-1.0'] app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/developer) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(hardened/linux/amd64) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(hardened/linux/amd64/no-multilib) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(hardened/linux/amd64/no-multilib/selinux) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.0.ebuild: RDEPEND: ~amd64(hardened/linux/amd64/selinux) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/gnome) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/gnome/systemd) ['>=app- emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/kde) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/desktop/kde/systemd) ['>=app- emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(default/linux/amd64/13.0/developer) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(hardened/linux/amd64) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(hardened/linux/amd64/no-multilib) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(hardened/linux/amd64/no-multilib/selinux) ['>=app-emulation/lxc-1.0'] app-emulation/docker/docker-1.0.1.ebuild: RDEPEND: ~amd64(hardened/linux/amd64/selinux) ['>=app-emulation/lxc-1.0']
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sunday 29 June 2014 10:12:22 Tom Wijsman wrote: > On Sun, 29 Jun 2014 09:09:36 +0100 > > Markos Chandras wrote: > > It's been a long time. To be honest I don't remember masking docker > > but I most likely did it because I was asked to mask >=lxc-1.0.0 by > > the virtualization team (and Diego (flameeyes). And docker depends on > > lxc-1.0.0 according to the ebuild. But now that you have unmasked > > docker, i think the deptree will be broken since lxc is still masked. > > Repoman is monitored; therefore, someone from the QA team or so has > probably masked Docker. Given that broken dependency tree again it is > likely to happen again. So, please set it up a satisfiable state. :) AutoRepoman :) So that was me fixing the depgraph, taking the easy way out of adding an unsatisfiable package to an existing related package.mask. If people can't be bothered to even run repoman full or commit without --force they'll get annoyed by my corrections - maybe it has an educational effect ;) Have fun, Patrick
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On 06/29/2014 09:12 AM, Tom Wijsman wrote: > On Sun, 29 Jun 2014 09:09:36 +0100 > Markos Chandras wrote: > >> It's been a long time. To be honest I don't remember masking docker >> but I most likely did it because I was asked to mask >=lxc-1.0.0 by >> the virtualization team (and Diego (flameeyes). And docker depends on >> lxc-1.0.0 according to the ebuild. But now that you have unmasked >> docker, i think the deptree will be broken since lxc is still masked. > > Repoman is monitored; therefore, someone from the QA team or so has > probably masked Docker. Given that broken dependency tree again it is > likely to happen again. So, please set it up a satisfiable state. :) > It's been a long time and sources.g.o is down so i can't check the history of that file. I think docker-1.0 was not present when i first committed >=lxc-1.0.0 in the tree. So, when docker-1.0 was committed, maybe repoman full was not checked, leading to a docker with broken deps and maybe QA team masked it because of that. Anyway apologies for the inconvenience. It was certainly not intentional -- Regards, Markos Chandras
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sun, 29 Jun 2014 09:09:36 +0100 Markos Chandras wrote: > It's been a long time. To be honest I don't remember masking docker > but I most likely did it because I was asked to mask >=lxc-1.0.0 by > the virtualization team (and Diego (flameeyes). And docker depends on > lxc-1.0.0 according to the ebuild. But now that you have unmasked > docker, i think the deptree will be broken since lxc is still masked. Repoman is monitored; therefore, someone from the QA team or so has probably masked Docker. Given that broken dependency tree again it is likely to happen again. So, please set it up a satisfiable state. :) -- 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] Docker 1.0.0 masked for no known reason?
On 06/29/2014 03:58 AM, Greg Kroah-Hartman wrote: > Hi Markos, > > I was wondering why docker 1.0.0 wasn't seeming to get updated on my > boxes recently, despite me commiting the update to the cvs tree, and > Tianon noticed that it was masked at the moment: > > # Markos Chandras (03 May 2014) > # Masked for further testing >> =app-emulation/lxc-1.0.0 >> =app-emulation/docker-1.0.0 > > Which is odd, given that I never saw a bug report, nor did Tianon, and I > thought we were the ones working on maintaining this package in the > tree. > > So, what's up with keeping docker from being updated? Is it just an lxc > bug? This works just fine on my other boxes with other distros :) > > And why mask without at least dropping me an email? > > thanks, > > greg k-h > Hi Greg, It's been a long time. To be honest I don't remember masking docker but I most likely did it because I was asked to mask >=lxc-1.0.0 by the virtualization team (and Diego (flameeyes). And docker depends on lxc-1.0.0 according to the ebuild. But now that you have unmasked docker, i think the deptree will be broken since lxc is still masked. -- Regards, Markos Chandras
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sat, 28 Jun 2014 20:46:08 -0700 Greg KH wrote: > So, given a total lack of "testing" by anyone, I might as well just > remove the mask, so it can actually be done given that people are > wanting the latest Docker release, especially due to the security > fixes in it over the one that is currently not masked... When you do this, please make sure to test the lxc USE flag to see if it actually works; because if it is _broken_, it needs to be put in a package.use.mask file instead until it is fixed up. Consider to not unmask lxc itself until you get response from hwoarang. -- 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] Docker 1.0.0 masked for no known reason?
On Sun, Jun 29, 2014 at 05:17:36AM +0200, Jeroen Roovers wrote: > On Sat, 28 Jun 2014 19:58:22 -0700 > Greg Kroah-Hartman wrote: > > > Hi Markos, > > > > I was wondering why docker 1.0.0 wasn't seeming to get updated on my > > boxes recently, despite me commiting the update to the cvs tree, and > > Tianon noticed that it was masked at the moment: > > > > # Markos Chandras (03 May 2014) > > # Masked for further testing > > Oh, that good old "masked for testing", which actually never works. Exactly. > If you want testing to be done, you don't mask stuff. Also, no bug > number referenced. All you get is someone's e-mail address. So, given a total lack of "testing" by anyone, I might as well just remove the mask, so it can actually be done given that people are wanting the latest Docker release, especially due to the security fixes in it over the one that is currently not masked... thanks, greg k-h
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sat, Jun 28, 2014 at 11:17 PM, Jeroen Roovers wrote: > On Sat, 28 Jun 2014 19:58:22 -0700 > Greg Kroah-Hartman wrote: > >> Hi Markos, >> >> I was wondering why docker 1.0.0 wasn't seeming to get updated on my >> boxes recently, despite me commiting the update to the cvs tree, and >> Tianon noticed that it was masked at the moment: >> >> # Markos Chandras (03 May 2014) >> # Masked for further testing > > Oh, that good old "masked for testing", which actually never works. If > you want testing to be done, you don't mask stuff. Also, no bug number > referenced. All you get is someone's e-mail address. Well, it can make sense if you're actually actively testing it and having it in tree offers convenience when doing so, but generally it should be reserved for cases where it really is actively being tested, and isn't simply sitting around. Then you actually have some kind of roadmap to general release. This is far less disruptive than sticking an ebuild in ~arch when all you know is that it builds. I can't vouch for what is going on in this case. Rich
Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?
On Sat, 28 Jun 2014 19:58:22 -0700 Greg Kroah-Hartman wrote: > Hi Markos, > > I was wondering why docker 1.0.0 wasn't seeming to get updated on my > boxes recently, despite me commiting the update to the cvs tree, and > Tianon noticed that it was masked at the moment: > > # Markos Chandras (03 May 2014) > # Masked for further testing Oh, that good old "masked for testing", which actually never works. If you want testing to be done, you don't mask stuff. Also, no bug number referenced. All you get is someone's e-mail address. jer
[gentoo-dev] Docker 1.0.0 masked for no known reason?
Hi Markos, I was wondering why docker 1.0.0 wasn't seeming to get updated on my boxes recently, despite me commiting the update to the cvs tree, and Tianon noticed that it was masked at the moment: # Markos Chandras (03 May 2014) # Masked for further testing >=app-emulation/lxc-1.0.0 >=app-emulation/docker-1.0.0 Which is odd, given that I never saw a bug report, nor did Tianon, and I thought we were the ones working on maintaining this package in the tree. So, what's up with keeping docker from being updated? Is it just an lxc bug? This works just fine on my other boxes with other distros :) And why mask without at least dropping me an email? thanks, greg k-h
