[gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Anthony G. Basile]

Hi everyone,

This is a followup to a discussion on IRC yesterday regarding breakage 
that's occurring to catalyst builds as a result of the recent move from 
dev-python/python-exec to dev-lang/python-exec. The commit of the later 
were pushed into the tree with all KEYWORDS marked stable using repoman 
--force [1].  In catalyst runs where stage1's are built from stage3's 
this leads to the following blockage:

     [ebuild N ] sys-devel/automake-1.13.4 to /tmp/stage1root/
     [ebuild N ] sys-fs/eudev-1.1 to /tmp/stage1root/ USE="-doc -gudev 
-hwdb -introspection -keymap -kmod -modutils -openrc -rule-generator 
(-selinux) -static-libs {-test}"
     [ebuild N ] virtual/udev-200 to /tmp/stage1root/ USE="-gudev -hwdb 
-introspection -keymap -kmod (-selinux) -static-libs"
     [blocks B ] <dev-python/python-exec-10000 
("<dev-python/python-exec-10000" is blocking dev-lang/python-exec-0.3.1)

I was only able to solve this by manually chrooting and running the following

     emerge --unmerge python-exec
     ROOT=/ emerge dev-lang/python-exec

I have to do this on 12 stage3's which is work.

Can I please ask the python team to be more careful and announce such 
commits beforehand so they can be assessed by the community.


Ref.
[1] 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python-exec/ChangeLog?view=log

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Tom Wijsman]

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

On Sat, 02 Nov 2013 09:16:45 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> This is a followup to a discussion on IRC yesterday regarding
> breakage that's occurring to catalyst builds as a result of the
> recent move from dev-python/python-exec to dev-lang/python-exec.

This has been happening to users as well, for example:

http://forums.gentoo.org/viewtopic-t-973998.html
http://forums.gentoo.org/viewtopic-t-974412.html

To move forward and get this resolved, some questions:

1. Has this been resolved for users? Do they just need to sync?
2. If not resolved for users, what is the best temporary workaround?
3. Are you able to fix this? Do you need help to fix this?
4. Depending on the nature of the fix: Would a news item be needed?

From what I heard so far this isn't reproducible by the committer; so,
is anyone else being able to reproduce this? I didn't experience this
either; so, maybe this is only reproducible on a stable system?

-- 
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] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Johann Schmitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02.11.2013 14:51, Tom Wijsman wrote:
> From what I heard so far this isn't reproducible by the committer;
> so, is anyone else being able to reproduce this? I didn't
> experience this either; so, maybe this is only reproducible on a
> stable system?

This one hit me too on several systems: up-to-date arch/~arch mixed
system and stable-only systems. I haven't looked into the block that
deep but removed the old one and emerged the new one.

At work i have several systems now with the block - if someone needs
some information, ping me on IRC or via mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSdQpDAAoJEKCEBkJ3xQHt58gH/18Ulp6IILZ+Y/h6vqOnVICh
dMe1+GMb4tRtph5LzdqTNnziRVQvOclspPfSealgW1VJozgJvYdHaRg/vyHBMarI
aMPN4FIB4xw3PcXa/pbdemVU5Mzf+jHnlIz6HRdARxFp/zg3a7DyppPhJy0gObuh
5Ah9phraKJLgdmVqDZnG+9vEgn4+2PiLd7SAadR4nY+muL+X+HExxr64xmI4t7Jk
FwwyjHgDz558Dd1jZ34oilYXrtDpVcLtCp67S091e/L3lq5vdneF/pxjAkG/bTVH
V9VEQKlJ6p0HFpueB57bdLEmhNLSPPwzoAjF1E24Tc+A95PwYBp35G8WW3CoPU0=
=5pRK
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Michał Górny]

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

Dnia 2013-11-02, o godz. 14:51:26
Tom Wijsman <TomWij@gentoo.org> napisał(a):

> On Sat, 02 Nov 2013 09:16:45 -0400
> "Anthony G. Basile" <blueness@gentoo.org> wrote:
> 
> > This is a followup to a discussion on IRC yesterday regarding
> > breakage that's occurring to catalyst builds as a result of the
> > recent move from dev-python/python-exec to dev-lang/python-exec.
> 
> This has been happening to users as well, for example:
> 
> http://forums.gentoo.org/viewtopic-t-973998.html
> http://forums.gentoo.org/viewtopic-t-974412.html
> 
> To move forward and get this resolved, some questions:
> 
> 1. Has this been resolved for users? Do they just need to sync?
> 2. If not resolved for users, what is the best temporary workaround?
> 3. Are you able to fix this? Do you need help to fix this?
> 4. Depending on the nature of the fix: Would a news item be needed?

From what I heard, most of people get this working through a plain:

  emerge -Du @world

If someone is really reluctant to world updates, it is enough to
upgrade dev-python/python-exec to 10000.*:

  emerge -1v dev-python/python-exec

I was considering writing a news item for it but we discussed it on IRC
and decided that users are really expected to be able to handle
themselves, especially wrt to:

1. using 'emerge -Du @world' to upgrade their systems,

2. reading the blocker output to see that it states
'<dev-python/python-exec-10000' -> which suggests: what if I upgrade to
10000?

If you believe that a news item would be helpful, I'm happy to write
it. Just please make sure that we're all in agreement over the method
of handling the issue.

Additionally, the news item would state how to get rid of the old deps.
This will presumably involve something like:

  emerge -1v $( qdepends -NCQ dev-python/python-exec )

Please note that 'equery d' from gentoolkit is currently broken due to
some random magic inside portage and doesn't list all the packages
correctly.

However, for the latter it would be probably preferred to wait with it
till python-exec:2 is stable on all arches to avoid rebuilding packages
twice in a short time.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/02/2013 11:03 AM, Michał Górny wrote:
> Dnia 2013-11-02, o godz. 14:51:26
> Tom Wijsman <TomWij@gentoo.org> napisał(a):
> 
>> On Sat, 02 Nov 2013 09:16:45 -0400
>> "Anthony G. Basile" <blueness@gentoo.org> wrote:
>>
>>> This is a followup to a discussion on IRC yesterday regarding
>>> breakage that's occurring to catalyst builds as a result of the
>>> recent move from dev-python/python-exec to dev-lang/python-exec.
>>
>> This has been happening to users as well, for example:
>>
>> http://forums.gentoo.org/viewtopic-t-973998.html
>> http://forums.gentoo.org/viewtopic-t-974412.html
>>
>> To move forward and get this resolved, some questions:
>>
>> 1. Has this been resolved for users? Do they just need to sync?
>> 2. If not resolved for users, what is the best temporary workaround?
>> 3. Are you able to fix this? Do you need help to fix this?
>> 4. Depending on the nature of the fix: Would a news item be needed?
> 
> From what I heard, most of people get this working through a plain:
> 
>   emerge -Du @world
> 
> If someone is really reluctant to world updates, it is enough to
> upgrade dev-python/python-exec to 10000.*:
> 
>   emerge -1v dev-python/python-exec
> 
> I was considering writing a news item for it but we discussed it on IRC
> and decided that users are really expected to be able to handle
> themselves, especially wrt to:
> 
> 1. using 'emerge -Du @world' to upgrade their systems,
> 
> 2. reading the blocker output to see that it states
> '<dev-python/python-exec-10000' -> which suggests: what if I upgrade to
> 10000?
> 
> If you believe that a news item would be helpful, I'm happy to write
> it. Just please make sure that we're all in agreement over the method
> of handling the issue.

A news item isn't enough for breaking autobuilds.  If we can't find a
way to do this properly so portage knows how to upgrade then it is being
done WRONG.

Autobuilds break, gentoo can't be installed, the distro dies.  I know,
sounds like I'm making something out of nothing but every time people
look at the stages and notice they are months out of date we find
another blog post announcing how gentoo is dead.

Honestly, if I knew a way to fix this I would have already made any
changes needed to fix it.  Please fix this, because if you don't,
eventually I'll find a way and I doubt you will like it.

