[gentoo-dev] Lastrite: media-gfx/pngcrush

[Samuli Suominen]

# Samuli Suominen  (08 Oct 2011)
# Fails to compile against system libpng15, bug 356127
# Removal in 14 days
media-gfx/pngcrush

[gentoo-dev] GCC upgrades, FUD and gentoo documentation

[Sven Vermeulen]

Hi guys

There is some FUD regarding GCC upgrades and I don't have the proper
knowledge to write a correct document on GCC upgrades. As you are currently
aware, we have a GCC upgrade guide [1], but it has seen its last update in
2008. Since then, things have undoubtedly changed.

What I can find on GCC upgrades and their apparent need (or no-need) for
rebuilding stuff:
- Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds from
  that version onwards should not be needed
- The fix_libtool_files.sh command is now part of the toolchain eclass, so
  doesn't need to be ran by users anymore

The only thing I fail to find out is why libtool needs to be rebuild (if it
still needs to be). There are some sources telling it always needs to be
rebuild (RedHat seems to fix the two togather at all times: gcc and
libtool), others state that this is similar towards the C++ ABI, so not
needed anymore since 3.4.0/4.1.0.

I revamped the GCC Upgrade guide [2] with what I think is correct nowadays,
but this is, to be honest, a bit out of my league. That's why I'm asking
you, development community at large, to give some feedback on this, allowing
the GDP to get rid of the FUD once and for all ;-)

Wkr,
Sven Vermeulen

[1] http://www.gentoo.org/doc/en/gcc-upgrading.xml
[2] http://dev.gentoo.org/~swift/docs/previews/gcc-upgrading.xml

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Matt Turner]

On Sat, Oct 8, 2011 at 4:47 AM, Samuli Suominen  wrote:
> # Samuli Suominen  (08 Oct 2011)
> # Fails to compile against system libpng15, bug 356127
> # Removal in 14 days

14 days?

> media-gfx/pngcrush

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Samuli Suominen]

On 10/08/2011 04:19 PM, Matt Turner wrote:
> On Sat, Oct 8, 2011 at 4:47 AM, Samuli Suominen  wrote:
>> # Samuli Suominen  (08 Oct 2011)
>> # Fails to compile against system libpng15, bug 356127
>> # Removal in 14 days
> 
> 14 days?

approx. 14 days and counting to CC archteams in the libpng15
stabilization bug.

the same day the tree is fully prepared for it.
the same day amd64 moves it to stable.

should come as no suprise to anyone at this point...

> 
>> media-gfx/pngcrush
> 

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Markos Chandras]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/08/2011 02:19 PM, Matt Turner wrote:
> On Sat, Oct 8, 2011 at 4:47 AM, Samuli Suominen
>  wrote:
>> # Samuli Suominen  (08 Oct 2011) # Fails to
>> compile against system libpng15, bug 356127 # Removal in 14 days
> 
> 14 days?
> 
>> media-gfx/pngcrush
> 
We can't really wait forever for slacking maintainers to fix their
packages. amd64 is almost ready to have libpng-1.5 stable in the very
near future

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOkFxIAAoJEPqDWhW0r/LCDf4P/jPUyoxorEdg6dxl9PfHMvZw
tmSICvBsqqcd0QRAJ77UKUqoiS/QrPdu/JSvSjJul7wxl86CYoNtgUKF1vYPhxOb
akWxBQxkxHdGjWLQl8ScfueW0eMemMaXaM3dV9ZTCPj8Y0jVS9+SMfTbQXjflZ+N
7A0QPoW0Y8/U8wKjqFyS2HhR1s6KnGYKzoPXb2PdyEWG1CJ9d2iK+RGUNoVEBzxs
HaE3pe7lMkboERhKd2U1grrGDUnsGvJyn6mHo1Q7Jz28eZ3V/tFrYEN9n3AgqYj4
ANvYtUZwdSXeRnp6JxrSUJGo6yqtwVYc2td/V0+x3hxt2gzhyq31ji4kRBq/8jQ2
ZrQ6DKz6aiWLnZS6Oouv5tUr5HPg+qMdNjoOFUz5CxwrfaESQyBS9QxYYhUU3gPh
fF/KZjnkxWx7WTddqBuawqn08KdY0BMIdPvXZZFG2At2ftOlv+ItMSPPRLJfF/ee
ew5SYw0HHa37vYTx30rgS/YfrrWKhpdvvNSw94VYfN1YHgSZmqrLQhooJxbt+q3h
sZWc3L7N9LADZ1ZdqHrrHUZfICCt0JkwlR2TXQ247M06ajPbJu3Vl5EKCR1XGJ+L
DfCFJ72ZriMNvgipfvjUAb4G2FzrEu/5Tt3LEhBC8Zj9Hpnt1ia8lJSasnwnhVzW
TtTkXrCoZlaK9Djri5AD
=4gEc
-END PGP SIGNATURE-

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Fabian Groffen]

