[gentoo-dev] Docker 1.0.0 masked for no known reason?

[gentoo-dev] Docker 1.0.0 masked for no known reason?

[Greg Kroah-Hartman]

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 <hwoarang@gentoo.org> (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

Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?

[Jeroen Roovers]

On Sat, 28 Jun 2014 19:58:22 -0700
Greg Kroah-Hartman <gregkh@gentoo.org> 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 <hwoarang@gentoo.org> (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

Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?

[Rich Freeman]

On Sat, Jun 28, 2014 at 11:17 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Sat, 28 Jun 2014 19:58:22 -0700
> Greg Kroah-Hartman <gregkh@gentoo.org> 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 <hwoarang@gentoo.org> (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?

[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 <gregkh@gentoo.org> 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 <hwoarang@gentoo.org> (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?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

On Sat, 28 Jun 2014 20:46:08 -0700
Greg KH <gregkh@gentoo.org> 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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?

[hasufell]

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 <gregkh@gentoo.org> 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 <hwoarang@gentoo.org> (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?

[Rich Freeman]

On Sun, Jun 29, 2014 at 7:36 AM, hasufell <hasufell@gentoo.org> 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?

[hasufell]

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?

[Rich Freeman]

On Sun, Jun 29, 2014 at 8:12 AM, hasufell <hasufell@gentoo.org> 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?

[hasufell]

Rich Freeman:
> On Sun, Jun 29, 2014 at 8:12 AM, hasufell <hasufell@gentoo.org> 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?

[Rich Freeman]

On Sun, Jun 29, 2014 at 8:36 AM, hasufell <hasufell@gentoo.org> 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?

[Markos Chandras]

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 <hwoarang@gentoo.org> (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?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

On Sun, 29 Jun 2014 09:09:36 +0100
Markos Chandras <hwoarang@gentoo.org> 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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?

[Markos Chandras]

On 06/29/2014 09:12 AM, Tom Wijsman wrote:
> On Sun, 29 Jun 2014 09:09:36 +0100
> Markos Chandras <hwoarang@gentoo.org> 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?

[Tom Wijsman]

[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]

On Sun, 29 Jun 2014 09:25:16 +0100
Markos Chandras <hwoarang@gentoo.org> 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.15773	Tue 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 <hwoarang@gentoo.org> (03 May 2014)
 # Masked for further testing
 >=app-emulation/lxc-1.0.0
+>=app-emulation/docker-1.0.0
 
 # Tom Wijsman <TomWij@gentoo.org> (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  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?

[Patrick Lauer]

On Sunday 29 June 2014 10:12:22 Tom Wijsman wrote:
> On Sun, 29 Jun 2014 09:09:36 +0100
> 
> Markos Chandras <hwoarang@gentoo.org> 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?

[Patrick Lauer]

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 <hwoarang@gentoo.org> 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.bad                22
   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?

[Markos Chandras]

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 <hwoarang@gentoo.org> 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.bad                22
>    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?

[Patrick Lauer]

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 <hwoarang@gentoo.org> 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.bad                22
>>    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?

[Markos Chandras]

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 <hwoarang@gentoo.org> 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

[gentoo-dev] Re: Docker 1.0.0 masked for no known reason?

[Tianon Gravi]

> Yeah, lets wait for Greg or Tianon to reply and if docker+lxc works for
> them we can unmask lxc.

I've just tested against app-emulation/lxc-1.0.4 and
app-emulation/docker is functioning properly with the "lxc" use flag
enabled and the "lxc" exec-driver in use.

Just so I can make sure to take this learning experience to its
fullest, would an appropriate fix from our end have been to put a USE
mask on the "lxc" use flag of our package so that the dep was masked
instead of the whole package?  I want to do my part to help avoid this
problem in the future, since I'm clearly new. O:)

♥,
- Tianon