- -Zero
> 
> Additionally, the news item would state how to get rid of the old deps.
> This will presumably involve something like:
> 
>   emerge -1v $( qdepends -NCQ dev-python/python-exec )
> 
> Please note that 'equery d' from gentoolkit is currently broken due to
> some random magic inside portage and doesn't list all the packages
> correctly.
> 
> However, for the latter it would be probably preferred to wait with it
> till python-exec:2 is stable on all arches to avoid rebuilding packages
> twice in a short time.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSdVCJAAoJEKXdFCfdEflKLiwP/AjlCVUKeHo7wI8FO6W/VE4u
2Pv2VqaRGQ3KDn/yvHfClfXib8Eu4/KE1cc8kUoP4vspRQLiCz3qMqtYqFy9Y3DF
fPYbBL5w4Z1V/sAho9pd3f2XHAOYwM/G1cD2GfbEHY5XdR4rk8w3AzK8cTCO5gL4
DmbBS1t/G3fLoNBud4pCpM+QCD1edwHWSptjWS2lQN9hNI9VwOBrXmuBKLPHR05F
JyLWiiTbHPD6y/UquVa9uqdcHRJ5uTAyu9CZPu4CDrC3sJuFYuZxYZc2s4VjqyLo
YKXhp5RJjFJT23ZNhM1eAUCH2jxiJM8JoTRC1gYY1mKuWqL3gLojPDjTqS5ukya6
C8mZ9dqEtqEisJuUQPBkuhfKfClmk0sDCTwrtEJCe4day7gX9w5uPZO1oFrJ+/8Y
6M0chyaU33XaZBIRLMo/KaCg0MccW3Oob2AVo8pesrPrmQwPnXnGvps8rlbrkpv+
lFdx1yh/phW2oWq3yVHf4LlPgrajDrgLzDgcVXYKByG/Nd2pKkkbzq/JfAwtfzck
fpufYDbWF3j8ErVGjzWWQLR4NOzf01NC5Q/U4dCVR+Yy4+a0joSuTB6fz2+eFjz8
6NCr7i+lYPcrnnlvf97XBvXhbsf0NIhwiJtMkLi72LKgI+Wn3D/Xc3H62KqjsXDf
Hc3RqAPCSO/GAqf5hqVl
=VeiN
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[yac]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 02 Nov 2013 15:20:41 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/02/2013 11:03 AM, Michał Górny wrote:
> > Dnia 2013-11-02, o godz. 14:51:26
> > Tom Wijsman <TomWij@gentoo.org> napisał(a):
> > 
> >> On Sat, 02 Nov 2013 09:16:45 -0400
> >> "Anthony G. Basile" <blueness@gentoo.org> wrote:
> >>
> >>> This is a followup to a discussion on IRC yesterday regarding
> >>> breakage that's occurring to catalyst builds as a result of the
> >>> recent move from dev-python/python-exec to dev-lang/python-exec.
> >>
> >> This has been happening to users as well, for example:
> >>
> >> http://forums.gentoo.org/viewtopic-t-973998.html
> >> http://forums.gentoo.org/viewtopic-t-974412.html
> >>
> >> To move forward and get this resolved, some questions:
> >>
> >> 1. Has this been resolved for users? Do they just need to sync?
> >> 2. If not resolved for users, what is the best temporary
> >> workaround? 3. Are you able to fix this? Do you need help to fix
> >> this? 4. Depending on the nature of the fix: Would a news item be
> >> needed?
> > 
> > From what I heard, most of people get this working through a plain:
> > 
> >   emerge -Du @world
> > 
> > If someone is really reluctant to world updates, it is enough to
> > upgrade dev-python/python-exec to 10000.*:
> > 
> >   emerge -1v dev-python/python-exec
> > 
> > I was considering writing a news item for it but we discussed it on
> > IRC and decided that users are really expected to be able to handle
> > themselves, especially wrt to:
> > 
> > 1. using 'emerge -Du @world' to upgrade their systems,
> > 
> > 2. reading the blocker output to see that it states
> > '<dev-python/python-exec-10000' -> which suggests: what if I
> > upgrade to 10000?
> > 
> > If you believe that a news item would be helpful, I'm happy to write
> > it. Just please make sure that we're all in agreement over the
> > method of handling the issue.
> 
> A news item isn't enough for breaking autobuilds.  If we can't find a
> way to do this properly so portage knows how to upgrade then it is
> being done WRONG.
> 
> Autobuilds break, gentoo can't be installed, the distro dies.  I know,
> sounds like I'm making something out of nothing but every time people
> look at the stages and notice they are months out of date we find
> another blog post announcing how gentoo is dead.
> 
> Honestly, if I knew a way to fix this I would have already made any
> changes needed to fix it.  Please fix this, because if you don't,
> eventually I'll find a way and I doubt you will like it.

I guess you can run a basic QA like that the image boots and gets the
network up with openQA (or using the same method) at least to detect
such breakage.

> - -Zero
> > 
> > Additionally, the news item would state how to get rid of the old
> > deps. This will presumably involve something like:
> > 
> >   emerge -1v $( qdepends -NCQ dev-python/python-exec )
> > 
> > Please note that 'equery d' from gentoolkit is currently broken due
> > to some random magic inside portage and doesn't list all the
> > packages correctly.
> > 
> > However, for the latter it would be probably preferred to wait with
> > it till python-exec:2 is stable on all arches to avoid rebuilding
> > packages twice in a short time.
> > 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJSdVCJAAoJEKXdFCfdEflKLiwP/AjlCVUKeHo7wI8FO6W/VE4u
> 2Pv2VqaRGQ3KDn/yvHfClfXib8Eu4/KE1cc8kUoP4vspRQLiCz3qMqtYqFy9Y3DF
> fPYbBL5w4Z1V/sAho9pd3f2XHAOYwM/G1cD2GfbEHY5XdR4rk8w3AzK8cTCO5gL4
> DmbBS1t/G3fLoNBud4pCpM+QCD1edwHWSptjWS2lQN9hNI9VwOBrXmuBKLPHR05F
> JyLWiiTbHPD6y/UquVa9uqdcHRJ5uTAyu9CZPu4CDrC3sJuFYuZxYZc2s4VjqyLo
> YKXhp5RJjFJT23ZNhM1eAUCH2jxiJM8JoTRC1gYY1mKuWqL3gLojPDjTqS5ukya6
> C8mZ9dqEtqEisJuUQPBkuhfKfClmk0sDCTwrtEJCe4day7gX9w5uPZO1oFrJ+/8Y
> 6M0chyaU33XaZBIRLMo/KaCg0MccW3Oob2AVo8pesrPrmQwPnXnGvps8rlbrkpv+
> lFdx1yh/phW2oWq3yVHf4LlPgrajDrgLzDgcVXYKByG/Nd2pKkkbzq/JfAwtfzck
> fpufYDbWF3j8ErVGjzWWQLR4NOzf01NC5Q/U4dCVR+Yy4+a0joSuTB6fz2+eFjz8
> 6NCr7i+lYPcrnnlvf97XBvXhbsf0NIhwiJtMkLi72LKgI+Wn3D/Xc3H62KqjsXDf
> Hc3RqAPCSO/GAqf5hqVl
> =VeiN
> -----END PGP SIGNATURE-----
> 



- -- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: F97A36A1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJSdWIUAAoJEIN+7RD5ejahSUgH/1/DJdVBC/4FbLY0iqctdeRr
0nrkTMYM9CSIw9qwakLtxsEHaSStJCOYeOfZ6iMlvpq0mteYBOiTRe69fV37jy/X
72KovFje6Wj1PQwbF1K9jQ47Vw09gaM00HdFz1F6n7pNNHJyujKZaiGN4+jeiBCg
vR/sssus8BJOGY0e0kS6gyBH93GIyZVRodgT7s6JBiOp+1+wZukEQSU+WUNjCTHQ
1RZ93zZ8/5WtIaZDphWxMeoRiw4B0lUJE2QCB63ZCbUBc+kg6ysN++t4f9zvHW1r
viQ8TYk9+L6gpACTmSzHfhTKExUgcXvakQjbFldb7AJwULQXz8DbxDHZbV1lWFw=
=P+Bi
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/02/2013 04:35 PM, yac wrote:
> On Sat, 02 Nov 2013 15:20:41 -0400
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
> 
>> On 11/02/2013 11:03 AM, Michał Górny wrote:
>>> Dnia 2013-11-02, o godz. 14:51:26
>>> Tom Wijsman <TomWij@gentoo.org> napisał(a):
>>>
>>>> On Sat, 02 Nov 2013 09:16:45 -0400
>>>> "Anthony G. Basile" <blueness@gentoo.org> wrote:
>>>>
>>>>> This is a followup to a discussion on IRC yesterday regarding
>>>>> breakage that's occurring to catalyst builds as a result of the
>>>>> recent move from dev-python/python-exec to dev-lang/python-exec.
>>>>
>>>> This has been happening to users as well, for example:
>>>>
>>>> http://forums.gentoo.org/viewtopic-t-973998.html
>>>> http://forums.gentoo.org/viewtopic-t-974412.html
>>>>
>>>> To move forward and get this resolved, some questions:
>>>>
>>>> 1. Has this been resolved for users? Do they just need to sync?
>>>> 2. If not resolved for users, what is the best temporary
>>>> workaround? 3. Are you able to fix this? Do you need help to fix
>>>> this? 4. Depending on the nature of the fix: Would a news item be
>>>> needed?
>>>
>>> From what I heard, most of people get this working through a plain:
>>>
>>>   emerge -Du @world
>>>
>>> If someone is really reluctant to world updates, it is enough to
>>> upgrade dev-python/python-exec to 10000.*:
>>>
>>>   emerge -1v dev-python/python-exec
>>>
>>> I was considering writing a news item for it but we discussed it on
>>> IRC and decided that users are really expected to be able to handle
>>> themselves, especially wrt to:
>>>
>>> 1. using 'emerge -Du @world' to upgrade their systems,
>>>
>>> 2. reading the blocker output to see that it states
>>> '<dev-python/python-exec-10000' -> which suggests: what if I
>>> upgrade to 10000?
>>>
>>> If you believe that a news item would be helpful, I'm happy to write
>>> it. Just please make sure that we're all in agreement over the
>>> method of handling the issue.
> 
>> A news item isn't enough for breaking autobuilds.  If we can't find a
>> way to do this properly so portage knows how to upgrade then it is
>> being done WRONG.
> 
>> Autobuilds break, gentoo can't be installed, the distro dies.  I know,
>> sounds like I'm making something out of nothing but every time people
>> look at the stages and notice they are months out of date we find
>> another blog post announcing how gentoo is dead.
> 
>> Honestly, if I knew a way to fix this I would have already made any
>> changes needed to fix it.  Please fix this, because if you don't,
>> eventually I'll find a way and I doubt you will like it.
> 
> I guess you can run a basic QA like that the image boots and gets the
> network up with openQA (or using the same method) at least to detect
> such breakage.
> 
I think everyone involved knows that manual intervention is needed to
resolve this dep.  I'm sure that things were tested before they were
commited, which leads me to believe that the commiter didn't care that
manual intervention is required.  Sadly, we at releng do.  I am actively
seeking a resolution for this, let's see who commits it first.

- -Zero

>> - -Zero
>>>
>>> Additionally, the news item would state how to get rid of the old
>>> deps. This will presumably involve something like:
>>>
>>>   emerge -1v $( qdepends -NCQ dev-python/python-exec )
>>>
>>> Please note that 'equery d' from gentoolkit is currently broken due
>>> to some random magic inside portage and doesn't list all the
>>> packages correctly.
>>>
>>> However, for the latter it would be probably preferred to wait with
>>> it till python-exec:2 is stable on all arches to avoid rebuilding
>>> packages twice in a short time.
>>>
> 
>> 

> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSdWcjAAoJEKXdFCfdEflK2vYP/Rf2I3SSAm0ZwxJRqYl2Lv+y
TrYscC0ekWn3Z0+FwUz9rhfhWJwoCjCEv7zsxq0UQiQu+xK+DmqXcgw38zYGb6Wv
bPvq8JMpcSa4tz1wW+wbepS31fXq/WlV1E03BRAbUrM1bhxyS2qia8S0AkTyN4xt
UlleZb8Ep0NrlX1JAx/EgLCBmA61xj5ONdIPlyni5RCtnFZIPnMRTVhlFARaWXQJ
coFztk/ke7B43p2Q6wGR6zHRNdnH59gHg6FwDxXsys/AajSDFrR9Id5GoAgOiqPW
9eqbwyR50Csd3H3UKdmit7Tdn80TSt4qWs/NXSrvG+38TVm1U6hY6rVSSHHuUXba
b3QqT/jx7GzUa3GtKp7QD5ZcKk/F2d7z/oOeGUodGNJ8P+5cQHHb96z0vKR6D2lU
DPpH8v5EWAY01PLW/1240mTljT6/30GPNxEgR1oj2GxOUR+gUnVXFARcorP4R5Ek
qv2jLp1SZgQDAht8RfvR1ngXIpQmNyUvYCKQuxu3fwhANxu0T1DqLfO0shxg9FnZ
HrOzlZvsmOtf4dPjJ9kuWPhbRD10VPqy8dzis1jzb9ucSgCP96y1UzbSjuLI183B
gsHfJSERKNZ9E1qWEL5OZ/qv7Q7+zsgG7XTo8/12AQUFIIkA8l7qEvZ0AiOXNxwQ
rHEvm115H5ic0gQ8bG6I
=Y0pJ
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Mike Gilbert]

On Sat, Nov 2, 2013 at 4:57 PM, Rick "Zero_Chaos" Farina
<zerochaos@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/02/2013 04:35 PM, yac wrote:
>> On Sat, 02 Nov 2013 15:20:41 -0400
>> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>
>>> On 11/02/2013 11:03 AM, Michał Górny wrote:
>>>> Dnia 2013-11-02, o godz. 14:51:26
>>>> Tom Wijsman <TomWij@gentoo.org> napisał(a):
>>>>
>>>>> On Sat, 02 Nov 2013 09:16:45 -0400
>>>>> "Anthony G. Basile" <blueness@gentoo.org> wrote:
>>>>>
>>>>>> This is a followup to a discussion on IRC yesterday regarding
>>>>>> breakage that's occurring to catalyst builds as a result of the
>>>>>> recent move from dev-python/python-exec to dev-lang/python-exec.
>>>>>
>>>>> This has been happening to users as well, for example:
>>>>>
>>>>> http://forums.gentoo.org/viewtopic-t-973998.html
>>>>> http://forums.gentoo.org/viewtopic-t-974412.html
>>>>>
>>>>> To move forward and get this resolved, some questions:
>>>>>
>>>>> 1. Has this been resolved for users? Do they just need to sync?
>>>>> 2. If not resolved for users, what is the best temporary
>>>>> workaround? 3. Are you able to fix this? Do you need help to fix
>>>>> this? 4. Depending on the nature of the fix: Would a news item be
>>>>> needed?
>>>>
>>>> From what I heard, most of people get this working through a plain:
>>>>
>>>>   emerge -Du @world
>>>>
>>>> If someone is really reluctant to world updates, it is enough to
>>>> upgrade dev-python/python-exec to 10000.*:
>>>>
>>>>   emerge -1v dev-python/python-exec
>>>>
>>>> I was considering writing a news item for it but we discussed it on
>>>> IRC and decided that users are really expected to be able to handle
>>>> themselves, especially wrt to:
>>>>
>>>> 1. using 'emerge -Du @world' to upgrade their systems,
>>>>
>>>> 2. reading the blocker output to see that it states
>>>> '<dev-python/python-exec-10000' -> which suggests: what if I
>>>> upgrade to 10000?
>>>>
>>>> If you believe that a news item would be helpful, I'm happy to write
>>>> it. Just please make sure that we're all in agreement over the
>>>> method of handling the issue.
>>
>>> A news item isn't enough for breaking autobuilds.  If we can't find a
>>> way to do this properly so portage knows how to upgrade then it is
>>> being done WRONG.
>>
>>> Autobuilds break, gentoo can't be installed, the distro dies.  I know,
>>> sounds like I'm making something out of nothing but every time people
>>> look at the stages and notice they are months out of date we find
>>> another blog post announcing how gentoo is dead.
>>
>>> Honestly, if I knew a way to fix this I would have already made any
>>> changes needed to fix it.  Please fix this, because if you don't,
>>> eventually I'll find a way and I doubt you will like it.
>>
>> I guess you can run a basic QA like that the image boots and gets the
>> network up with openQA (or using the same method) at least to detect
>> such breakage.
>>
> I think everyone involved knows that manual intervention is needed to
> resolve this dep.  I'm sure that things were tested before they were
> commited, which leads me to believe that the commiter didn't care that
> manual intervention is required.  Sadly, we at releng do.  I am actively
> seeking a resolution for this, let's see who commits it first.
>

In most cases, manual intervention is not required, and portage does
the right thing when you run emerge -uD world. If you actually look at
the deps in the tree, it really SHOULD work, and the fact that it can
be resolved manually indicates that we are running into some portage
weirdness.

After it was committed, we starting getting a few reports of cases
where it does not work without some manual intervention (including
releng). I do not believe we have discovered any useful pattern, other
than that is seems to happen more frequently with people who do not
run full world updates.

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Johann Schmitz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I do not believe we have discovered any useful pattern, other than
> that is seems to happen more frequently with people who do not run
> full world updates.

I don't think that running a world update should be valid solution to
solve blocking issues. At work, we have some servers with pretty
ancient package-sets because with newer versions third party apps are
broken. I bump parts of the systems where it's neccessary and leave
the rest alone. As a result i have to deal with all kinds of strange
blockers or blockers which i haven't seen for years. I'm strongly
against this, but it is how it is.


So i have to totally agree with mgorny on
> I was considering writing a news item for it but we discussed it on
> IRC and decided that users are really expected to be able to
> handle themselves, especially wrt to:
> 
> 1. using 'emerge -Du @world' to upgrade their systems,
> 
> 2. reading the blocker output to see that it states 
> '<dev-python/python-exec-10000' -> which suggests: what if I
> upgrade to 10000?
> 

Gentoo isn't a click-and-play distribution. I totally prefer automatic
blocker resolution (as nearly all blockers can nowadays), but if
something can't be solved automatically, everyone should be able to
fix this manually. As long as it doesn't happen every week, i don't
think that it's such a big thing.


>>>> Autobuilds break, gentoo can't be installed, the distro dies.
>>>> I know, sounds like I'm making something out of nothing but
>>>> every time people look at the stages and notice they are
>>>> months out of date we find another blog post announcing how
>>>> gentoo is dead.

I totally understand your point, but if i throw "gentoo python-exec
blocker" into google, the second hit is this thread and the first post
has the solution.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSdgEuAAoJEKCEBkJ3xQHtPH0H/0jZYUgYW1RB2LhSVM67dm+4
5Y76A5APck+cEnDcFBH7S5CQe93yeGwGWmgzBas8A3mvgI80d/IR1x/1iAVjZ9mW
zjtC3gNGjkrqo8ciIOZUIQY4+iA+8XDtTezYGBdGn2H+LZGoqjycwT05Vf8+R06D
CnlL9wyIVaY6VoA0QTSCez0EBd6Pnf7SxVwQHUwI/wt1fi4/hu8NkjFMC6QxLNQh
oBCtI3P/akHrBs8GdZwaXqFTkGRdLUEF0BNljJS4TSg7mum3ZcoU2WgRj8DYL8Ty
/wQX9JERjYb6hU5F6aXrJglUpJ5DKE7KESI6oDOK7DmxORMfndke1i8AKlXaKV8=
=Dzg9
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[yac]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Sat, 02 Nov 2013 16:57:07 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/02/2013 04:35 PM, yac wrote:
> > On Sat, 02 Nov 2013 15:20:41 -0400
> > "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> > 
> >> On 11/02/2013 11:03 AM, Michał Górny wrote:
> >>> Dnia 2013-11-02, o godz. 14:51:26
> >>> Tom Wijsman <TomWij@gentoo.org> napisał(a):
> >>>
> >>>> On Sat, 02 Nov 2013 09:16:45 -0400
> >>>> "Anthony G. Basile" <blueness@gentoo.org> wrote:
> >>>>
> >>>>> This is a followup to a discussion on IRC yesterday regarding
> >>>>> breakage that's occurring to catalyst builds as a result of the
> >>>>> recent move from dev-python/python-exec to dev-lang/python-exec.
> >>>>
> >>>> This has been happening to users as well, for example:
> >>>>
> >>>> http://forums.gentoo.org/viewtopic-t-973998.html
> >>>> http://forums.gentoo.org/viewtopic-t-974412.html
> >>>>
> >>>> To move forward and get this resolved, some questions:
> >>>>
> >>>> 1. Has this been resolved for users? Do they just need to sync?
> >>>> 2. If not resolved for users, what is the best temporary
> >>>> workaround? 3. Are you able to fix this? Do you need help to fix
> >>>> this? 4. Depending on the nature of the fix: Would a news item be
> >>>> needed?
> >>>
> >>> From what I heard, most of people get this working through a
> >>> plain:
> >>>
> >>>   emerge -Du @world
> >>>
> >>> If someone is really reluctant to world updates, it is enough to
> >>> upgrade dev-python/python-exec to 10000.*:
> >>>
> >>>   emerge -1v dev-python/python-exec
> >>>
> >>> I was considering writing a news item for it but we discussed it
> >>> on IRC and decided that users are really expected to be able to
> >>> handle themselves, especially wrt to:
> >>>
> >>> 1. using 'emerge -Du @world' to upgrade their systems,
> >>>
> >>> 2. reading the blocker output to see that it states
> >>> '<dev-python/python-exec-10000' -> which suggests: what if I
> >>> upgrade to 10000?
> >>>
> >>> If you believe that a news item would be helpful, I'm happy to
> >>> write it. Just please make sure that we're all in agreement over
> >>> the method of handling the issue.
> > 
> >> A news item isn't enough for breaking autobuilds.  If we can't
> >> find a way to do this properly so portage knows how to upgrade
> >> then it is being done WRONG.
> > 
> >> Autobuilds break, gentoo can't be installed, the distro dies.  I
> >> know, sounds like I'm making something out of nothing but every
> >> time people look at the stages and notice they are months out of
> >> date we find another blog post announcing how gentoo is dead.
> > 
> >> Honestly, if I knew a way to fix this I would have already made any
> >> changes needed to fix it.  Please fix this, because if you don't,
> >> eventually I'll find a way and I doubt you will like it.
> > 
> > I guess you can run a basic QA like that the image boots and gets
> > the network up with openQA (or using the same method) at least to
> > detect such breakage.
> > 
> I think everyone involved knows that manual intervention is needed to
> resolve this dep.  I'm sure that things were tested before they were
> commited, which leads me to believe that the commiter didn't care that
> manual intervention is required.  Sadly, we at releng do.  I am
> actively seeking a resolution for this, let's see who commits it
> first.