On 08-10-2011 15:20:56 +0100, Markos Chandras wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 10/08/2011 02:19 PM, Matt Turner wrote:
> > On Sat, Oct 8, 2011 at 4:47 AM, Samuli Suominen
> >  wrote:
> >> # Samuli Suominen  (08 Oct 2011) # Fails to
> >> compile against system libpng15, bug 356127 # Removal in 14 days
> > 
> > 14 days?
> > 
> >> media-gfx/pngcrush
> > 
> We can't really wait forever for slacking maintainers to fix their
> packages. amd64 is almost ready to have libpng-1.5 stable in the very
> near future

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap8


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Markos Chandras]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/08/2011 03:28 PM, Fabian Groffen wrote:
> On 08-10-2011 15:20:56 +0100, Markos Chandras wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
>> 
>> On 10/08/2011 02:19 PM, Matt Turner wrote:
>>> On Sat, Oct 8, 2011 at 4:47 AM, Samuli Suominen 
>>>  wrote:
 # Samuli Suominen  (08 Oct 2011) #
 Fails to compile against system libpng15, bug 356127 #
 Removal in 14 days
>>> 
>>> 14 days?
>>> 
 media-gfx/pngcrush
>>> 
>> We can't really wait forever for slacking maintainers to fix
>> their packages. amd64 is almost ready to have libpng-1.5 stable
>> in the very near future
> 
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap8
>
> 
> 
In fact, like Samuli said, the waiting period is 14+ which will be more than 30. No reason to
s/14/30/

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOkGLcAAoJEPqDWhW0r/LCHMsP/0bxRFzewgqT3flQExvYvZit
gatc9T++QoOBTmaJORpWgMWcthzhOSuugjC+LSWP5w9v8wPW7wy2jYwKRVHKJ3iY
Zk88aGxSCEp8K39WlG2PYurZMySfM7i+pd8iOgknyJUMNY4Rx2tMpkeWWL6BuwXl
P6BtfyvCWWg32s3yO8GhejYTZsVhjo2w7ECac3VaieDWeEi8qm+PflN86y3y3+x/
AvmS8G2PiK4sEIzZPpVpD43dpVtwnimMXcnpmn7aDtvpXSRr3DqYZsK7BDu2xUWU
P945Y3X0exxdEniy3c8UiGDERb6z1AdqLInEdejQoAqDAiHrozCoYvNcYhSoCcaK
cdg+N1Q55Y/cCGmi+dh6vGwYzKIt4x8O6Zb/pYFORO9Gp5cRjS5KJSu/pnG1xK2F
N+uCGCDzg9ruylWFsflr4yhBuXoLgFc7bJP0WimsLBPgxYhr1YXHYzV2PRwnar2U
BhGZf7NclaJIm2zlqLt5CxSBxJ958rpKURLmlT5Wtv7VX8yWtOJxPqWkd48rDIHu
wkH4PlK8+J3yI0u9eiMbuE1LwVg1eiafI75weJXIh1Yejifli1i5TilNiLtnAgya
5/pATeYQTHAaa3SnCdHuv0lK1Jm+7v+jCK51vy87Wfq/Eu5hIXP+yT6BVCl8m0Mx
l0TX+wu9gRoBMCrCfe7R
=0SYw
-END PGP SIGNATURE-

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Fabian Groffen]

On 08-10-2011 15:49:00 +0100, Markos Chandras wrote:
> >> We can't really wait forever for slacking maintainers to fix
> >> their packages. amd64 is almost ready to have libpng-1.5 stable
> >> in the very near future
> > 
> > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=5#doc_chap8
> >
> In fact, like Samuli said, the waiting period is 14+ test is an become stable> which will be more than 30. No reason to
> s/14/30/