I don't know how this releng stuff works. I bet there is lot of devs
who don't.

Also I think your response is also completely unrelated to my
suggestion. My suggestion is about acting proactively
instead of reactively - automatically testing eg. the image of livecd
iso that gets built to verify eg. it is bootable and network working to
at least detect such breakage and do not publish broken iso instead of
hoping for the best and eventualy getting bug reports.


> - -Zero
> 
> >> - -Zero
> >>>
> >>> Additionally, the news item would state how to get rid of the old
> >>> deps. This will presumably involve something like:
> >>>
> >>>   emerge -1v $( qdepends -NCQ dev-python/python-exec )
> >>>
> >>> Please note that 'equery d' from gentoolkit is currently broken
> >>> due to some random magic inside portage and doesn't list all the
> >>> packages correctly.
> >>>
> >>> However, for the latter it would be probably preferred to wait
> >>> with it till python-exec:2 is stable on all arches to avoid
> >>> rebuilding packages twice in a short time.
> >>>
> > 
> >> 
> 
> > 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJSdWcjAAoJEKXdFCfdEflK2vYP/Rf2I3SSAm0ZwxJRqYl2Lv+y
> TrYscC0ekWn3Z0+FwUz9rhfhWJwoCjCEv7zsxq0UQiQu+xK+DmqXcgw38zYGb6Wv
> bPvq8JMpcSa4tz1wW+wbepS31fXq/WlV1E03BRAbUrM1bhxyS2qia8S0AkTyN4xt
> UlleZb8Ep0NrlX1JAx/EgLCBmA61xj5ONdIPlyni5RCtnFZIPnMRTVhlFARaWXQJ
> coFztk/ke7B43p2Q6wGR6zHRNdnH59gHg6FwDxXsys/AajSDFrR9Id5GoAgOiqPW
> 9eqbwyR50Csd3H3UKdmit7Tdn80TSt4qWs/NXSrvG+38TVm1U6hY6rVSSHHuUXba
> b3QqT/jx7GzUa3GtKp7QD5ZcKk/F2d7z/oOeGUodGNJ8P+5cQHHb96z0vKR6D2lU
> DPpH8v5EWAY01PLW/1240mTljT6/30GPNxEgR1oj2GxOUR+gUnVXFARcorP4R5Ek
> qv2jLp1SZgQDAht8RfvR1ngXIpQmNyUvYCKQuxu3fwhANxu0T1DqLfO0shxg9FnZ
> HrOzlZvsmOtf4dPjJ9kuWPhbRD10VPqy8dzis1jzb9ucSgCP96y1UzbSjuLI183B
> gsHfJSERKNZ9E1qWEL5OZ/qv7Q7+zsgG7XTo8/12AQUFIIkA8l7qEvZ0AiOXNxwQ
> rHEvm115H5ic0gQ8bG6I
> =Y0pJ
> -----END PGP SIGNATURE-----
> 



- -- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: F97A36A1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBCgAGBQJSdXgmAAoJEIN+7RD5ejah9iEH+QGedmUDpFxGxXBzRk+2HQ8/
7uzCxQn6k04AY1184UwOxMR+Vgob949hI2z91zj+sw9m6FaIjQ0Fl9B7Xs3R5FBx
YBlA8UcYHZrC9NHbJURxoM8rPVxUCLebkr4HZKrEG5cm7bIhfxIY6i0S70A6bOPa
kDZSV3K3D9RuLh4/0mQrRZ3AETz4Q+v1Zo/JtVh8TOQ/ln5iLIm1JKMnn67x/AXu
nxr2ZIADgd/DxUhaGAYmev9r7S1iSTXArxkZ249qdZcb80zjahhE1+41K142VjV0
CHI6zXNEISB9GKArH7ZvH/rXPXr8zdjuWW590a4MUVzp8viZtvlPLFSnO4dW+vE=
=37A2
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Anthony G. Basile]

On 11/02/2013 06:09 PM, yac wrote:
> I don't know how this releng stuff works. I bet there is lot of devs
> who don't.

This is why you should announce risking commits.  Because you may not 
know what it will cause, but others will.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[yac]

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

On Sat, 02 Nov 2013 19:19:21 -0400
"Anthony G. Basile" <blueness@gentoo.org> wrote:

> On 11/02/2013 06:09 PM, yac wrote:
> > I don't know how this releng stuff works. I bet there is lot of devs
> > who don't.
> 
> This is why you should announce risking commits.  Because you may not 
> know what it will cause, but others will.
> 

If I don't know in the first place, how do I know it's risky?

Afaik there is no official way to update gentoo, is there?

I personally got used to -uaNDv and I don't even know what exactly is
the difference and it's implications between that and just -uD

-- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: F97A36A1

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

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Anthony G. Basile]

On 11/02/2013 07:45 PM, yac wrote:
> On Sat, 02 Nov 2013 19:19:21 -0400
> "Anthony G. Basile" <blueness@gentoo.org> wrote:
>
>> On 11/02/2013 06:09 PM, yac wrote:
>>> I don't know how this releng stuff works. I bet there is lot of devs
>>> who don't.
>> This is why you should announce risking commits.  Because you may not
>> know what it will cause, but others will.
>>
> If I don't know in the first place, how do I know it's risky?
>
> Afaik there is no official way to update gentoo, is there?
>
> I personally got used to -uaNDv and I don't even know what exactly is
> the difference and it's implications between that and just -uD
>

Adding something to the tree with all keywords set stable is risky. Take 
a look at the original commit.  I understand why mgorny did it, but it 
should have been discussed.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Alan McKinnon]

On 03/11/2013 01:45, yac wrote:
> On Sat, 02 Nov 2013 19:19:21 -0400
> "Anthony G. Basile" <blueness@gentoo.org> wrote:
> 
>> On 11/02/2013 06:09 PM, yac wrote:
>>> I don't know how this releng stuff works. I bet there is lot of devs
>>> who don't.
>>
>> This is why you should announce risking commits.  Because you may not 
>> know what it will cause, but others will.
>>
> 
> If I don't know in the first place, how do I know it's risky?


Assessing risk is somewhat intuitive and relies heavily on experience.

python-exec changes python wrapper scripts, emerge is coded in python.
You have the makings of a circular dep right there and alarms bells
should already be going off in your head.

With risk, you almost always already DO have more information than at
first appears. Learn to trust the little voice in your head, when it
pipes up rather be careful and double check.

> 
> Afaik there is no official way to update gentoo, is there?

It's always been "emerge -avuND world"

> 
> I personally got used to -uaNDv and I don't even know what exactly is
> the difference and it's implications between that and just -uD

the difference is -N, it's in man emerge

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Ben de Groot]

On 3 November 2013 17:02, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On 03/11/2013 01:45, yac wrote:
>>
>> Afaik there is no official way to update gentoo, is there?
>
> It's always been "emerge -avuND world"
>
>>
>> I personally got used to -uaNDv and I don't even know what exactly is
>> the difference and it's implications between that and just -uD
>
> the difference is -N, it's in man emerge
>

We really should change this recommendation to --changed-use instead of -N.
But we also need a short option for that.

-- 
Cheers,

Ben | yngwin
Gentoo developer

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[yac]

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

On Sun, 03 Nov 2013 11:02:31 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 03/11/2013 01:45, yac wrote:
> > On Sat, 02 Nov 2013 19:19:21 -0400
> > "Anthony G. Basile" <blueness@gentoo.org> wrote:
> > 
> >> On 11/02/2013 06:09 PM, yac wrote:
> >>> I don't know how this releng stuff works. I bet there is lot of
> >>> devs who don't.
> >>
> >> This is why you should announce risking commits.  Because you may
> >> not know what it will cause, but others will.
> >>
> > 
> > If I don't know in the first place, how do I know it's risky?
> 
> 
> Assessing risk is somewhat intuitive and relies heavily on experience.
> 
> python-exec changes python wrapper scripts, emerge is coded in python.
> You have the makings of a circular dep right there and alarms bells
> should already be going off in your head.
> 
> With risk, you almost always already DO have more information than at
> first appears. Learn to trust the little voice in your head, when it
> pipes up rather be careful and double check.
> 
> > 
> > Afaik there is no official way to update gentoo, is there?
> 
> It's always been "emerge -avuND world"
> 
> > 
> > I personally got used to -uaNDv and I don't even know what exactly
> > is the difference and it's implications between that and just -uD
> 
> the difference is -N, it's in man emerge

I can read man pages, I know what -N stands for, but I can't say I
understand it with it's implications, as the exact behaviour depends
on the state of tree at last emerge update and the state the portage
tree is currently, which again depends on policies applied to the
packages involved in the system and that's pretty non-trivial thing.

-- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

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

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Anthony G. Basile]

On 11/03/2013 04:02 AM, Alan McKinnon wrote:
> On 03/11/2013 01:45, yac wrote:
>> On Sat, 02 Nov 2013 19:19:21 -0400
>> "Anthony G. Basile" <blueness@gentoo.org> wrote:
>>
>>> On 11/02/2013 06:09 PM, yac wrote:
>>>> I don't know how this releng stuff works. I bet there is lot of devs
>>>> who don't.
>>> This is why you should announce risking commits.  Because you may not
>>> know what it will cause, but others will.
>>>
>> If I don't know in the first place, how do I know it's risky?
>
> Assessing risk is somewhat intuitive and relies heavily on experience.
>
> python-exec changes python wrapper scripts, emerge is coded in python.
> You have the makings of a circular dep right there and alarms bells
> should already be going off in your head.

Correct.  One needs to be particularly careful with python + portage.  
"Careful" here means taking the "alarm bells" seriously and should 
include uncommon but critical environments like catalyst.

>
> With risk, you almost always already DO have more information than at
> first appears. Learn to trust the little voice in your head, when it
> pipes up rather be careful and double check.
>
>> Afaik there is no official way to update gentoo, is there?
> It's always been "emerge -avuND world"

Keep in mind that catalyst runs do something along the lines of:

    ROOT=/tmp/stage1root emerge -e @system

which is why (I think) we are hitting issue there and not in a regular 
setup.  I didn't diagnose to the bottom though.

Getting back to my original post: I want to make the python team aware 
of the needs of releng and exercise care in the future when making a 
commit where "alarm bells" go off.  An email to releng@ or gentoo-dev@ 
asking "will this mess up your stuff" would have been sufficient as we 
then could have tested.  I don't know if any deeper lesson can be 
learned.  I don't expect anyone to have super cow powers and forsee 
every eventuality.  Don't be afraid to use the community.

>
>> I personally got used to -uaNDv and I don't even know what exactly is
>> the difference and it's implications between that and just -uD
> the difference is -N, it's in man emerge
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Mike Gilbert]

On Sun, Nov 3, 2013 at 11:01 AM, Anthony G. Basile <blueness@gentoo.org> wrote:
> Getting back to my original post: I want to make the python team aware of
> the needs of releng and exercise care in the future when making a commit
> where "alarm bells" go off.  An email to releng@ or gentoo-dev@ asking "will
> this mess up your stuff" would have been sufficient as we then could have
> tested.  I don't know if any deeper lesson can be learned.  I don't expect
> anyone to have super cow powers and forsee every eventuality.  Don't be
> afraid to use the community.
>

I think we were rushing to come up with a solution for a problem that
really only affected ~arch, and in the process we caused some problems
for a few stable or mixed-arch users.

It was rushed because we started getting bugs and IRC pings with words
like "QA violation" about the original /var/db/pkg sed hack we had
employed. I think a little patience by all parties would have helped.
As you say, if we had taken the time to ping some people to test it,
the situation may have been avoided.