No reason then to confuse people by suggesting the opposite either.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Rich Freeman]

On Sat, Oct 8, 2011 at 10:20 AM, Markos Chandras  wrote:
> On 10/08/2011 02:19 PM, Matt Turner wrote:
>> 14 days?
> We can't really wait forever for slacking maintainers to fix their
> packages. amd64 is almost ready to have libpng-1.5 stable in the very
> near future
>

Didn't we just do this thread a few days ago?  :)

Matt - will an extra 16 days make any difference?  This bug has been
open since Feb.  Will something happen in 30 days that won't happen in
14?

Next, time, though posting an "FYI - we're masking blockers on Oct
7th" or whatever would probably make some happier.

If the extra 16 days will actually accomplish something beyond just
delaying libpng then we can debate the finer points of policy.
However, if we're just arguing policy for its own sake then I don't
see the value.  Perhaps a package maintainer might have the "right" to
a few weeks to fix things, but in the end you have to put the distro
and its users first.  You can do that either by speaking up or
standing aside, but if you're going to speak up, then make sure you
can follow through.

Rich

[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

[Diego Elio Pettenò]

Il giorno sab, 08/10/2011 alle 11.33 +, Sven Vermeulen ha scritto:
> 
> - The fix_libtool_files.sh command is now part of the toolchain
> eclass, so
>   doesn't need to be ran by users anymore 

Moreover, that should only be needed for very old installs: libstdc++.la
that caused the trouble in the first place hasn't been around for over
an year (maybe two? I lost count), and the auto-fix of .la files in
recent Portage versions make it even less necessary.

As for libtool, it is required, but it doesn't happen so often that it
is visible why it's necessary:

% fgrep 4.6.1 /usr/bin/libtool
sys_lib_search_path_spec="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1
/usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib "
sys_lib_dlsearch_path_spec="/lib /usr/lib /lib64 /usr/lib64
/usr/local/lib64 /lib32 /usr/lib32 /usr/local/lib32 /lib /usr/lib
/usr/local/lib /usr/x86_64-pc-linux-gnu/lib
/usr/lib64/opengl/xorg-x11/lib /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/32 /usr/lib/postgresql
/usr/lib64/postgresql /usr/lib64/postgresql-8.4/lib64/
/usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.2
/usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.2/adalib /usr/games/lib
/usr/games/lib64 /usr/games/lib32 /usr/local/xine-lib-1.1/lib64
/usr/local/xine-lib-1.2/lib64 /usr/lib64/path64/lib
/usr/lib64/path64/lib/1.0.0/x8664/64 /opt/ekopath/lib
/opt/ekopath/lib/4.0.11/x8664/64 "
compiler_lib_search_dirs="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64 /lib/../lib64
/usr/lib/../lib64
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../x86_64-pc-linux-gnu/lib
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../.."
predep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/crtbeginS.o"
postdep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64/crtn.o"
compiler_lib_search_path="-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../.."
compiler_lib_search_dirs="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64 /lib/../lib64
/usr/lib/../lib64
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../x86_64-pc-linux-gnu/lib
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../.."
predep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/crtbeginS.o"
postdep_objects="/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64/crtn.o"
compiler_lib_search_path="-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.1/../../.."


-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Fabian Groffen]

On 08-10-2011 11:05:08 -0400, Rich Freeman wrote:
> If the extra 16 days will actually accomplish something beyond just
> delaying libpng then we can debate the finer points of policy.
> However, if we're just arguing policy for its own sake then I don't
> see the value.  Perhaps a package maintainer might have the "right" to
> a few weeks to fix things, but in the end you have to put the distro
> and its users first.  You can do that either by speaking up or
> standing aside, but if you're going to speak up, then make sure you
> can follow through.

It seems to me like you say here that any policy that Gentoo has that
you just don't like can be ignored because, well, you just don't like
it.
We can discuss whether or not the policy is ok, but should we ignore the
policy for that reason?  I think not.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Tomáš Chvátal]

Guys,
the policy makes perfect sense, there are people that sync just
monthly, so they might want to get some headsup why their packages are
going away, and not just remove them.

Thats why the recommended value is 60 days, 30 for urgent cases,
lately we just moved to 30 for everything, but please stick with that,
do not make it lower.

This is not about waiting for maintainer, or slowing up distro, but
letting our users to catch up with what we do.