Official way to do rolling update (Was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[yac]

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

On Sun, 03 Nov 2013 11:02:31 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

[snip]
> > 
> > Afaik there is no official way to update gentoo, is there?
> 
> It's always been "emerge -avuND world"
[snip]

Is this documented annywhere? I have a hard time finding it. I can see
it mentioned eg. in man emerge in -c option but that's not good enough.

Even if it is documented, I think it would be very helpfull to have
such a way implemented as "kind of option" to emerge like `emerge
--standard-ugrade` that would just alias to -uaNDv or possibly leverage
sets like `emerge @upgrade`

-- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

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

Re: Official way to do rolling update (Was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[yac]

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

Please do not reply to this thread.

I've resent the mail without the thread context header.

On Mon, 4 Nov 2013 01:59:19 +0100
yac <yac@gentoo.org> wrote:

> On Sun, 03 Nov 2013 11:02:31 +0200
> Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> 
> [snip]
> > > 
> > > Afaik there is no official way to update gentoo, is there?
> > 
> > It's always been "emerge -avuND world"
> [snip]
> 
> Is this documented annywhere? I have a hard time finding it. I can see
> it mentioned eg. in man emerge in -c option but that's not good
> enough.
> 
> Even if it is documented, I think it would be very helpfull to have
> such a way implemented as "kind of option" to emerge like `emerge
> --standard-ugrade` that would just alias to -uaNDv or possibly
> leverage sets like `emerge @upgrade`
> 



-- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

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

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/02/2013 06:09 PM, yac wrote:
> On Sat, 02 Nov 2013 16:57:07 -0400
> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
> 
>> On 11/02/2013 04:35 PM, yac wrote:
>>> On Sat, 02 Nov 2013 15:20:41 -0400
>>> "Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>
>>>> On 11/02/2013 11:03 AM, Michał Górny wrote:
>>>>> Dnia 2013-11-02, o godz. 14:51:26
>>>>> Tom Wijsman <TomWij@gentoo.org> napisał(a):
>>>>>
>>>>>> On Sat, 02 Nov 2013 09:16:45 -0400
>>>>>> "Anthony G. Basile" <blueness@gentoo.org> wrote:
>>>>>>
>>>>>>> This is a followup to a discussion on IRC yesterday regarding
>>>>>>> breakage that's occurring to catalyst builds as a result of the
>>>>>>> recent move from dev-python/python-exec to dev-lang/python-exec.
>>>>>>
>>>>>> This has been happening to users as well, for example:
>>>>>>
>>>>>> http://forums.gentoo.org/viewtopic-t-973998.html
>>>>>> http://forums.gentoo.org/viewtopic-t-974412.html
>>>>>>
>>>>>> To move forward and get this resolved, some questions:
>>>>>>
>>>>>> 1. Has this been resolved for users? Do they just need to sync?
>>>>>> 2. If not resolved for users, what is the best temporary
>>>>>> workaround? 3. Are you able to fix this? Do you need help to fix
>>>>>> this? 4. Depending on the nature of the fix: Would a news item be
>>>>>> needed?
>>>>>
>>>>> From what I heard, most of people get this working through a
>>>>> plain:
>>>>>
>>>>>   emerge -Du @world
>>>>>
>>>>> If someone is really reluctant to world updates, it is enough to
>>>>> upgrade dev-python/python-exec to 10000.*:
>>>>>
>>>>>   emerge -1v dev-python/python-exec
>>>>>
>>>>> I was considering writing a news item for it but we discussed it
>>>>> on IRC and decided that users are really expected to be able to
>>>>> handle themselves, especially wrt to:
>>>>>
>>>>> 1. using 'emerge -Du @world' to upgrade their systems,
>>>>>
>>>>> 2. reading the blocker output to see that it states
>>>>> '<dev-python/python-exec-10000' -> which suggests: what if I
>>>>> upgrade to 10000?
>>>>>
>>>>> If you believe that a news item would be helpful, I'm happy to
>>>>> write it. Just please make sure that we're all in agreement over
>>>>> the method of handling the issue.
>>>
>>>> A news item isn't enough for breaking autobuilds.  If we can't
>>>> find a way to do this properly so portage knows how to upgrade
>>>> then it is being done WRONG.
>>>
>>>> Autobuilds break, gentoo can't be installed, the distro dies.  I
>>>> know, sounds like I'm making something out of nothing but every
>>>> time people look at the stages and notice they are months out of
>>>> date we find another blog post announcing how gentoo is dead.
>>>
>>>> Honestly, if I knew a way to fix this I would have already made any
>>>> changes needed to fix it.  Please fix this, because if you don't,
>>>> eventually I'll find a way and I doubt you will like it.
>>>
>>> I guess you can run a basic QA like that the image boots and gets
>>> the network up with openQA (or using the same method) at least to
>>> detect such breakage.
>>>
>> I think everyone involved knows that manual intervention is needed to
>> resolve this dep.  I'm sure that things were tested before they were
>> commited, which leads me to believe that the commiter didn't care that
>> manual intervention is required.  Sadly, we at releng do.  I am
>> actively seeking a resolution for this, let's see who commits it
>> first.
> 
> I don't know how this releng stuff works. I bet there is lot of devs
> who don't.
> 
> Also I think your response is also completely unrelated to my
> suggestion. My suggestion is about acting proactively
> instead of reactively - automatically testing eg. the image of livecd
> iso that gets built to verify eg. it is bootable and network working to
> at least detect such breakage and do not publish broken iso instead of
> hoping for the best and eventualy getting bug reports.

The isos are built at least daily by one or more members of releng.
Build tests are automatic, sadly functionality test after the fact are
not.  If you are volunteering to help get some tests up and running then
I'll be happy to dedicate my time to assisting.  I build 4000 packages a
day across 4 profiles and 2 arches and I'm adding more all the time. I
would love to have some functionality tests but I lack the skill to
implement from scratch.

- -Zero
> 
> 
>> - -Zero
> 
>>>> - -Zero
>>>>>
>>>>> Additionally, the news item would state how to get rid of the old
>>>>> deps. This will presumably involve something like:
>>>>>
>>>>>   emerge -1v $( qdepends -NCQ dev-python/python-exec )
>>>>>
>>>>> Please note that 'equery d' from gentoolkit is currently broken
>>>>> due to some random magic inside portage and doesn't list all the
>>>>> packages correctly.
>>>>>
>>>>> However, for the latter it would be probably preferred to wait
>>>>> with it till python-exec:2 is stable on all arches to avoid
>>>>> rebuilding packages twice in a short time.
>>>>>
>>>
>>>>
> 
>>>
> 
>> 

> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSdaxZAAoJEKXdFCfdEflKTMIP/3nxCCAEINL1zO6sSLM1eNd+
rWlfABU8+jURD5OUmwiabw5nZ0/GFQC4X7ETLhHnTj9iI82mytbrjxy6S8UFMx7j
33oyT7As/9XPOEGOu5BHUaZzVIsrwrRZ9KtJOSMhH8mDPe8QfhcAa6J0xwcpF78I
+s9MQ1R8RPtFU5JBGDK2cCOL9SvLYRJtYebtxcosepKBKaKqih7XcZIifhm/3FUw
qfmVhFSTRCRh7nr0FkYEB4Z00OAW9R5BEyAuH96v1Z1hTEpiipAGAKEqUBtnG/ek
hPFF5FLg4TZjXXyQ6AM4dD7G7MKawWHG1ctLWzQJRdtZtbw9L1Ie1PVPp8ZNRJfO
lfhcTkZ3meObR7BnUTB1UQ3JK68WEzMziY0Oq2oFX8bulJFzqPFcgYZHzUeQ0NdY
Xzd8ThtM7O/8ION9nzhI2kuyTeJql7xzfHla8OIDT/17PIwNtw+Y8BEm4+C+f4R0
8q0mUnrbg1QPZ/1iBENJAeo4CTA+GY6M/x3+MUdWXKS3b09GyVZBp1Jo+dyyuPeR
i5O4MA9X+iXp4HxNhZrKJ770rXW7kuZ67AnLk4jzGkkuejG8YuwLAGApEaDTz3at
0KDLIz4fgzmOsyvcMraGaMNmpRxt7dPMHQJnOhCAXTR37Ud6HpjKHaNSEyHJMVAn
bkpRFfnvc3KTX8H+e+5f
=Belt
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 02 Nov 2013 15:20:41 -0400
"Rick \"Zero_Chaos\" Farina" <zerochaos@gentoo.org> wrote:
> A news item isn't enough for breaking autobuilds.  If we can't find a
> way to do this properly so portage knows how to upgrade then it is
> being done WRONG.

Realistically, we're not going to get decent resolutions of these kinds
of thing until we have EAPI support for specifying in a package mangler
readable format what a dependency means and why it is there, rather
than just what does or does not satisfy it.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlJ1ksoACgkQ96zL6DUtXhGRTwCginOc2+dI8zEbNMHQezyE/jmU
2JoAoI3uilx5TCKa9SRssjkEbYWUA+Pw
=/Snz
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Alan McKinnon]

On 02/11/2013 17:03, Michał Górny wrote:
> I was considering writing a news item for it but we discussed it on IRC
> and decided that users are really expected to be able to handle
> themselves, especially wrt to:
> 
> 1. using 'emerge -Du @world' to upgrade their systems,
> 
> 2. reading the blocker output to see that it states
> '<dev-python/python-exec-10000' -> which suggests: what if I upgrade to
> 10000?


Sadly, it's somewhat common for (newish) users to not know what to do
with that. Blocker output can be quite daunting in the beginning,
especially if it's in the middle of 20 other things portage is also
updating.

It's not easy to parse this stuff; I've been using gentoo for what feels
like forever and I still haven't managed to hard-wire my head to read
blockers like an idiom. I have to study it and usually end up reading
the affected ebuild directly.

The basic problem is that there's a lot of information to convey re a
blocker, but to new users it all just looks like noise.

One set of questions that were never answered and probably do deserve
some kind of notification:

1. What exactly is python-exec anyway?
2. Why are there two, in dev-python/ and dev-lang/ ?
3. One has a version of -10000, which is *highly* unusual, what is that
exactly? 1 more than -9999?
4. There is some kind of migration going on between an old and new
python-exec, but I can't understand it using only standard portage tools.

An advance notice was probably warranted in this case, not to avoid
bugs, but just to alert folk that something is coming down the wire and
a short description of what it's trying to achieve. Most folks are
naturally suspicious of anything that alters their python setup.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[yac]

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

On Sun, 03 Nov 2013 10:53:13 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 02/11/2013 17:03, Michał Górny wrote:
> > I was considering writing a news item for it but we discussed it on
> > IRC and decided that users are really expected to be able to handle
> > themselves, especially wrt to:
> > 
> > 1. using 'emerge -Du @world' to upgrade their systems,

I got a blocker on one system even with -uaNDv world

btw, is there a difference betwen world and @world or is just new
syntax?

> > 2. reading the blocker output to see that it states
> > '<dev-python/python-exec-10000' -> which suggests: what if I
> > upgrade to 10000?
> 
> 
> Sadly, it's somewhat common for (newish) users to not know what to do
> with that. Blocker output can be quite daunting in the beginning,
> especially if it's in the middle of 20 other things portage is also
> updating.
> 
> It's not easy to parse this stuff; I've been using gentoo for what
> feels like forever and I still haven't managed to hard-wire my head
> to read blockers like an idiom. I have to study it and usually end up
> reading the affected ebuild directly.

+1 I always have to think hard to get which blocks which and which I
want. Especialy in this case with -10000 and -9999

> The basic problem is that there's a lot of information to convey re a
> blocker, but to new users it all just looks like noise.
> 
> One set of questions that were never answered and probably do deserve
> some kind of notification:
> 
> 1. What exactly is python-exec anyway?

python-exec is the thingie that makes the python thingies install libs
and executables with different names/paths as per python major.minor so
they are available for all the required versions.

> 2. Why are there two, in dev-python/ and dev-lang/ ?
> 3. One has a version of -10000, which is *highly* unusual, what is
> that exactly? 1 more than -9999?
> 4. There is some kind of migration going on between an old and new
> python-exec, but I can't understand it using only standard portage
> tools.

+1 I agree this change was poorly communicated to the users.

> 
> An advance notice was probably warranted in this case, not to avoid
> bugs, but just to alert folk that something is coming down the wire
> and a short description of what it's trying to achieve. Most folks are
> naturally suspicious of anything that alters their python setup.



-- 
Jan Matějka        | Gentoo Developer
https://gentoo.org | Gentoo Linux
GPG: A33E F5BC A9F6 DAFD 2021  6FB6 3EBF D45B EEB6 CA8B

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

[gentoo-dev] Re: Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Duncan]

yac posted on Sun, 03 Nov 2013 11:11:00 +0100 as excerpted:

> btw, is there a difference betwen world and @world or is just new
> syntax?

Too short answer: New syntax.

Middling answer: @world is now preferred, (bare) world support being 
retained for backward compatibility, both with people's "typing memory" 
and with the multitude of helper scripts most long-time gentooers have 
likely devised.

Much longer and more detailed answer: With portage set support @world and 
@system (with the related @selected, @world being the combined @system 
and @selected, as well) are simply two of many available sets, all of 
which are prefixed with @ to denote the set status.  They're the two most 
commonly used sets, with legacy aliases without the @ prefix, sure, but 
they are sets just like other available sets, and the @ prefix makes that 
clear and keeps set notation obvious.  The prefixless variants are 
special-case backward compatibility notation for these sets only, and use 
is discouraged[1] as it's inconsistent with the rules for other sets, but 
it remains available, /purely/ for backward compatibility.

Presumably at some point in the far future those backward compatibility 
aliases could be removed, but I don't think anyone's considering that for 
anything remotely close to current portage -- at this point it's 
"bluesky", something that "might be nice, someday", but nothing that 
they'll do any time soon, as it's too soon to break that backward 
compatibility.


Note[1]: The emerge manpage does not even mention the prefixless 
variants, saying:  "When used as arguments to emerge sets have to be 
prefixed with @ to be recognized."

Unfortunately the handbook apparently hasn't been updated to cover sets 
or the @world form at all, so the handbook (part 2, Working with Gentoo, 
chapter 1, A Portage Introduction, doc_chapter 3, Maintaining Software) 
still uses the bare world form, and there appears to be no discussion of 
sets (presumably as a new "Portage Sets" chapter in part 3, Working with 
Portage) at all. =:^(

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[heroxbd]

Alan McKinnon <alan.mckinnon@gmail.com> writes:

> One set of questions that were never answered and probably do deserve
> some kind of notification:
>
> 1. What exactly is python-exec anyway?
> 2. Why are there two, in dev-python/ and dev-lang/ ?
> 3. One has a version of -10000, which is *highly* unusual, what is that
> exactly? 1 more than -9999?
> 4. There is some kind of migration going on between an old and new
> python-exec, but I can't understand it using only standard portage tools.

I can resonate with these questions.

I bet it's common for people outside the python herd.

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Michał Górny]

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

Dnia 2013-11-03, o godz. 10:53:13
Alan McKinnon <alan.mckinnon@gmail.com> napisał(a):

> One set of questions that were never answered and probably do deserve
> some kind of notification:

I can help you with these. However, I don't know on how much of it
a random user cares.

> 1. What exactly is python-exec anyway?

It's the wrapper script that chooses the proper version of Python
scripts for the currently selected Python version. Say, when you
install 'foomatic' for p2.6, 2.7, 3.2 and 3.3, /usr/bin/foomatic is
linked to python-exec and it determines which one to run.

> 2. Why are there two, in dev-python/ and dev-lang/ ?