As a side note masked packages CAN be broken, so the stab can proceed
from the point you mask all the broken ones.

Tom

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Samuli Suominen]

On 10/08/2011 06:13 PM, Fabian Groffen wrote:
> On 08-10-2011 11:05:08 -0400, Rich Freeman wrote:
>> If the extra 16 days will actually accomplish something beyond just
>> delaying libpng then we can debate the finer points of policy.
>> However, if we're just arguing policy for its own sake then I don't
>> see the value.  Perhaps a package maintainer might have the "right" to
>> a few weeks to fix things, but in the end you have to put the distro
>> and its users first.  You can do that either by speaking up or
>> standing aside, but if you're going to speak up, then make sure you
>> can follow through.
> 
> It seems to me like you say here that any policy that Gentoo has that
> you just don't like can be ignored because, well, you just don't like
> it.
> We can discuss whether or not the policy is ok, but should we ignore the
> policy for that reason?  I think not.
> 
> 

It's not like fastened lastriting hasn't happened before. I question
your motives in picking this particular one. It's not like I expected
cookies for the time I've put into this porting effort, but not this
"attack" either.

whatever

- Samuli

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Fabian Groffen]

On 08-10-2011 18:33:15 +0300, Samuli Suominen wrote:
> It's not like fastened lastriting hasn't happened before. I question
> your motives in picking this particular one. It's not like I expected
> cookies for the time I've put into this porting effort, but not this
> "attack" either.

If you feel I'm attacking you, then I apologise.  My personal feeling is
that my response was very mild and not directed to you.  I haven't
responded to your earlier "fastened lastriting" messages on purpose.
Now that Matt brought it up for this package, I just liked to point out
that we have a policy, that was made for some reason, and that you
violated it.

I realise that it may look like I'm picking just on you.  I'm not.  This
is the risk you run as one of the top committers of Gentoo.  I think you
do a lot of good work, and I hope you'll keep on doing so for a long
time.

You just tend to change rules as you see fit every once in a while,
which is a bad thing for Gentoo.  I don't like all policies either, but
I stick to them (for as far as I'm aware of them), because if we all
would start to ignore what we don't like, then what would be the point
in having those policies at first?

Again, this doesn't mean that each policy in its current form is
de-facto the best thing or something like that.


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

[gentoo-dev] integrity of stage files

[Paweł Hajdan, Jr.]

I checked

and the Handbook only mentions validating MD5 checksums.

There are two possible issues:

1. Why are we using _only_ MD5 and SHA1 as the checksums? Shouldn't we
be using something stronger?

2. I noticed the checksums are signed (.asc files). With what key are
they signed? How is that key handled, and how to ensure people use the
right key when verifying the signature?

Paweł



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Matt Turner]

On Sat, Oct 8, 2011 at 10:20 AM, Markos Chandras  wrote:
> On 10/08/2011 02:19 PM, Matt Turner wrote:
>> On Sat, Oct 8, 2011 at 4:47 AM, Samuli Suominen
>>  wrote:
>>> # Samuli Suominen  (08 Oct 2011) # Fails to
>>> compile against system libpng15, bug 356127 # Removal in 14 days
>>
>> 14 days?
>>
>>> media-gfx/pngcrush
>>
> We can't really wait forever for slacking maintainers to fix their
> packages. amd64 is almost ready to have libpng-1.5 stable in the very
> near future

Two things:

1) I'm *really* tired of the usage of the word "slacking" on this
mailing list. If you or someone else wants to pay me to work on
Gentoo, *then* you can tell me that I'm slacking. Otherwise, I'm a
volunteer working on things that interest me in my free time. I truly
do have more important things to do than to figure out how to port
pngcrush to libpng1.5. Namely, graduate school and midterm exams.

2) What exactly is it that you want me to do here? Upstream is aware
of the problem, and seems to be working on it as there are comments
about libpng15 in pngcrush.c. Hanno kindly stepped in and made
pngcrush use a bundled libpng14 (and at the same time bundled zlib,
which has now been fixed), which you promptly masked. I'm not sure if
the problem is bundled libs in general or specifically zlib, but we
*know* it's distasteful. It's not like that's a preferred or permanent
solution. Do you find that somehow more distasteful than removing a
piece of software from from portage that's been in the tree since
2002?

Re: [gentoo-dev] integrity of stage files

[Robin H. Johnson]

On Sat, Oct 08, 2011 at 02:45:02PM -0700, "Paweł Hajdan, Jr." wrote:
> I checked
> 
> and the Handbook only mentions validating MD5 checksums.
> 
> There are two possible issues:
> 
> 1. Why are we using _only_ MD5 and SHA1 as the checksums? Shouldn't we
> be using something stronger?
Fixed in Catalyst now.
http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=commit;h=42b4f6608682cf03954918ecce7923330a1656fe
So when the stagebuilders update their Catalyst, they will be generated
with newer hashes.

> 2. I noticed the checksums are signed (.asc files). With what key are
> they signed? How is that key handled, and how to ensure people use the
> right key when verifying the signature?
Documented here:
http://www.gentoo.org/proj/en/releng/

Relevant to this discussion:
The weekly builds are signed with:
key 2D182910 RSA 4096-bit, generated 2009/08/25
Gentoo Linux Release Engineering (Automated Weekly Release Key) 


It's located in the pipeline that collects stages and isos for publication.

The non-weekly releases (eg 11.2) have a separate key
key 17072058, DSA 1024-bit, generated 2004/07/20
Gentoo Linux Release Engineering (Gentoo Linux Release Signing Key) 


-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] GCC upgrades, FUD and gentoo documentation

[James Cloos]

> "SV" == Sven Vermeulen  writes:

SV> - Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds
SV>   from that version onwards should not be needed

That is not generally true.

I use gcc-4.5 as my system gcc, but mostly use 4.6 when building things
outside of portage.  I still run into compilation errors with C++ which
go away if I compile said code with 4.5.

GCC’s C++ abi is only *mostly* forwards compatible, not *entirely*.

-JimC
-- 
James Cloos  OpenPGP: 1024D/ED7DAEA6

Re: [gentoo-dev] integrity of stage files

[Paweł Hajdan, Jr.]

On 10/8/11 3:43 PM, Robin H. Johnson wrote:
>> 1. Why are we using _only_ MD5 and SHA1 as the checksums? Shouldn't we
>> be using something stronger?
> Fixed in Catalyst now.
> http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=commit;h=42b4f6608682cf03954918ecce7923330a1656fe
> So when the stagebuilders update their Catalyst, they will be generated
> with newer hashes.

Thank you for a quick reaction, but maybe in one aspect it was too
quick:

tells people to use md5sum, and the patch above _removes_ md5 sum, which
means the Handbook instructions now won't work.

Suggested course of action:

1. Please re-add md5 sum.
2. File a bug to modify the handbook to verify sha sum instead.
3. Then remove the checksum.

>> 2. I noticed the checksums are signed (.asc files). With what key are
>> they signed? How is that key handled, and how to ensure people use the
>> right key when verifying the signature?
> Documented here:
> http://www.gentoo.org/proj/en/releng/

Ah, I just forgot about that page. Okay, so can we also update the
Handbook to include GPG signature checking?



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] integrity of stage files

[Robin H. Johnson]

On Sat, Oct 08, 2011 at 04:39:40PM -0700, "Paweł Hajdan, Jr." wrote:
> On 10/8/11 3:43 PM, Robin H. Johnson wrote:
> >> 1. Why are we using _only_ MD5 and SHA1 as the checksums? Shouldn't we
> >> be using something stronger?
> > Fixed in Catalyst now.
> > http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=commit;h=42b4f6608682cf03954918ecce7923330a1656fe
> > So when the stagebuilders update their Catalyst, they will be generated
> > with newer hashes.
> 
> Thank you for a quick reaction, but maybe in one aspect it was too
> quick:
> 
> tells people to use md5sum, and the patch above _removes_ md5 sum, which
> means the Handbook instructions now won't work.
> 
> Suggested course of action:
> 
> 1. Please re-add md5 sum.
Done.
> 2. File a bug to modify the handbook to verify sha sum instead.
https://bugs.gentoo.org/show_bug.cgi?id=386475

> 3. Then remove the checksum.
> 
> >> 2. I noticed the checksums are signed (.asc files). With what key are
> >> they signed? How is that key handled, and how to ensure people use the
> >> right key when verifying the signature?
> > Documented here:
> > http://www.gentoo.org/proj/en/releng/
> Ah, I just forgot about that page. Okay, so can we also update the
> Handbook to include GPG signature checking?
It DOES already mention checking the signature:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=2#doc_chap3