The intent is that the one in dev-python/ was not slotted and the one
in dev-lang/ is. This seems like the only sane way to support both
slots without rewriting all the existing deps (which doesn't seem to
work) or risking breaking the system.

> 3. One has a version of -10000, which is *highly* unusual, what is that
> exactly? 1 more than -9999?

It is a plain virtual/compat/meta-package. It is a meaningless version
that is supposed to be larger than anything that was earlier in
dev-python/python-exec and it only pulls in dev-lang/python-exec.

> 4. There is some kind of migration going on between an old and new
> python-exec, but I can't understand it using only standard portage tools.

Yes. The goal is that everything will dep on dev-lang/python-exec:=.
However, we need to somehow keep things that deped on
dev-python/python-exec in the past working.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Alan McKinnon]

On 03/11/2013 12:53, Michał Górny wrote:
> Dnia 2013-11-03, o godz. 10:53:13
> Alan McKinnon <alan.mckinnon@gmail.com> napisał(a):
> 
>> One set of questions that were never answered and probably do deserve
>> some kind of notification:
> 
> I can help you with these. However, I don't know on how much of it
> a random user cares.
> 
>> 1. What exactly is python-exec anyway?
> 
> It's the wrapper script that chooses the proper version of Python
> scripts for the currently selected Python version. Say, when you
> install 'foomatic' for p2.6, 2.7, 3.2 and 3.3, /usr/bin/foomatic is
> linked to python-exec and it determines which one to run.
> 
>> 2. Why are there two, in dev-python/ and dev-lang/ ?
> 
> The intent is that the one in dev-python/ was not slotted and the one
> in dev-lang/ is. This seems like the only sane way to support both
> slots without rewriting all the existing deps (which doesn't seem to
> work) or risking breaking the system.
> 
>> 3. One has a version of -10000, which is *highly* unusual, what is that
>> exactly? 1 more than -9999?
> 
> It is a plain virtual/compat/meta-package. It is a meaningless version
> that is supposed to be larger than anything that was earlier in
> dev-python/python-exec and it only pulls in dev-lang/python-exec.
> 
>> 4. There is some kind of migration going on between an old and new
>> python-exec, but I can't understand it using only standard portage tools.
> 
> Yes. The goal is that everything will dep on dev-lang/python-exec:=.
> However, we need to somehow keep things that deped on
> dev-python/python-exec in the past working.
> 


I didn't make completely clear that the questions were mostly rhetorical
- I since figured out the answers for myself (I'm used to cat'ing
ebuilds almost routinely to find stuff out). But thanks for taking the
time to answer, I'll probably repost to gentoo-user and that will no
doubt help many more people.

It makes a good example - we both made what I believe is the same
mistake. I underestimated that you would understand what I was actually
asking, and the python team underestimated how much information to
convey ahead of time.

I do appreciate hugely all the effort Gentoo devs put into the project
so this isn't a criticism at all, it's more data points of experience
put out there to help devs make judgement calls for the future.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

[IDEA] Enumerate solutions for blockers, to avoid tedious manual work. (was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Tom Wijsman]

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

On Sun, 03 Nov 2013 10:53:13 +0200
Alan McKinnon <alan.mckinnon@gmail.com> wrote:

> On 02/11/2013 17:03, Michał Górny wrote:
> Sadly, it's somewhat common for (newish) users to not know what to do
> with that. Blocker output can be quite daunting in the beginning,
> especially if it's in the middle of 20 other things portage is also
> updating.

+1 I agree, we should look into having errors not only tell what we
should not do, but also tell what we could do; every time I see a
blocker it is annoying that I have to go manually search the solution.

Let's say I have the blocker:

    <dev-python/python-exec-10000 is blocking
    dev-lang/python-exec-0.3.1

We could have it additionally say something like:

    To resolve this blocker, you can run one of the following commands:

        emerge -1 '>=dev-python/python-exec-10000'
        
Taking another example:

    <dev-lang/vala-0.20.0" is blocking
    dev-libs/gobject-introspection-1.36.0-r1

Why not have it say:

    To resolve this blocker, you can run one of the following commands:

        emerge -1 '>=dev-lang/vala-0.20.0'
        emerge -1 '<dev-libs/gobject-introspection-1.36.0'

For the last example it was smart enough to see 1.36.0 and 1.36.0-r1
have this blocker, whereas the lower versions did not; and if there's a
range, it could just list all options.

This spares me out from having to inspect "${PORTDIR}"/dev-lang/vala
and "${PORTDIR}"/dev-libs/gobject-introspection manually to figure out
what's really going on; it's quite repetitive work that we currently
need to do manually for every blocker we meet, which can be automated.

Do other people like this idea? Should it be worded differently? If so,
I might try to work out a patch together with the Portage team.

!! Moving this sub discussion to the Portage Dev ML; please respond
there and drop gentoo-dev from CC, thank you very much in advance.

-- 
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 --]

[gentoo-dev] Re: [IDEA] Enumerate solutions for blockers, to avoid tedious manual work.

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/11/13 07:10 AM, Tom Wijsman wrote:
> On Sun, 03 Nov 2013 10:53:13 +0200 Alan McKinnon
> <alan.mckinnon@gmail.com> wrote:
> 
>> On 02/11/2013 17:03, Michał Górny wrote: Sadly, it's somewhat
>> common for (newish) users to not know what to do with that.
>> Blocker output can be quite daunting in the beginning, especially
>> if it's in the middle of 20 other things portage is also 
>> updating.
> 
> +1 I agree, we should look into having errors not only tell what
> we should not do, but also tell what we could do; every time I see
> a blocker it is annoying that I have to go manually search the
> solution.
> 

This sounds like a great idea.

However, let's first get Portage to stop dumping out massive amounts
of useless and/or meaningless slot collision messages first, seemingly
*whenever* there is some other random and unrelated blockage
triggered.  Dropping the extra noise will help a lot I think to make
things more clear.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlJ3trcACgkQ2ugaI38ACPB+nAD5AXdXTR3Aw3M0hSsneq0kz0A4
qD4R255jipGDETA2NOEA/jGc33K60gquaMd0ByyFkN3+qpUBGvCTVRWrQKqUDyPW
=FpuT
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [IDEA] Enumerate solutions for blockers, to avoid tedious manual work.

[Pacho Ramos]

El lun, 04-11-2013 a las 10:01 -0500, Ian Stakenvicius escribió:
> On 03/11/13 07:10 AM, Tom Wijsman wrote:
> > On Sun, 03 Nov 2013 10:53:13 +0200 Alan McKinnon
> > <alan.mckinnon@gmail.com> wrote:
> > 
> >> On 02/11/2013 17:03, Michał Górny wrote: Sadly, it's somewhat
> >> common for (newish) users to not know what to do with that.
> >> Blocker output can be quite daunting in the beginning, especially
> >> if it's in the middle of 20 other things portage is also 
> >> updating.
> > 
> > +1 I agree, we should look into having errors not only tell what
> > we should not do, but also tell what we could do; every time I see
> > a blocker it is annoying that I have to go manually search the
> > solution.
> > 
> 
> This sounds like a great idea.
> 
> However, let's first get Portage to stop dumping out massive amounts
> of useless and/or meaningless slot collision messages first, seemingly
> *whenever* there is some other random and unrelated blockage
> triggered.  Dropping the extra noise will help a lot I think to make
> things more clear.
> 