Also opened another bug for correcting keys.
https://bugs.gentoo.org/show_bug.cgi?id=386477

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] GCC upgrades, FUD and gentoo documentation

[Matt Turner]

On Sat, Oct 8, 2011 at 6:57 PM, James Cloos  wrote:
>> "SV" == Sven Vermeulen  writes:
>
> SV> - Since 3.4.0/4.1.0, the C++ ABI is forward-compatible, so rebuilds
> SV>   from that version onwards should not be needed
>
> That is not generally true.
>
> I use gcc-4.5 as my system gcc, but mostly use 4.6 when building things
> outside of portage.  I still run into compilation errors with C++ which
> go away if I compile said code with 4.5.
>
> GCC’s C++ abi is only *mostly* forwards compatible, not *entirely*.

Is that a problem with the ABI, or just that gcc-4.6 is more strict? I
think it's the latter.

Matt

Re: [gentoo-dev] integrity of stage files

[Matt Turner]

On Sat, Oct 8, 2011 at 6:43 PM, Robin H. Johnson  wrote:
> On Sat, Oct 08, 2011 at 02:45:02PM -0700, "Paweł Hajdan, Jr." wrote:
>> I checked
>> 
>> and the Handbook only mentions validating MD5 checksums.
>>
>> There are two possible issues:
>>
>> 1. Why are we using _only_ MD5 and SHA1 as the checksums? Shouldn't we
>> be using something stronger?
> Fixed in Catalyst now.
> http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=commit;h=42b4f6608682cf03954918ecce7923330a1656fe
> So when the stagebuilders update their Catalyst, they will be generated
> with newer hashes.

Well, almost.

The changes you made are in the master branch (for catalyst-3), but
since catalyst-3 isn't really going anywhere fast, you should
cherry-pick your patches back to the catalyst_2 branch so they'll be
available in the next 2.0.6.919 release.

Matt

Re: [gentoo-dev] integrity of stage files

[Robin H. Johnson]

On Sat, Oct 08, 2011 at 08:21:44PM -0400, Matt Turner wrote:
> On Sat, Oct 8, 2011 at 6:43 PM, Robin H. Johnson  wrote:
> > On Sat, Oct 08, 2011 at 02:45:02PM -0700, "Paweł Hajdan, Jr." wrote:
> >> I checked
> >> 
> >> and the Handbook only mentions validating MD5 checksums.
> >>
> >> There are two possible issues:
> >>
> >> 1. Why are we using _only_ MD5 and SHA1 as the checksums? Shouldn't we
> >> be using something stronger?
> > Fixed in Catalyst now.
> > http://git.overlays.gentoo.org/gitweb/?p=proj/catalyst.git;a=commit;h=42b4f6608682cf03954918ecce7923330a1656fe
> > So when the stagebuilders update their Catalyst, they will be generated
> > with newer hashes.
> 
> Well, almost.
> 
> The changes you made are in the master branch (for catalyst-3), but
> since catalyst-3 isn't really going anywhere fast, you should
> cherry-pick your patches back to the catalyst_2 branch so they'll be
> available in the next 2.0.6.919 release.
Done already.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] integrity of stage files

[Paweł Hajdan, Jr.]

On 10/8/11 5:01 PM, Robin H. Johnson wrote:
>> Ah, I just forgot about that page. Okay, so can we also update the
>> Handbook to include GPG signature checking?
> It DOES already mention checking the signature:
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=2#doc_chap3

That's good, but it only mentions GPG for checking downloaded .iso
images. GPG is not mentioned at all for stage files.

For example, I don't re-download the installation .iso very often (old
ones are still good, or one can use sysresccd), but I always re-download
the most recent stages (less rebuilding).



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] integrity of stage files

[Alec Warner]

On Sat, Oct 8, 2011 at 5:41 PM, "Paweł Hajdan, Jr."
 wrote:
> On 10/8/11 5:01 PM, Robin H. Johnson wrote:
>>> Ah, I just forgot about that page. Okay, so can we also update the
>>> Handbook to include GPG signature checking?
>> It DOES already mention checking the signature:
>> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=2#doc_chap3
>
> That's good, but it only mentions GPG for checking downloaded .iso
> images. GPG is not mentioned at all for stage files.
>
> For example, I don't re-download the installation .iso very often (old
> ones are still good, or one can use sysresccd), but I always re-download
> the most recent stages (less rebuilding).
>
>

Why not ship something in /usr/portage/scripts, or write some scripts
to do this?

-A

Re: [gentoo-dev] integrity of stage files

[Robin H. Johnson]

On Sat, Oct 08, 2011 at 05:44:01PM -0700, Alec Warner wrote:
> On Sat, Oct 8, 2011 at 5:41 PM, "Paweł Hajdan, Jr."
>  wrote:
> > On 10/8/11 5:01 PM, Robin H. Johnson wrote:
> >>> Ah, I just forgot about that page. Okay, so can we also update the
> >>> Handbook to include GPG signature checking?
> >> It DOES already mention checking the signature:
> >> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=2#doc_chap3
> >
> > That's good, but it only mentions GPG for checking downloaded .iso
> > images. GPG is not mentioned at all for stage files.
> >
> > For example, I don't re-download the installation .iso very often (old
> > ones are still good, or one can use sysresccd), but I always re-download
> > the most recent stages (less rebuilding).
> Why not ship something in /usr/portage/scripts, or write some scripts
> to do this?
+1 on having scripts, but they need to be in the media, not the scripts
dir.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Markos Chandras]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 10/08/11 22:45, Matt Turner wrote:
> On Sat, Oct 8, 2011 at 10:20 AM, Markos Chandras
>  wrote:
>> On 10/08/2011 02:19 PM, Matt Turner wrote:
>>> On Sat, Oct 8, 2011 at 4:47 AM, Samuli Suominen 
>>>  wrote:
 # Samuli Suominen  (08 Oct 2011) #
 Fails to compile against system libpng15, bug 356127 #
 Removal in 14 days
>>> 
>>> 14 days?
>>> 
 media-gfx/pngcrush
>>> 
>> We can't really wait forever for slacking maintainers to fix
>> their packages. amd64 is almost ready to have libpng-1.5 stable
>> in the very near future
> 
> Two things:
> 
> 1) I'm *really* tired of the usage of the word "slacking" on this 
> mailing list. If you or someone else wants to pay me to work on 
> Gentoo, *then* you can tell me that I'm slacking. Otherwise, I'm a 
> volunteer working on things that interest me in my free time. I
> truly do have more important things to do than to figure out how to
> port pngcrush to libpng1.5. Namely, graduate school and midterm
> exams.

The bug is open since February (9 months). If you can't handle a bug
in 9 months then maybe you should consider stepping down as a
maintainer. Handling does not necessarily mean fixing. Masking could
be an acceptable solution as well. The fact that nobody pays us does
not mean that we can use that as an excuse for lower the QA barrier of
portage tree. If only I got a $1 everytime I hear this "excuse"...

> 
> 2) What exactly is it that you want me to do here? Upstream is
> aware of the problem, and seems to be working on it as there are
> comments about libpng15 in pngcrush.c. Hanno kindly stepped in and
> made pngcrush use a bundled libpng14 (and at the same time bundled
> zlib, which has now been fixed), which you promptly masked. I'm not
> sure if the problem is bundled libs in general or specifically
> zlib, but we *know* it's distasteful. It's not like that's a
> preferred or permanent solution. Do you find that somehow more
> distasteful than removing a piece of software from from portage
> that's been in the tree since 2002?
> 

First of all, pay some attention and ready the masking message. It
says "Waiting for upstream to fix it". It says nothing about removal.
Hanno did two commits
1) use bundled zlib and libpng14. Doh this is not a fix. It is barely
a workaround. What if a vulnerability is discovered in the bundled
version of libpng in the next months? Will upstream fix it? Highly
unlikely since they don't seem able to keep up with libpng releases.

2) Next commit, unbundle zlib, use bundled libpng. Say problem as before.

So until you or upstream or someone else comes up with a proper fix
this will remain masked. If you still disagree feel free to talk to QA.