I agree, but I think a bug was already opened due that and wasn't so
easy to solve :( (not sure if Zac will read this to clarify). I think it
was a problem due backtracking code

Re: [gentoo-dev] Re: [IDEA] Enumerate solutions for blockers, to avoid tedious manual work.

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/11/13 10:07 AM, Pacho Ramos wrote:
> El lun, 04-11-2013 a las 10:01 -0500, Ian Stakenvicius escribió:
>> On 03/11/13 07:10 AM, Tom Wijsman wrote:
>>> On Sun, 03 Nov 2013 10:53:13 +0200 Alan McKinnon 
>>> <alan.mckinnon@gmail.com> wrote:
>>> 
>>>> On 02/11/2013 17:03, Michał Górny wrote: Sadly, it's
>>>> somewhat common for (newish) users to not know what to do
>>>> with that. Blocker output can be quite daunting in the
>>>> beginning, especially if it's in the middle of 20 other
>>>> things portage is also updating.
>>> 
>>> +1 I agree, we should look into having errors not only tell
>>> what we should not do, but also tell what we could do; every
>>> time I see a blocker it is annoying that I have to go manually
>>> search the solution.
>>> 
>> 
>> This sounds like a great idea.
>> 
>> However, let's first get Portage to stop dumping out massive
>> amounts of useless and/or meaningless slot collision messages
>> first, seemingly *whenever* there is some other random and
>> unrelated blockage triggered.  Dropping the extra noise will help
>> a lot I think to make things more clear.
>> 
> 
> I agree, but I think a bug was already opened due that and wasn't
> so easy to solve :( (not sure if Zac will read this to clarify). I
> think it was a problem due backtracking code
> 
> 

Oh absolutely -- i figured this isn't a trivial issue. :)

But it does seem like something we will need to fix (that is, ensuring
that blocker or conflict messages shown are -only- the ones that are
actually relevant) before being able to make the messages themselves
more user friendly and instructive.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlJ3uzgACgkQ2ugaI38ACPCGWQEAnIq5wGnsInGVH0j/yE8wY/ln
uHkCGQOF3NSKb4zMvVEA/jkBKcA8nvnzepFlkQO1TEzzTlRhOJP82WXcbNS5K2KF
=nNGm
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [IDEA] Enumerate solutions for blockers, to avoid tedious manual work.

[Tom Wijsman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 04 Nov 2013 10:20:24 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:

> Oh absolutely -- i figured this isn't a trivial issue. :)
> 
> But it does seem like something we will need to fix (that is, ensuring
> that blocker or conflict messages shown are -only- the ones that are
> actually relevant) before being able to make the messages themselves
> more user friendly and instructive.

Heh, seems the ML overwrote my Reply-To header (infra bug? it is
correct in Sent); as we're not supposed to be discussing this here.

Yeah, I've asked about "pulled in by (no parents that aren't satisfied
by other packages in this slot)" on #gentoo-portage and it is a weird
state in the backtrack code; it was said by dwfreed there to
intentionally not remove the orphans until it finds a solution, since
it doesn't find one it outputs them. So, we just would need to remove
faux orphans as well when we reach a blocker we can't solve...

Anyhow, it is not a topic for the gentoo-dev ML, but thanks for
mentioning your opinions; I'll be trying to look into this with them.

- -- 
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJSd74JAAoJEJWyH81tNOV9U24IAL4Ijx8p9HvAuc7GyGC14TM8
0gjPdrIC8GVXl96f8I9SQ5L07S76ccda4FRohWuUHP6+cAicvpT5t9UJDfANhDCH
J12vU2Gyq4nUQ0fWxN0hPyKxy96r+UYYjSuEvZyfErr1mZ2QAS2qoTUXCtbUOSNb
NH98FBUIuzdSRiwEQKBsWIaxk3Bt8mHt3Bjd8FrgzhMVXtP0g3eTbtJPAPkjlRzb
Smutg3v1FazxRf5WahTpM6mqYZEmQnkxq/J0HgQKJrb8gAtTSRJQD1re0K5iQiZ8
lluWbdTBOmc+FFlcnQJHDyq22fC5yHpG94VFu/70AVMY/AuB3PDKyvxGjgNsMjI=
=2zZx
-----END PGP SIGNATURE-----

Re: [IDEA] Enumerate solutions for blockers, to avoid tedious manual work. (was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Ruud Koolen]

On Sunday 03 November 2013 13:10:57 Tom Wijsman wrote:
> Let's say I have the blocker:
>
>     <dev-python/python-exec-10000 is blocking
>     dev-lang/python-exec-0.3.1
>
> We could have it additionally say something like:
>
>     To resolve this blocker, you can run one of the following commands:
>
>         emerge -1 '>=dev-python/python-exec-10000'

If portage can do that, what exactly is keeping it from resolving the 
situation fully automatically? If it reliably knows what to emerge to get 
unstuck, it sounds like it would only be a trivial step to actually add this 
information to the dependency resolver.

-- Ruud

Re: [IDEA] Enumerate solutions for blockers, to avoid tedious manual work. (was: Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec)

[Ciaran McCreesh]

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

On Mon, 4 Nov 2013 21:00:16 +0100
Ruud Koolen <redlizard@gentoo.org> wrote:
> On Sunday 03 November 2013 13:10:57 Tom Wijsman wrote:
> > Let's say I have the blocker:
> >
> >     <dev-python/python-exec-10000 is blocking
> >     dev-lang/python-exec-0.3.1
> >
> > We could have it additionally say something like:
> >
> >     To resolve this blocker, you can run one of the following
> > commands:
> >
> >         emerge -1 '>=dev-python/python-exec-10000'
> 
> If portage can do that, what exactly is keeping it from resolving the 
> situation fully automatically?

Fully automatic blocker resolution leads to Portage silently
uninstalling bash.

> If it reliably knows what to emerge to get unstuck, it sounds like it
> would only be a trivial step to actually add this information to the
> dependency resolver.

If you want it to be reliable, you need to give the resolver lots more
information, and you need to make sure developers provide that
information correctly. Such a scheme can certainly be made to work:

http://exherbo.org/docs/exheres-for-smarties.html#annotations

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Sven Eden]

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

Am Samstag, 2. November 2013, 16:03:30 schrieb Michał Górny:
> Dnia 2013-11-02, o godz. 14:51:26
> 
> Tom Wijsman <TomWij@gentoo.org> napisał(a):
> > On Sat, 02 Nov 2013 09:16:45 -0400
> > 
> > "Anthony G. Basile" <blueness@gentoo.org> wrote:
> > > This is a followup to a discussion on IRC yesterday regarding
> > > breakage that's occurring to catalyst builds as a result of the
> > > recent move from dev-python/python-exec to dev-lang/python-exec.
> > 
> > This has been happening to users as well, for example:
> > 
> > http://forums.gentoo.org/viewtopic-t-973998.html
> > http://forums.gentoo.org/viewtopic-t-974412.html
> 
> From what I heard, most of people get this working through a plain:
> 
>   emerge -Du @world
> 
> If someone is really reluctant to world updates, it is enough to
> upgrade dev-python/python-exec to 10000.*:
> 
>   emerge -1v dev-python/python-exec

I tried the world upgrade (yes, with --deep and with "--with-bdeps y" also) to 
no avail.

"emerge -1av --nodeps $(qdepends -q -N -C -Q python-exec)" just wanted to 
rebuild app-portage/smart-live-rebuild - needless to say this didn't solve 
anything.

Even unmerging python-exec didn't help.

The blocker output was the following:

=====
Conflict: 1 block 

!!! Multiple package instances within a single package slot have been pulled 
!!! into the dependency graph, resulting in a slot conflict: 

dev-lang/python-exec:0 

  (dev-lang/python-exec-0.9999::gentoo, ebuild scheduled for merge) pulled in 
by 
    dev-lang/python-exec:0[python_targets_jython2_5(-)?, 
python_targets_jython2_7(-)?, python_targets_pypy2_0(-)?, 
python_targets_python3_2(-)?, python_targets_python3_3(-)?, 
python_targets_python2_6(-)?, python_targets_python2_7(-)?, -
python_single_target_jython2_5(-), -python_single_target_jython2_7(-), -
python_single_target_pypy2_0(-), -python_single_target_python3_2(-), -
python_single_target_python3_3(-), -python_single_target_python2_6(-), -
python_single_target_python2_7(-)] required by (dev-python/python-
exec-10000.1::gentoo, ebuild scheduled for merge) 

  (dev-lang/python-exec-0.3.1::gentoo, ebuild scheduled for merge) pulled in 
by 
    (no parents that aren't satisfied by other packages in this slot) 


!!! Enabling --newuse and --update might solve this conflict. 
!!! If not, it might help emerge to give a more specific suggestion. 


The following keyword changes are necessary to proceed: 
 (see "package.accept_keywords" in the portage(5) man page for more details) 
# required by dev-python/PyQt4-4.10.2 
# required by kde-misc/synaptiks-0.8.1-r4 
# required by @kde_sed 
# required by @selected 
# required by @world (argument) 
=dev-lang/python-exec-0.9999 ** 
=====

PyQt4 and synaptiks were only the messengers, btw.
dev-lang/python-exec-0.9999 has the Targets pypy2_0 and python3_3 which dev-
lang/python-exec-0.3.1 does not have. But both dev-python/python-exec-10000.1 
and dev-python/python-exec-10000.2 want a dev-lang/python-exec:0 with the same 
target setting. 

Btw. Why does dev-python/python-exec:2 has a dependency on dev-python/python-
exec:0 ?


Cheers

Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Sven Eden]

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

Am Montag, 4. November 2013, 10:01:18 schrieb Sven Eden:
> Btw. Why does dev-python/python-exec:2 has a dependency on
> dev-python/python- exec:0 ?

Sorry, I meant: "Why does dev-python/python-exec:2 has a dependency on dev-
lang/python- exec:0 ?" of course.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Michał Górny]

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

Dnia 2013-11-04, o godz. 10:01:18
Sven Eden <sven.eden@gmx.de> napisał(a):

> PyQt4 and synaptiks were only the messengers, btw.
> dev-lang/python-exec-0.9999 has the Targets pypy2_0 and python3_3 which dev-
> lang/python-exec-0.3.1 does not have. But both dev-python/python-exec-10000.1 
> and dev-python/python-exec-10000.2 want a dev-lang/python-exec:0 with the same 
> target setting. 

Did you play with package.accept_keywords? This looks like another
attempt at trying to unmask flags through changing keywords
on packages...

> Btw. Why does dev-python/python-exec:2 has a dependency on dev-python/python-
> exec:0 ?

To avoid mistakenly depcleaning it too early, with old packages that
depended on dev-python/python-exec (with no slot).

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Releng breakage with respect to move from dev-python/python-exec to dev-lang/python-exec

[Sven Eden]

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

Am Montag, 4. November 2013, 12:55:45 schrieben Sie:
> Dnia 2013-11-04, o godz. 10:01:18
> 
> Sven Eden <sven.eden@gmx.de> napisał(a):
> > PyQt4 and synaptiks were only the messengers, btw.
> > dev-lang/python-exec-0.9999 has the Targets pypy2_0 and python3_3 which
> > dev- lang/python-exec-0.3.1 does not have. But both
> > dev-python/python-exec-10000.1 and dev-python/python-exec-10000.2 want a
> > dev-lang/python-exec:0 with the same target setting.
> 
> Did you play with package.accept_keywords? This looks like another
> attempt at trying to unmask flags through changing keywords
> on packages...

No.

 $ wc -l /etc/portage/package.accept_keywords 
0 /etc/portage/package.accept_keywords

But you brought me on the right track, thank you very much!

I had an entry 
dev-lang/python-exec -python_targets_python3_3
In /etc/portage/profile/package.use.mask which was needed to be able to 
install media-gfx/blender.
It's been a while, I do not even remember why this was necessary...

Sorry for the fuss!


> 
> > Btw. Why does dev-python/python-exec:2 has a dependency on
> > dev-python/python- exec:0 ?
> 
> To avoid mistakenly depcleaning it too early, with old packages that
> depended on dev-python/python-exec (with no slot).

Ah, okay. Thank you very much for the clarification!

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]