Finally, yes I know that we have plenty of bundled libs around but
this is not an excuse. Sometimes we cannot avoid that but in this case
it makes perfect sense to mask it and proceed with libpng15
stabilization or whatever. Moreover pngcrush has no rdeps so no other
packages affect by this change. We have the same problem with optipng
but we can't mask it because there are reverse dependencies that will
be affected.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJOkPu7AAoJEPqDWhW0r/LC5OoP/iqw4tdzp/0blCmvKWqLXt9R
DD1EwrBp0o/cvG7RtwMkezW+IDWkBhmQLwXLxSh2pYtSgBzKs6F9FmyI3xkRO6Ba
1dKunJQaqvWDOrfXjvtZZ8FewovFbefxvekZeOh+6FSXXra3JG2sV0aM5JXuM5Xs
fN5DiGNXwzQV8p3XnG2mNldGzwN+Q3w3uWHkAW/ogxC3R7hluieL7P+UVYF2arCJ
v5JXFBoGmHrTvDh4jG10/vunCV0bhK+diXTLA+L4W3nqdcohvNeaulnSXc+v5Q0W
NS1KPTMtWqbuucWU87z189PH2otCrRBC+YTt7Vr/h8lSMfTWQxYQP2bOIUceh8Ru
SG12y6kfU+NPNZxIH5AeO+yeLapQyVDOQBXqbAW2R4+u3H9XNbFxi9aoKhthLBF5
akXcAO/SVji5reDtoMcvsBCgQeqO3eYjagyr8OfLA8Cfh0SqVRbZ9fx79RKSY0fz
uROKXqcEqcD2o4egc0VXDYGtlPm1xZaTwZzLRG3ZKX5DB+p/Smi/fw4SaK9OY+Si
3my9tTT/3jilhQupDytcRbkDV77yleyRy/1eQCxsm/nOoGLTsvXf7bjLS+sscdDU
HUX9+uD2SQFnUxSPyK0axk4FkXXqPteTGKoSNSG5udIBkUg++K8dKHX0pd8Frq6W
wkkFI+lm4pPABkES2Px+
=5dMm
-END PGP SIGNATURE-

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Matt Turner]

On Sat, Oct 8, 2011 at 9:41 PM, Markos Chandras  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 10/08/11 22:45, Matt Turner wrote:
>> On Sat, Oct 8, 2011 at 10:20 AM, Markos Chandras
>>  wrote:
>>> On 10/08/2011 02:19 PM, Matt Turner wrote:
 On Sat, Oct 8, 2011 at 4:47 AM, Samuli Suominen
  wrote:
> # Samuli Suominen  (08 Oct 2011) #
> Fails to compile against system libpng15, bug 356127 #
> Removal in 14 days

 14 days?

> media-gfx/pngcrush

>>> We can't really wait forever for slacking maintainers to fix
>>> their packages. amd64 is almost ready to have libpng-1.5 stable
>>> in the very near future
>>
>> Two things:
>>
>> 1) I'm *really* tired of the usage of the word "slacking" on this
>> mailing list. If you or someone else wants to pay me to work on
>> Gentoo, *then* you can tell me that I'm slacking. Otherwise, I'm a
>> volunteer working on things that interest me in my free time. I
>> truly do have more important things to do than to figure out how to
>> port pngcrush to libpng1.5. Namely, graduate school and midterm
>> exams.
>
> The bug is open since February (9 months). If you can't handle a bug
> in 9 months then maybe you should consider stepping down as a
> maintainer. Handling does not necessarily mean fixing. Masking could
> be an acceptable solution as well. The fact that nobody pays us does
> not mean that we can use that as an excuse for lower the QA barrier of
> portage tree. If only I got a $1 everytime I hear this "excuse"...

Maybe you could check the fucking changelog and see that I added
myself as a maintainer in August?

Don't ever ask me for anything again.

Re: [gentoo-dev] Lastrite: media-gfx/pngcrush

[Rich Freeman]

On Sat, Oct 8, 2011 at 9:41 PM, Markos Chandras  wrote:
> 1) use bundled zlib and libpng14. Doh this is not a fix. It is barely
> a workaround. What if a vulnerability is discovered in the bundled
> version of libpng in the next months? Will upstream fix it? Highly
> unlikely since they don't seem able to keep up with libpng releases.

I'm no sure why a bundled library needs to be cause for masking.  If
there is a vulnerability, of course we should mask away if we can't
fix it within the GLSA guidelines.

I think that the general principle of not bundling libraries is a good
one.  However, that shouldn't be the sole reason for excluding a
package from the tree, and right now I can't see any other reason to
exclude this package since bundling the library fixes the block.  I
haven't seen any evidence presented that upstream is lax with security
- not using the latest version of a library simply is a case of "if it
ain't broke, don't fix it."

Rich