[gentoo-dev] glibc-2.12 in ~arch

[Mike Frysinger]

glibc-2.12 seems to work for me on amd64/ia64/ppc/ppc64/x86 and no one
has reported significant problems with it, so added to ~arch for the
non-ports arches
-mike

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Dale]

Richard Freeman wrote:

On 08/14/2010 02:35 PM, Duncan wrote:

User perspective here...

For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump.
Yes, it requires a rebuild, but the rebuilds will occur as the bugs are
fixed so it's a few at a time for people who keep reasonably updated
(every month or more frequently).  The alternative is triggering a 
several-

hundred-package rebuild when some base library package updates, because
all those LDFLAGS respecting changes weren't rev-bumped and the user's
installed set is still ignoring them, and thus --as-needed.


Interesting - I was looking at it in the opposite way.

Not having as-needed means that I /might/ have to rebuild that one 
package unnecessarily at some point in the future - if it isn't 
upgraded first for some other reason.


Rev-bumping the build means that I /will/ have to rebuild that one 
package for certain - right now.


I think we can all at least agree that this is a gray area as far as 
the INTENT of the (apparently unwritten) policy goes.


I would like to echo Markos's comment that having policies written 
down, if only to point stubborn maintainers to them, would be 
helpful.  The other reason to have them written is so that they go 
through some kind of review, and there is some way of challenging them 
if they no longer make sense.


In any case, I think we're making a pretty big deal about a pretty 
small issue - we can probably all afford to think about this a little 
more and move on...


Rich





I'm with Duncan as well.  I update pretty regular, usually daily, just 
because I want to update a few packages at a time.  If I do a truly HUGE 
update, what is it that broke what?   If I do 3 to 10 packages and 
something breaks, I can go look at those 3 to 10 packages for either a 
version mismatch or just a plain old broken package.  If I have to 
update everything at once, where does one even start to look?   I have 
almost a thousand packages here and I would hate to have to go look for 
a needle in a haystack.  That's a large haystack to go looking in.


I might also mention that I see rebuilds from time to time where it 
looks like nothing has changed.  I always let them rebuild anyway 
because I know there is something different under the hood that I don't 
see.  Open Office is one that I dread tho.  lol  Even tho it would mean 
a gradual system rebuild, I'd say that I'm for it.  As they get changed, 
bump them up a notch and let them get rebuilt.


Back to my hole now.

Dale

:-)  :-)

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

On Sat, Aug 14, 2010 at 02:46:21PM -0600, Ryan Hill wrote:
> On Sat, 14 Aug 2010 17:00:38 +0300
> Markos Chandras  wrote:
> 
> > > you don't need to subscribe, there's usually an AUTHORS file with emails 
> > > you 
> > > can use...
> > As I said, I thought that maintainers was responsible to do it since they
> > follow all the bug progress after all. So according to you I should do all 
> > the
> > work. Tempting
> 
> When you take on the task of fixing a bug in a package you don't maintain,
> you are responsible for the whole task, not just the part you want to do.
> You essentially become the maintainer for that change.  So just do what you
> would do if it really was your package.
> 
> And really I don't care if you upstream the patch or not, but when the
> maintainer politely asks you to do so the correct response is "okay", not "do
> it yourself".
> 
> 
> -- 
> fonts, gcc-porting,   and it's all by design
> toolchain, wxwidgetsto keep us from losing our minds
> @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

You misunderstood me. I never said "do it yourself". I said that I didn't know
that I have to do it myself and that I will do it from now on

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410


pgp6L6stUZH0S.pgp
Description: PGP signature

Re: [gentoo-dev] keepdir /var/run/package/?

[Mike Frysinger]

On Sat, Aug 14, 2010 at 3:39 PM, Ulrich Mueller wrote:
> On Fri, 13 Aug 2010, Mike Frysinger wrote:
>>> Why not "checkpath -d -o fowner:fgroup -m 0755 /var/run/foo"?
>>
>> i thought there was something.  that was the whole point of Bug
>> 192682.  if we dont get openrc out the door, i'll have to add to
>> baselayout-1.
>
> I thought you already had backported checkpath?
> 

clearly i cant remember anything anymore.  checkpath is indeed in
stable baselayout.
-mike

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Ryan Hill]

On Sat, 14 Aug 2010 17:00:38 +0300
Markos Chandras  wrote:

> > you don't need to subscribe, there's usually an AUTHORS file with emails 
> > you 
> > can use...
> As I said, I thought that maintainers was responsible to do it since they
> follow all the bug progress after all. So according to you I should do all the
> work. Tempting

When you take on the task of fixing a bug in a package you don't maintain,
you are responsible for the whole task, not just the part you want to do.
You essentially become the maintainer for that change.  So just do what you
would do if it really was your package.

And really I don't care if you upstream the patch or not, but when the
maintainer politely asks you to do so the correct response is "okay", not "do
it yourself".


-- 
fonts, gcc-porting,   and it's all by design
toolchain, wxwidgetsto keep us from losing our minds
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Ryan Hill]

On Sat, 14 Aug 2010 19:35:56 +0200
Harald van Dijk  wrote:

> On Sat, Aug 14, 2010 at 06:26:12PM +0200, Thilo Bangert wrote:
> > > So you want me to force everyone to update the package just to respect
> > > the LDFLAGS.
> > 
> > yes. IIRC it has been stated on this list before, that a change which 
> > changes the resulting binary always needs to be done in a revbump. 
> 
> If that's true, that doesn't make sense. Take one extreme case: let's
> say libgcj, part of gcc, has a problem with LDFLAGS, and you fixed it.
> But the majority of people using gcc don't even turn on java support,
> those that do have a working libgcj already, and gcc can easily take
> hours to build. Should you revbump?
> 
> There are always exceptions. Maybe you don't consider LDFLAGS support
> in general one of those exceptions, but clearly some others do. You
> can't just tell them "there are no exceptions" when there are, you need
> to explain why this isn't a valid reason to make an exception.
> My impression, too, is that few people care enough about LDFLAGS support
> to want to rebuild packages for it, so I would not have bumped either,
> but I'm willing to be convinced I'm wrong.

I think it's up to the discretion of the maintainer in this case.  Of course,
when you're not the maintainer, err on the side of caution.

(i wouldn't do a revbump for LDFLAGS on my own packages.  CFLAGS, yes.)


-- 
fonts, gcc-porting,   and it's all by design
toolchain, wxwidgetsto keep us from losing our minds
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS

[Markos Chandras]

On Sat, Aug 14, 2010 at 01:58:57PM -0400, Mike Frysinger wrote:
> On Sat, Aug 14, 2010 at 8:08 AM, Markos Chandras wrote:
> > ~$ cat 
> > development/gentoo-cvs/gentoo-x86/profiles/default/linux/amd64/dev/make.defaults
> 
> i'm pretty sure all the /dev subdirs are dead now and unified in
> targets/developer
> 
> in fact, i dont see anyone referencing that subdir, so i guess we can
> just punt it
> -mike
> 
Just committed that new make.defaults for amd64/10.0/developer profile. 

@x86 Could you please do the same for your dev profile?
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410


pgpSkKyKdXeVs.pgp
Description: PGP signature

Re: [gentoo-dev] keepdir /var/run/package/?

[Ulrich Mueller]

> On Fri, 13 Aug 2010, Mike Frysinger wrote:

>> Why not "checkpath -d -o fowner:fgroup -m 0755 /var/run/foo"?

> i thought there was something.  that was the whole point of Bug
> 192682.  if we dont get openrc out the door, i'll have to add to
> baselayout-1.

I thought you already had backported checkpath?


Ulrich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Richard Freeman]

On 08/14/2010 02:35 PM, Duncan wrote:

User perspective here...

For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump.
Yes, it requires a rebuild, but the rebuilds will occur as the bugs are
fixed so it's a few at a time for people who keep reasonably updated
(every month or more frequently).  The alternative is triggering a several-
hundred-package rebuild when some base library package updates, because
all those LDFLAGS respecting changes weren't rev-bumped and the user's
installed set is still ignoring them, and thus --as-needed.


Interesting - I was looking at it in the opposite way.

Not having as-needed means that I /might/ have to rebuild that one 
package unnecessarily at some point in the future - if it isn't upgraded 
first for some other reason.


Rev-bumping the build means that I /will/ have to rebuild that one 
package for certain - right now.


I think we can all at least agree that this is a gray area as far as the 
INTENT of the (apparently unwritten) policy goes.


I would like to echo Markos's comment that having policies written down, 
if only to point stubborn maintainers to them, would be helpful.  The 
other reason to have them written is so that they go through some kind 
of review, and there is some way of challenging them if they no longer 
make sense.


In any case, I think we're making a pretty big deal about a pretty small 
issue - we can probably all afford to think about this a little more and 
move on...


Rich

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Duncan]

Markos Chandras posted on Sat, 14 Aug 2010 20:00:40 +0300 as excerpted:

> Cause I don't like users to compile the same damn package over and over.
> -r1 for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is
> that a good reason or not? It is not like I introduce huge patches with
> bugfixes etc. My fixes are QA fixes not *serious* bugfixes anyway.
> Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted
> and there isn't much for users to test anyway. Either you respect the
> bloody flags or not. I don't do blindly commits. I try to test the
> packages in multiple chroots anyway.

User perspective here...

For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump.  
Yes, it requires a rebuild, but the rebuilds will occur as the bugs are 
fixed so it's a few at a time for people who keep reasonably updated 
(every month or more frequently).  The alternative is triggering a several-
hundred-package rebuild when some base library package updates, because 
all those LDFLAGS respecting changes weren't rev-bumped and the user's 
installed set is still ignoring them, and thus --as-needed.

Better the few at a time, even if some of them end up being bumped and 
built twice as a result, than the multiple hundred at once.

So I'm not going to get into who's right or wrong vs. current policy, but 
that's my perspective as a user.  For LDFLAGS respecting changes at least, 
please do the rev-bumps, as the cost of failing to do so, thus triggering 
a mass update when a base lib changes, far exceeds that of dealing with 
them on a trickle-in basis, even if a few do end up updated twice as a 
result. 

Thanks.  =:^)

-- 
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] Re: Add --hash-style=gnu to LDFLAGS

[Mike Frysinger]

On Sat, Aug 14, 2010 at 2:31 PM, Samuli Suominen wrote:
> On 08/14/2010 08:58 PM, Mike Frysinger wrote:
>> On Sat, Aug 14, 2010 at 8:08 AM, Markos Chandras wrote:
>>> ~$ cat 
>>> development/gentoo-cvs/gentoo-x86/profiles/default/linux/amd64/dev/make.defaults
>>
>> i'm pretty sure all the /dev subdirs are dead now and unified in
>> targets/developer
>>
>> in fact, i dont see anyone referencing that subdir, so i guess we can
>> just punt it
>
> the dev/ directory in amd64 is special one:
>
> it's for creating emul-linux-x86- packages. it provides "out of box"
> environment for that task.
>
> dont remove it. it's useful & being used.

i guess if i had read dev/32bit-userland/README, i'd know this
-mike

Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS

[Samuli Suominen]

On 08/14/2010 08:58 PM, Mike Frysinger wrote:
> On Sat, Aug 14, 2010 at 8:08 AM, Markos Chandras wrote:
>> ~$ cat 
>> development/gentoo-cvs/gentoo-x86/profiles/default/linux/amd64/dev/make.defaults
> 
> i'm pretty sure all the /dev subdirs are dead now and unified in
> targets/developer
> 
> in fact, i dont see anyone referencing that subdir, so i guess we can
> just punt it

the dev/ directory in amd64 is special one:

it's for creating emul-linux-x86- packages. it provides "out of box"
environment for that task.

dont remove it. it's useful & being used.

Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS

[Markos Chandras]

On Sat, Aug 14, 2010 at 01:58:57PM -0400, Mike Frysinger wrote:
> On Sat, Aug 14, 2010 at 8:08 AM, Markos Chandras wrote:
> > ~$ cat 
> > development/gentoo-cvs/gentoo-x86/profiles/default/linux/amd64/dev/make.defaults
> 
> i'm pretty sure all the /dev subdirs are dead now and unified in
> targets/developer
> 
> in fact, i dont see anyone referencing that subdir, so i guess we can
> just punt it
> -mike
> 
Fair enough. Then I will introduce a new make.defaults
default/linux/amd64/10.0/developer later today.

Thanks to guiding me through this
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410


pgpofU7ZcsHf5.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS

[Mike Frysinger]

On Sat, Aug 14, 2010 at 8:08 AM, Markos Chandras wrote:
> ~$ cat 
> development/gentoo-cvs/gentoo-x86/profiles/default/linux/amd64/dev/make.defaults

i'm pretty sure all the /dev subdirs are dead now and unified in
targets/developer

in fact, i dont see anyone referencing that subdir, so i guess we can
just punt it
-mike

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alex Alexander]

On Sat, Aug 14, 2010 at 08:34:13PM +0300, Markos Chandras wrote:
> > > said, commit an actual patch, assigned to QA and if the rest of the 
> > > members
> > > agree on that I am willing to change my policy.
> > 
> > Now you're just being stubborn. I'm pretty sure your mentor told you "any
> > change to installed files warrants a revbump" ;)
> Pretty sure this rule is not that strict.
> > 
> > Do we really need bureaucracy to enforce a commonly followed but not
> > documented policy?
> So document this policy to point stubborn maintainers to it
> 
> Apparently I pissed a lot people off so I will siege my QA fixes for now.
> Apparently I need a break

I'm pretty sure you didn't piss off anyone.

We're having a conversation about something, we're not fighting :)
-- 
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com


pgpyYRRiLy0N8.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Harald van Dijk]

On Sat, Aug 14, 2010 at 06:26:12PM +0200, Thilo Bangert wrote:
> > So you want me to force everyone to update the package just to respect
> > the LDFLAGS.
> 
> yes. IIRC it has been stated on this list before, that a change which 
> changes the resulting binary always needs to be done in a revbump. 

If that's true, that doesn't make sense. Take one extreme case: let's
say libgcj, part of gcc, has a problem with LDFLAGS, and you fixed it.
But the majority of people using gcc don't even turn on java support,
those that do have a working libgcj already, and gcc can easily take
hours to build. Should you revbump?

There are always exceptions. Maybe you don't consider LDFLAGS support
in general one of those exceptions, but clearly some others do. You
can't just tell them "there are no exceptions" when there are, you need
to explain why this isn't a valid reason to make an exception.
My impression, too, is that few people care enough about LDFLAGS support
to want to rebuild packages for it, so I would not have bumped either,
but I'm willing to be convinced I'm wrong.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

On Sat, Aug 14, 2010 at 08:21:15PM +0300, Alex Alexander wrote:
> On Sat, Aug 14, 2010 at 08:00:40PM +0300, Markos Chandras wrote:
> > On Sat, Aug 14, 2010 at 07:16:26PM +0300, Alex Alexander wrote:
> > > Does respecting LDFLAGS change the installed files in any way? yes.
> > > Will users benefit from your change if you don't revbump? No.
> > > 
> > > I think that chain of logic is enough to warrant a revbump and it is
> > > covered by the devmanual since the change affects the installed package.
> > No it doesn't. If it was that clear we wouldn't debated over this over and
> > over. The cvs logs and you will see that other devs are fixing the package
> > without revbump.
> 
> The fact that others do what you do doesn't automatically make it right.
It means that there is something wrong with documentation
> 
> > > 
> > > It's merely a cp, why are you making such a fuss about it? You're doing
> > > a good job already, we're just pointing out ways to make it even better
> > > 
> > Cause I don't like users to compile the same damn package over and over. -r1
> > for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is that a 
> > good
> > reason or not? It is not like I introduce huge patches with bugfixes etc. My
> > fixes are QA fixes not *serious* bugfixes anyway.
> > Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted and
> > there isn't much for users to test anyway. Either you respect the bloody 
> > flags
> > or not. I don't do blindly commits. I try to test the packages in multiple
> > chroots anyway. 
> 
> All your fixes are important else you wouldn't be doing them.
> 
> I still don't understand why you don't want to revbump.
Cause I already said that I consider my changes trivial so the only actual
testing could be performed when the package is about to get stabilized
> 
> Your changes may not affect program features but they do fix hidden
> issues. Issues that might help users later (for example, rebuilding a
> package with --as-needed may reduce revdep-rebuilds in the future).
> 
> You can always try to reduce revbumps by doing all the things you
> mentioned together, if possible.
No cause I am not the maintainer so I fix whatever gets reported on bugzilla
and assigned to QA.
> 
> In any case, unless we're talking about openoffice or kdelibs, revbumps
> don't really cost so much anymore.
Not if you own a single core CPU
> 
> > > :)
> > > 
> > > BTW, archs do the final testing, but much testing is done by the users
> > > themselves, who report the bugs that get fixed before the packages get a
> > > STABLEREQ bug ;)
> > Most of these bugs don't come from users but from Diego. Why? Because users
> > don't bother reading the build.log and see if all their flags are respected 
> > or
> > not. I wouldn't do it either. This 
> 
> I never said users report these specific bugs. But they will test *your*
> revbumps and may report other problems you didn't hit.
> 
> > > > > Please, don't skip revbumps to avoid "tree spamming", thats why we 
> > > > > have
> > > > > revbumps in the first place ;)
> > I am not convinced yet that this kind of QA fixes require a revbump. As I
> > said, commit an actual patch, assigned to QA and if the rest of the members
> > agree on that I am willing to change my policy.
> 
> Now you're just being stubborn. I'm pretty sure your mentor told you "any
> change to installed files warrants a revbump" ;)
Pretty sure this rule is not that strict.
> 
> Do we really need bureaucracy to enforce a commonly followed but not
> documented policy?
So document this policy to point stubborn maintainers to it

Apparently I pissed a lot people off so I will siege my QA fixes for now.
Apparently I need a break
> 
> > > > > > unless something is on stable branch, I fix it as it is. I don't 
> > > > > > want to
> > > > > > version bump anything because I don't want to mess with anyones
> > > > > > packages. I only do QA fixing. If you have problem touching your
> > > > > > packages just say it
> > > > > > >
> > > > > > > A.
> > > > > > > 
> > > > > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=332523
> > > > > > 
> > > > > > -- 
> > > > > > Markos Chandras (hwoarang)
> > > > > > Gentoo Linux Developer
> > > > > > Web: http://hwoarang.silverarrow.org
> > > > > 
> > > > > -- 
> > > > > Alex Alexander -=- wired
> > > > > Gentoo Linux Developer -=- Council / Qt / KDE / more
> > > > > www.linuxized.com
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > > Markos Chandras (hwoarang)
> > > > Gentoo Linux Developer
> > > > Web: http://hwoarang.silverarrow.org
> > > > Key ID: 441AC410
> > > > Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
> > > 
> > > 
> > > 
> > > -- 
> > > Alex Alexander -=- wired
> > > Gentoo Linux Developer -=- Council / Qt / KDE / more
> > > www.linuxized.com
> > 
> > 
> > 
> > -- 
> > Markos Chandras (hwoarang)
> > Gentoo Linux Developer
> > Web: http://hwoarang.silverarrow.org
> > Key ID: 441AC410
> > Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 4

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alex Alexander]

On Sat, Aug 14, 2010 at 08:00:40PM +0300, Markos Chandras wrote:
> On Sat, Aug 14, 2010 at 07:16:26PM +0300, Alex Alexander wrote:
> > Does respecting LDFLAGS change the installed files in any way? yes.
> > Will users benefit from your change if you don't revbump? No.
> > 
> > I think that chain of logic is enough to warrant a revbump and it is
> > covered by the devmanual since the change affects the installed package.
> No it doesn't. If it was that clear we wouldn't debated over this over and
> over. The cvs logs and you will see that other devs are fixing the package
> without revbump.

The fact that others do what you do doesn't automatically make it right.

> > 
> > It's merely a cp, why are you making such a fuss about it? You're doing
> > a good job already, we're just pointing out ways to make it even better
> > 
> Cause I don't like users to compile the same damn package over and over. -r1
> for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is that a good
> reason or not? It is not like I introduce huge patches with bugfixes etc. My
> fixes are QA fixes not *serious* bugfixes anyway.
> Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted and
> there isn't much for users to test anyway. Either you respect the bloody flags
> or not. I don't do blindly commits. I try to test the packages in multiple
> chroots anyway. 

All your fixes are important else you wouldn't be doing them.

I still don't understand why you don't want to revbump.

Your changes may not affect program features but they do fix hidden
issues. Issues that might help users later (for example, rebuilding a
package with --as-needed may reduce revdep-rebuilds in the future).

You can always try to reduce revbumps by doing all the things you
mentioned together, if possible.

In any case, unless we're talking about openoffice or kdelibs, revbumps
don't really cost so much anymore.

> > :)
> > 
> > BTW, archs do the final testing, but much testing is done by the users
> > themselves, who report the bugs that get fixed before the packages get a
> > STABLEREQ bug ;)
> Most of these bugs don't come from users but from Diego. Why? Because users
> don't bother reading the build.log and see if all their flags are respected or
> not. I wouldn't do it either. This 

I never said users report these specific bugs. But they will test *your*
revbumps and may report other problems you didn't hit.

> > > > Please, don't skip revbumps to avoid "tree spamming", thats why we have
> > > > revbumps in the first place ;)
> I am not convinced yet that this kind of QA fixes require a revbump. As I
> said, commit an actual patch, assigned to QA and if the rest of the members
> agree on that I am willing to change my policy.

Now you're just being stubborn. I'm pretty sure your mentor told you "any
change to installed files warrants a revbump" ;)

Do we really need bureaucracy to enforce a commonly followed but not
documented policy?

> > > > > unless something is on stable branch, I fix it as it is. I don't want 
> > > > > to
> > > > > version bump anything because I don't want to mess with anyones
> > > > > packages. I only do QA fixing. If you have problem touching your
> > > > > packages just say it
> > > > > >
> > > > > > A.
> > > > > > 
> > > > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=332523
> > > > > 
> > > > > -- 
> > > > > Markos Chandras (hwoarang)
> > > > > Gentoo Linux Developer
> > > > > Web: http://hwoarang.silverarrow.org
> > > > 
> > > > -- 
> > > > Alex Alexander -=- wired
> > > > Gentoo Linux Developer -=- Council / Qt / KDE / more
> > > > www.linuxized.com
> > > 
> > > 
> > > 
> > > -- 
> > > Markos Chandras (hwoarang)
> > > Gentoo Linux Developer
> > > Web: http://hwoarang.silverarrow.org
> > > Key ID: 441AC410
> > > Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410
> > 
> > 
> > 
> > -- 
> > Alex Alexander -=- wired
> > Gentoo Linux Developer -=- Council / Qt / KDE / more
> > www.linuxized.com
> 
> 
> 
> -- 
> Markos Chandras (hwoarang)
> Gentoo Linux Developer
> Web: http://hwoarang.silverarrow.org
> Key ID: 441AC410
> Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410



-- 
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com


pgpjSxqLycMhR.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

On Sat, Aug 14, 2010 at 06:26:36PM +0200, Thilo Bangert wrote:
> > So you want me to force everyone to update the package just to respect
> > the LDFLAGS.
> 
> yes. IIRC it has been stated on this list before, that a change which 
> changes the resulting binary always needs to be done in a revbump. 
List? Really? I use devmanual for ebuild development not list archives.
> 
> > Why, since until recently, nobody gave a crap about this
> > kind of QA issues?
> 
> Thats a bad excuse!
Yet it is true. The tree is flood with such packages. So my assumption is
correct. Maintainers didn't and still don't give a crap about this QA issue,
other they wouldn't commit broken packages in the first place
> 
> > 
> > Please provide a patch for devmanual to make it more clear.
> 
> Good idea. Any takers?
> 
> thanks
> kind regards
> 
> Thilo



-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410


pgpQyU6NZZJEv.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

On Sat, Aug 14, 2010 at 07:16:26PM +0300, Alex Alexander wrote:
> On Sat, Aug 14, 2010 at 04:47:39PM +0300, Markos Chandras wrote:
> > On Sat, Aug 14, 2010 at 04:10:13PM +0300, Alex Alexander wrote:
> > > On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote:
> > > > > - If you are not in cc of the gentoo bug nor in the herd alias, 
> > > > > please cc 
> > > > > yourself on the bug.
> > > > > - Please close the bugs, even the dupes (and apply previous point to 
> > > > > the dupes 
> > > > > too).
> > > > > - That way you'll be able to quickly fix (apparently, I didn't check) 
> > > > > obvious 
> > > > > mistakes [1].
> > > > > - You'll have to do a rev. bump for *FLAGS respect, please also check 
> > > > > if you 
> > > > > can avoid it by doing a version bump instead.
> > > > Well not always. If something is on ~testing then I don't think I should
> > > > "spam" the tree with revbumps. Stable users are my first priority so
> > > 
> > > Stable may be more critical, but we support ~testing as well. How do you
> > > expect your changes to be tested before landing on stable if you don't
> > > revbump the packages, allowing them to reach our users?
> > I expect arch testers to do a pretty good testing before they mark them
> > stable. Seems like I am the only one who fixes such issues without revbump.
> > Strange, cvs log must be lying...
> > 
> > Now lets see
> > 
> > http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
> > 
> > "Ebuilds should have their -rX incremented whenever a change is made which 
> > will
> > make a **substantial** difference to what gets installed by the package — by
> > substantial, we generally mean "something for which many users would want to
> > upgrade". This is usually for bugfixes."
> > 
> > Seems like it is up to maintainer's discretion to decide what it is
> > substantial change and what it is not. Many users wont be directly affected 
> > from my changes. It is not like not
> > respect CXX, CXXFLAGS after all.
> > 
> > "Simple compile fixes do not warrant a revision bump; this is because they 
> > do
> > not affect the installed package for users who already managed to compile 
> > it.
> > Small documentation fixes are also usually not grounds for a new revision."
> > 
> > So you want me to force everyone to update the package just to respect the
> > LDFLAGS. Why, since until recently, nobody gave a crap about this kind of QA
> > issues?
> > 
> > 
> > Please provide a patch for devmanual to make it more clear. If it is
> > already clear maybe I am that stupid after all. 
> > 
> > In any case, I will keep doing what I do because you didn't convince me so 
> > far
> > that my changes need a revbump. If arch testers fail to do proper testing
> > thats really *REALLY* not my fault. Testing is testing and I can't do a
> > revbump for every little piece of shit I fix everytime. 
> 
> Does respecting LDFLAGS change the installed files in any way? yes.
> Will users benefit from your change if you don't revbump? No.
> 
> I think that chain of logic is enough to warrant a revbump and it is
> covered by the devmanual since the change affects the installed package.
No it doesn't. If it was that clear we wouldn't debated over this over and
over. The cvs logs and you will see that other devs are fixing the package
without revbump.
> 
> It's merely a cp, why are you making such a fuss about it? You're doing
> a good job already, we're just pointing out ways to make it even better
> 
Cause I don't like users to compile the same damn package over and over. -r1
for docs on ${PF}, -r2 for CFLGAS, -r3 for LDFLAGS, -r4 for ... Is that a good
reason or not? It is not like I introduce huge patches with bugfixes etc. My
fixes are QA fixes not *serious* bugfixes anyway.
Furthermore the QA fixes I do ( CC,CFLAGS,LDFLAGS ) are easily spotted and
there isn't much for users to test anyway. Either you respect the bloody flags
or not. I don't do blindly commits. I try to test the packages in multiple
chroots anyway. 

> :)
> 
> BTW, archs do the final testing, but much testing is done by the users
> themselves, who report the bugs that get fixed before the packages get a
> STABLEREQ bug ;)
Most of these bugs don't come from users but from Diego. Why? Because users
don't bother reading the build.log and see if all their flags are respected or
not. I wouldn't do it either. This 
>  
> > > 
> > > Please, don't skip revbumps to avoid "tree spamming", thats why we have
> > > revbumps in the first place ;)
I am not convinced yet that this kind of QA fixes require a revbump. As I
said, commit an actual patch, assigned to QA and if the rest of the members
agree on that I am willing to change my policy.
> > > 
> > > > unless something is on stable branch, I fix it as it is. I don't want to
> > > > version bump anything because I don't want to mess with anyones
> > > > packages. I only do QA fixing. If you have problem touching your
> > > > packages just say it
> > > > >
> > > > > 

[gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")

[Peter Hjalmarsson]

lör 2010-08-14 klockan 15:14 +0300 skrev Samuli Suominen:
> > [1] Last time I did a bugreport about this, here is the answer:
> > https://bugs.gentoo.org/show_bug.cgi?id=310681
> 
> Long story short:
> 
> If package has SSL support, and use "ssl" is ignored or not present in a
> ebuild. it's plain broken.
> 
> Every ebuild in tree with USE="openssl" is a QA violation, and should be
> fixed asap.
> 
> 

Is there a policy I can point Doug to in the bug referenced as he asks
for it?

[gentoo-dev] Re: Why (i.e. USE="openssl" instead of USE="ssl")

[Peter Hjalmarsson]

lör 2010-08-14 klockan 13:45 +0200 skrev Chí-Thanh Christopher Nguyễn:
> Peter Hjalmarsson schrieb:
> > This is about my beloved USE="ssl". A bit long and ranty, but if you
> > want the consensus, just read the last part.
> >
> >
> > Today a new snapshot of gnash was uploaded where the old USE="ssl" was
> > renamed to USE="openssl".
> >
> > So yet another package where if you want ssl support you have to
> > _personally_ audit what function this useflag has (i.e. does it enable
> > ssl or tune the ssl implementation?).
> >
> > So I wanted to figure it out, does gnash provide ssl itself and the
> > USE="openssl" only tunes how it is implemented or does USE="openssl"
> > enable ssl?
> >
> 
> The USE flag was renamed after discussion with upstream. Gnash does not 
> provide any SSL implementation itself and (when invoked as NPAPI plugin) 
> uses the browser's facilities. Possibly I could make more explicit that 
> users only interested in the plugin don't need it.
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 
> 
> 

Well if that is the use of the use flag the description is to be honest
really bad.

And still, why openssl instead of ssl? Even if most people are out to
only get the plugin the meaning of use flag for the rest of the package
is still the same. So is there a special reson why upstream do want ssl
disabled for people only out to get the plugin (and why not EAPI=1 and
IUSE="-ssl")?

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Thilo Bangert]

> So you want me to force everyone to update the package just to respect
> the LDFLAGS.

yes. IIRC it has been stated on this list before, that a change which 
changes the resulting binary always needs to be done in a revbump. 

> Why, since until recently, nobody gave a crap about this
> kind of QA issues?

Thats a bad excuse!

> 
> Please provide a patch for devmanual to make it more clear.

Good idea. Any takers?

thanks
kind regards

Thilo


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Thilo Bangert]

Richard Freeman  said:
> On 08/14/2010 10:29 AM, Markos Chandras wrote:
> > So do I. Fixing your package and you don't even bother to send a
> > *ready to go* patch upstream seems like a bit rude to me as well.
> > Perhaps, we do have a complete different point of view in this one.
> > Recent example is Chí-Thanh Christopher Nguyễn who thanked me for
> > fixing his package, asked me to attach the patch so *he* can send it
> > upstream. I thought that was the *default* policy. Anyway. I should
> > talk to each maintainer separately when I fix his package. Seems to
> > me is the best approach
> 
> My two cents.  In my opinion, whether a commit is good or not depends
> on whether it left Gentoo as a whole in better or worse shape than
> before it was made.
> 
> Here it sounds like we had QA problems before the commit, and no QA
> problems after the commit.  Maybe the maintainer has some work to do
> now, but he had it to do anyway, and the maintainers have less work to
> do now than they did before the patches were made.
> 
> Now, if he had broken something due to a sloppy commit I'd be more
> concerned.
> 
> Many hands make for lighter work.  The best way to have many hands is
> to make individual tasks easier.  1+1+1+1+1 is going to happen faster
> than 3+2, since nobody ever gets around to doing 3.
> 
> If we give devs an ultimatum like "fix it all or don't fix anything"
> guess which one they'll pick?

exactly. maybe the maintainer has to do some catch up work, but thats ok. 
the aim is to improve the tree and not for QA to do the work of the 
maintainer.

perhaps there is a lesson here though: if the bug isnt closed as soon as 
the patch has hit the tree, but its subject changed to 'push QA patch 
upstream', then it is clear what is left to do.

> 
> Rich



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alex Alexander]

On Sat, Aug 14, 2010 at 04:47:39PM +0300, Markos Chandras wrote:
> On Sat, Aug 14, 2010 at 04:10:13PM +0300, Alex Alexander wrote:
> > On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote:
> > > > - If you are not in cc of the gentoo bug nor in the herd alias, please 
> > > > cc 
> > > > yourself on the bug.
> > > > - Please close the bugs, even the dupes (and apply previous point to 
> > > > the dupes 
> > > > too).
> > > > - That way you'll be able to quickly fix (apparently, I didn't check) 
> > > > obvious 
> > > > mistakes [1].
> > > > - You'll have to do a rev. bump for *FLAGS respect, please also check 
> > > > if you 
> > > > can avoid it by doing a version bump instead.
> > > Well not always. If something is on ~testing then I don't think I should
> > > "spam" the tree with revbumps. Stable users are my first priority so
> > 
> > Stable may be more critical, but we support ~testing as well. How do you
> > expect your changes to be tested before landing on stable if you don't
> > revbump the packages, allowing them to reach our users?
> I expect arch testers to do a pretty good testing before they mark them
> stable. Seems like I am the only one who fixes such issues without revbump.
> Strange, cvs log must be lying...
> 
> Now lets see
> 
> http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
> 
> "Ebuilds should have their -rX incremented whenever a change is made which 
> will
> make a **substantial** difference to what gets installed by the package — by
> substantial, we generally mean "something for which many users would want to
> upgrade". This is usually for bugfixes."
> 
> Seems like it is up to maintainer's discretion to decide what it is
> substantial change and what it is not. Many users wont be directly affected 
> from my changes. It is not like not
> respect CXX, CXXFLAGS after all.
> 
> "Simple compile fixes do not warrant a revision bump; this is because they do
> not affect the installed package for users who already managed to compile it.
> Small documentation fixes are also usually not grounds for a new revision."
> 
> So you want me to force everyone to update the package just to respect the
> LDFLAGS. Why, since until recently, nobody gave a crap about this kind of QA
> issues?
> 
> 
> Please provide a patch for devmanual to make it more clear. If it is
> already clear maybe I am that stupid after all. 
> 
> In any case, I will keep doing what I do because you didn't convince me so far
> that my changes need a revbump. If arch testers fail to do proper testing
> thats really *REALLY* not my fault. Testing is testing and I can't do a
> revbump for every little piece of shit I fix everytime. 

Does respecting LDFLAGS change the installed files in any way? yes.
Will users benefit from your change if you don't revbump? No.

I think that chain of logic is enough to warrant a revbump and it is
covered by the devmanual since the change affects the installed package.

It's merely a cp, why are you making such a fuss about it? You're doing
a good job already, we're just pointing out ways to make it even better

:)

BTW, archs do the final testing, but much testing is done by the users
themselves, who report the bugs that get fixed before the packages get a
STABLEREQ bug ;)
 
> > 
> > Please, don't skip revbumps to avoid "tree spamming", thats why we have
> > revbumps in the first place ;)
> > 
> > > unless something is on stable branch, I fix it as it is. I don't want to
> > > version bump anything because I don't want to mess with anyones
> > > packages. I only do QA fixing. If you have problem touching your
> > > packages just say it
> > > >
> > > > A.
> > > > 
> > > > [1] https://bugs.gentoo.org/show_bug.cgi?id=332523
> > > 
> > > -- 
> > > Markos Chandras (hwoarang)
> > > Gentoo Linux Developer
> > > Web: http://hwoarang.silverarrow.org
> > 
> > -- 
> > Alex Alexander -=- wired
> > Gentoo Linux Developer -=- Council / Qt / KDE / more
> > www.linuxized.com
> 
> 
> 
> -- 
> Markos Chandras (hwoarang)
> Gentoo Linux Developer
> Web: http://hwoarang.silverarrow.org
> Key ID: 441AC410
> Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410



-- 
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com


pgpeRtWlpAORz.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Richard Freeman]

On 08/14/2010 10:29 AM, Markos Chandras wrote:

So do I. Fixing your package and you don't even bother to send a *ready to go* 
patch
upstream seems like a bit rude to me as well. Perhaps, we do have a complete
different point of view in this one.
Recent example is Chí-Thanh Christopher Nguyễn who thanked me for fixing his
package, asked me to attach the patch so *he* can send it upstream. I thought
that was the *default* policy. Anyway. I should talk to each maintainer
separately when I fix his package. Seems to me is the best approach


My two cents.  In my opinion, whether a commit is good or not depends on 
whether it left Gentoo as a whole in better or worse shape than before 
it was made.


Here it sounds like we had QA problems before the commit, and no QA 
problems after the commit.  Maybe the maintainer has some work to do 
now, but he had it to do anyway, and the maintainers have less work to 
do now than they did before the patches were made.


Now, if he had broken something due to a sloppy commit I'd be more 
concerned.


Many hands make for lighter work.  The best way to have many hands is to 
make individual tasks easier.  1+1+1+1+1 is going to happen faster than 
3+2, since nobody ever gets around to doing 3.


If we give devs an ultimatum like "fix it all or don't fix anything" 
guess which one they'll pick?


Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

On Sat, Aug 14, 2010 at 05:20:38PM +0300, Alexis Ballier wrote:
> On Saturday 14 August 2010 17:00:38 Markos Chandras wrote:
> [...]
> > > > > - There is absolutely no reference to any patch sent upstream and I
> > > > > have not seen anything on the upstream dev ml.
> > > > 
> > > > Thats because I didn't. I've fixed more than 40 bug wrt LDFLAGS. Do you
> > > > expect me to subscribe to 40 different ML and send them upstream?
> > > 
> > > you don't need to subscribe, there's usually an AUTHORS file with emails
> > > you can use...
> > 
> > As I said, I thought that maintainers was responsible to do it since they
> > follow all the bug progress after all. So according to you I should do all
> > the work. Tempting
> 
> yes please; I consider not doing it a bit rude as the maintainers will _have_ 
> to clean after you.
So do I. Fixing your package and you don't even bother to send a *ready to go* 
patch
upstream seems like a bit rude to me as well. Perhaps, we do have a complete
different point of view in this one.
Recent example is Chí-Thanh Christopher Nguyễn who thanked me for fixing his
package, asked me to attach the patch so *he* can send it upstream. I thought
that was the *default* policy. Anyway. I should talk to each maintainer
separately when I fix his package. Seems to me is the best approach
>[...] 
> A.
> 

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410


pgpTplps6vV9i.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alexis Ballier]

On Saturday 14 August 2010 17:00:38 Markos Chandras wrote:
[...]
> > > > - There is absolutely no reference to any patch sent upstream and I
> > > > have not seen anything on the upstream dev ml.
> > > 
> > > Thats because I didn't. I've fixed more than 40 bug wrt LDFLAGS. Do you
> > > expect me to subscribe to 40 different ML and send them upstream?
> > 
> > you don't need to subscribe, there's usually an AUTHORS file with emails
> > you can use...
> 
> As I said, I thought that maintainers was responsible to do it since they
> follow all the bug progress after all. So according to you I should do all
> the work. Tempting

yes please; I consider not doing it a bit rude as the maintainers will _have_ 
to clean after you.

> > > The
> > > patch is there, the maintainer is CC on the bug. All he has to do it to
> > > send this damn patch to upstream.
> > 
> > I can use the same reasoning and ask:
> > Why don't you do it in the first place if that's "all" ?
> 
> Cause I cannot maintain all the tree myself

you're confused; contributing to an(other) OSS project (and retaining 
authorship of your patches & improvements) does not have much to do with 
maintaining a package.

[...]
> > > I only do QA fixing. If you have problem touching your
> > > packages just say it
> > 
> > I don't have problems with anyone touching "my" packages (esp. when
> > they're herds packages...); though when I'm not happy with the technical
> > details I let it be known and _really_ appreciate when the comments are
> > taken into account instead of aggressively discarded by trying to argue
> > why it's not been perfect in the first place ;)
> > 
> > A.
> 
> I don't think what I do is perfect. But all this kind of judgement is
> quite demotivated I must say.

Don't be demotivated. The only "judgement" I made is on the technical side and 
not on the global goal; on that side you can just fix it, get thanks & kudos 
and be done :)

A.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

On Sat, Aug 14, 2010 at 04:37:04PM +0300, Alexis Ballier wrote:
> On Saturday 14 August 2010 15:50:53 Markos Chandras wrote:
> > On Sat, Aug 14, 2010 at 03:35:34PM +0300, Alexis Ballier wrote:
> > > On Saturday 07 August 2010 00:21:39 Markos Chandras (hwoarang) wrote:
> > > > hwoarang10/08/06 21:21:39
> > > > 
> > > >   Modified: ChangeLog
> > > >   Added:mlt-0.5.4-r1.ebuild
> > > >   Log:
> > > >   Respect {C,LD}FLAGS when building shared library. Bug #308873
> > > >   (Portage version: 2.2_rc67/cvs/Linux x86_64)
> > > 
> > > While fixing bugs can't be bad and I thank you for doing it, I can see a
> > > couple of important quality problems in this commit:
> > > 
> > > - There is absolutely no reference to any patch sent upstream and I have
> > > not seen anything on the upstream dev ml.
> > 
> > Thats because I didn't. I've fixed more than 40 bug wrt LDFLAGS. Do you
> > expect me to subscribe to 40 different ML and send them upstream? 
> 
> you don't need to subscribe, there's usually an AUTHORS file with emails you 
> can use...
As I said, I thought that maintainers was responsible to do it since they
follow all the bug progress after all. So according to you I should do all the
work. Tempting
> 
> > The
> > patch is there, the maintainer is CC on the bug. All he has to do it to
> > send this damn patch to upstream.
> 
> I can use the same reasoning and ask:
> Why don't you do it in the first place if that's "all" ?
Cause I cannot maintain all the tree myself
> 
> > I only care about the QA status on tree.
> 
> As I already said, that's good, but that's better achieved with long term 
> fixes rather than quick hacks IMHO
> 
> > Most of them just use my patches and
> > contact upstream themselves. If this doesn't apply for you just let me
> > know.
> 
> Yes this doesn't apply to me because the most probable scenario will be this: 
> I'll touch the package in a couple of months/years, do a review of the 
> ebuild/patches, find out some patches need porting, waste time trying to 
> figure out why it's there in the first place, see it's been there for ages 
> and 
> that the author didn't consider the fix good enough to upstream it, drop it.
> 
Sure, the changelogs are there though. I am trying to always write down as many
details as I can so the maintainer can easily track down changes.
> > > - If you are not in cc of the gentoo bug nor in the herd alias, please cc
> > > yourself on the bug.
> > > - Please close the bugs, even the dupes (and apply previous point to the
> > > dupes too).
> > > - That way you'll be able to quickly fix (apparently, I didn't check)
> > > obvious mistakes [1].
> > > - You'll have to do a rev. bump for *FLAGS respect, please also check if
> > > you can avoid it by doing a version bump instead.
> > 
> > Well not always. If something is on ~testing then I don't think I should
> > "spam" the tree with revbumps. Stable users are my first priority so
> > unless something is on stable branch, I fix it as it is. I don't want to
> > version bump anything because I don't want to mess with anyones
> > packages.
> 
> You're messing much more with one's package with quick'n'dirty "fixes" than 
> with a clean version bump with upstreamed patches...
Quick and dirty? Fair enough. Will try to contact upstream from now on. Seems
like I will maintain the entire tree in the end.
> 
> > I only do QA fixing. If you have problem touching your
> > packages just say it
> 
> I don't have problems with anyone touching "my" packages (esp. when they're 
> herds packages...); though when I'm not happy with the technical details I 
> let 
> it be known and _really_ appreciate when the comments are taken into account 
> instead of aggressively discarded by trying to argue why it's not been 
> perfect 
> in the first place ;)
> 
> A.
> 
I don't think what I do is perfect. But all this kind of judgement is
quite demotivated I must say.

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410


pgpHlH84uLr9R.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

On Sat, Aug 14, 2010 at 04:10:13PM +0300, Alex Alexander wrote:
> On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote:
> > > - If you are not in cc of the gentoo bug nor in the herd alias, please cc 
> > > yourself on the bug.
> > > - Please close the bugs, even the dupes (and apply previous point to the 
> > > dupes 
> > > too).
> > > - That way you'll be able to quickly fix (apparently, I didn't check) 
> > > obvious 
> > > mistakes [1].
> > > - You'll have to do a rev. bump for *FLAGS respect, please also check if 
> > > you 
> > > can avoid it by doing a version bump instead.
> > Well not always. If something is on ~testing then I don't think I should
> > "spam" the tree with revbumps. Stable users are my first priority so
> 
> Stable may be more critical, but we support ~testing as well. How do you
> expect your changes to be tested before landing on stable if you don't
> revbump the packages, allowing them to reach our users?
I expect arch testers to do a pretty good testing before they mark them
stable. Seems like I am the only one who fixes such issues without revbump.
Strange, cvs log must be lying...

Now lets see

http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html

"Ebuilds should have their -rX incremented whenever a change is made which will
make a **substantial** difference to what gets installed by the package — by
substantial, we generally mean "something for which many users would want to
upgrade". This is usually for bugfixes."

Seems like it is up to maintainer's discretion to decide what it is
substantial change and what it is not. Many users wont be directly affected 
from my changes. It is not like not
respect CXX, CXXFLAGS after all.

"Simple compile fixes do not warrant a revision bump; this is because they do
not affect the installed package for users who already managed to compile it.
Small documentation fixes are also usually not grounds for a new revision."

So you want me to force everyone to update the package just to respect the
LDFLAGS. Why, since until recently, nobody gave a crap about this kind of QA
issues?


Please provide a patch for devmanual to make it more clear. If it is
already clear maybe I am that stupid after all. 

In any case, I will keep doing what I do because you didn't convince me so far
that my changes need a revbump. If arch testers fail to do proper testing
thats really *REALLY* not my fault. Testing is testing and I can't do a
revbump for every little piece of shit I fix everytime. 

> 
> Please, don't skip revbumps to avoid "tree spamming", thats why we have
> revbumps in the first place ;)
> 
> > unless something is on stable branch, I fix it as it is. I don't want to
> > version bump anything because I don't want to mess with anyones
> > packages. I only do QA fixing. If you have problem touching your
> > packages just say it
> > >
> > > A.
> > > 
> > > [1] https://bugs.gentoo.org/show_bug.cgi?id=332523
> > 
> > -- 
> > Markos Chandras (hwoarang)
> > Gentoo Linux Developer
> > Web: http://hwoarang.silverarrow.org
> 
> -- 
> Alex Alexander -=- wired
> Gentoo Linux Developer -=- Council / Qt / KDE / more
> www.linuxized.com



-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410


pgpQqJyitMeKu.pgp
Description: PGP signature

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alexis Ballier]

On Saturday 14 August 2010 15:50:53 Markos Chandras wrote:
> On Sat, Aug 14, 2010 at 03:35:34PM +0300, Alexis Ballier wrote:
> > On Saturday 07 August 2010 00:21:39 Markos Chandras (hwoarang) wrote:
> > > hwoarang10/08/06 21:21:39
> > > 
> > >   Modified: ChangeLog
> > >   Added:mlt-0.5.4-r1.ebuild
> > >   Log:
> > >   Respect {C,LD}FLAGS when building shared library. Bug #308873
> > >   (Portage version: 2.2_rc67/cvs/Linux x86_64)
> > 
> > While fixing bugs can't be bad and I thank you for doing it, I can see a
> > couple of important quality problems in this commit:
> > 
> > - There is absolutely no reference to any patch sent upstream and I have
> > not seen anything on the upstream dev ml.
> 
> Thats because I didn't. I've fixed more than 40 bug wrt LDFLAGS. Do you
> expect me to subscribe to 40 different ML and send them upstream? 

you don't need to subscribe, there's usually an AUTHORS file with emails you 
can use...

> The
> patch is there, the maintainer is CC on the bug. All he has to do it to
> send this damn patch to upstream.

I can use the same reasoning and ask:
Why don't you do it in the first place if that's "all" ?

> I only care about the QA status on tree.

As I already said, that's good, but that's better achieved with long term 
fixes rather than quick hacks IMHO

> Most of them just use my patches and
> contact upstream themselves. If this doesn't apply for you just let me
> know.

Yes this doesn't apply to me because the most probable scenario will be this: 
I'll touch the package in a couple of months/years, do a review of the 
ebuild/patches, find out some patches need porting, waste time trying to 
figure out why it's there in the first place, see it's been there for ages and 
that the author didn't consider the fix good enough to upstream it, drop it.

> > - If you are not in cc of the gentoo bug nor in the herd alias, please cc
> > yourself on the bug.
> > - Please close the bugs, even the dupes (and apply previous point to the
> > dupes too).
> > - That way you'll be able to quickly fix (apparently, I didn't check)
> > obvious mistakes [1].
> > - You'll have to do a rev. bump for *FLAGS respect, please also check if
> > you can avoid it by doing a version bump instead.
> 
> Well not always. If something is on ~testing then I don't think I should
> "spam" the tree with revbumps. Stable users are my first priority so
> unless something is on stable branch, I fix it as it is. I don't want to
> version bump anything because I don't want to mess with anyones
> packages.

You're messing much more with one's package with quick'n'dirty "fixes" than 
with a clean version bump with upstreamed patches...

> I only do QA fixing. If you have problem touching your
> packages just say it

I don't have problems with anyone touching "my" packages (esp. when they're 
herds packages...); though when I'm not happy with the technical details I let 
it be known and _really_ appreciate when the comments are taken into account 
instead of aggressively discarded by trying to argue why it's not been perfect 
in the first place ;)

A.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alex Alexander]

On Sat, Aug 14, 2010 at 03:50:53PM +0300, Markos Chandras wrote:
> > - If you are not in cc of the gentoo bug nor in the herd alias, please cc 
> > yourself on the bug.
> > - Please close the bugs, even the dupes (and apply previous point to the 
> > dupes 
> > too).
> > - That way you'll be able to quickly fix (apparently, I didn't check) 
> > obvious 
> > mistakes [1].
> > - You'll have to do a rev. bump for *FLAGS respect, please also check if 
> > you 
> > can avoid it by doing a version bump instead.
> Well not always. If something is on ~testing then I don't think I should
> "spam" the tree with revbumps. Stable users are my first priority so

Stable may be more critical, but we support ~testing as well. How do you
expect your changes to be tested before landing on stable if you don't
revbump the packages, allowing them to reach our users?

Please, don't skip revbumps to avoid "tree spamming", thats why we have
revbumps in the first place ;)

> unless something is on stable branch, I fix it as it is. I don't want to
> version bump anything because I don't want to mess with anyones
> packages. I only do QA fixing. If you have problem touching your
> packages just say it
> >
> > A.
> > 
> > [1] https://bugs.gentoo.org/show_bug.cgi?id=332523
> 
> -- 
> Markos Chandras (hwoarang)
> Gentoo Linux Developer
> Web: http://hwoarang.silverarrow.org

-- 
Alex Alexander -=- wired
Gentoo Linux Developer -=- Council / Qt / KDE / more
www.linuxized.com


pgpmeRTNX8JRb.pgp
Description: PGP signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Markos Chandras]

On Sat, Aug 14, 2010 at 03:35:34PM +0300, Alexis Ballier wrote:
> On Saturday 07 August 2010 00:21:39 Markos Chandras (hwoarang) wrote:
> > hwoarang10/08/06 21:21:39
> > 
> >   Modified: ChangeLog
> >   Added:mlt-0.5.4-r1.ebuild
> >   Log:
> >   Respect {C,LD}FLAGS when building shared library. Bug #308873
> >   (Portage version: 2.2_rc67/cvs/Linux x86_64)
> 
> While fixing bugs can't be bad and I thank you for doing it, I can see a 
> couple of important quality problems in this commit:
> 
> - There is absolutely no reference to any patch sent upstream and I have not 
> seen anything on the upstream dev ml.
Thats because I didn't. I've fixed more than 40 bug wrt LDFLAGS. Do you
expect me to subscribe to 40 different ML and send them upstream? The
patch is there, the maintainer is CC on the bug. All he has to do it to
send this damn patch to upstream. I only care
about the QA status on tree. Most of them just use my patches and
contact upstream themselves. If this doesn't apply for you just let me
know.
> - If you are not in cc of the gentoo bug nor in the herd alias, please cc 
> yourself on the bug.
> - Please close the bugs, even the dupes (and apply previous point to the 
> dupes 
> too).
> - That way you'll be able to quickly fix (apparently, I didn't check) obvious 
> mistakes [1].
> - You'll have to do a rev. bump for *FLAGS respect, please also check if you 
> can avoid it by doing a version bump instead.
Well not always. If something is on ~testing then I don't think I should
"spam" the tree with revbumps. Stable users are my first priority so
unless something is on stable branch, I fix it as it is. I don't want to
version bump anything because I don't want to mess with anyones
packages. I only do QA fixing. If you have problem touching your
packages just say it
> 
> 
> A.
> 
> 
> 
> [1] https://bugs.gentoo.org/show_bug.cgi?id=332523

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org


pgpU75OWlzyEv.pgp
Description: PGP signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild

[Alexis Ballier]

On Saturday 07 August 2010 00:21:39 Markos Chandras (hwoarang) wrote:
> hwoarang10/08/06 21:21:39
> 
>   Modified: ChangeLog
>   Added:mlt-0.5.4-r1.ebuild
>   Log:
>   Respect {C,LD}FLAGS when building shared library. Bug #308873
>   (Portage version: 2.2_rc67/cvs/Linux x86_64)

While fixing bugs can't be bad and I thank you for doing it, I can see a 
couple of important quality problems in this commit:

- There is absolutely no reference to any patch sent upstream and I have not 
seen anything on the upstream dev ml.
- If you are not in cc of the gentoo bug nor in the herd alias, please cc 
yourself on the bug.
- Please close the bugs, even the dupes (and apply previous point to the dupes 
too).
- That way you'll be able to quickly fix (apparently, I didn't check) obvious 
mistakes [1].
- You'll have to do a rev. bump for *FLAGS respect, please also check if you 
can avoid it by doing a version bump instead.


A.



[1] https://bugs.gentoo.org/show_bug.cgi?id=332523

Re: [gentoo-dev] Why (i.e. USE="openssl" instead of USE="ssl")

[Samuli Suominen]

On 08/14/2010 02:26 PM, Peter Hjalmarsson wrote:
> This is about my beloved USE="ssl". A bit long and ranty, but if you
> want the consensus, just read the last part.
> 
> 
> Today a new snapshot of gnash was uploaded where the old USE="ssl" was
> renamed to USE="openssl".
> 
> So yet another package where if you want ssl support you have to
> _personally_ audit what function this useflag has (i.e. does it enable
> ssl or tune the ssl implementation?).
> 
> So I wanted to figure it out, does gnash provide ssl itself and the
> USE="openssl" only tunes how it is implemented or does USE="openssl"
> enable ssl?
> 
> So what does the flag really do? Their local description does not say
> very much:
> local:openssl:www-plugins/gnash: Enable directly using OpenSSL
> 
> What is even "enabled directly"? Still not much smarter.
> Unpacking the source and looking in ./configure --help and the strange
> description for the use flag gets an explanation:
> --enable-sslEnable using OpenSSL directly
> 
> Still not much smarter...
> 
> Looking inside configure.ac makes me smarter tho:
> 
> dnl Enable using OpenSSL with libnet.
> AC_ARG_ENABLE(ssl,
>   AC_HELP_STRING([--enable-ssl], [Enable using OpenSSL directly]),
> [case "${enableval}" in
>   yes) build_ssl=yes ;;
>   no)  build_ssl=no ;;
>   *)   AC_MSG_ERROR([bad value ${enableval} for --enable-ssl option]) ;;
> esac], build_ssl=no)
> 
> So apparently it seems the flag enables ssl support using openssl.
> 
> No, I did not review the source to make sure that build_ssl does really
> build ssl, but do I really have to to find out what a USE-flag does?
> 
> Personally I would still like the description for the useflag to really
> describe the flag, like:
> global:ssl: Adds support for Secure Socket Layer connections
> 
> (and thus in this case the use flag to still be USE="ssl")
> 
> 
> 
> And why I post here instead of making a bug is to try to start a
> discussion that is still not finished[1]:
> What function should useflags bring?
> 
> There are some packages (like networkmanager) that does not have a ssl
> flag (it is always enabled), and the gnutls/nss useflags are used to
> fine tune what implementation to use. If non selected the upstream
> preferred (nss) is chosen.
> 
> Then there are some packages (like qemu) where there is only one flag
> (USE="gnutls") that enables support for encrypten vnc.
> 
> Then there are packages like curl where the local description of
> USE="ssl" says it all:
> local:ssl:net-misc/curl: Enable crypto engine support (via openssl if
> USE='-gnutls -nss')
> 
> 
> 
> 
> 
> So as a user, if I want to have Secure Socket Layer or Transport Layer
> Security, do I really need to learn the name of every implementation
> known to man and enable their respective use flag to ensure that my
> whole system has support for it, or should I just have to enable
> USE="ssl"?
> And will I still be sure that those use flag did not disable a (maybe
> superior or by maintainer preferred) internal ssl implementation?
> 
> 
> [1] Last time I did a bugreport about this, here is the answer:
> https://bugs.gentoo.org/show_bug.cgi?id=310681

Long story short:

If package has SSL support, and use "ssl" is ignored or not present in a
ebuild. it's plain broken.

Every ebuild in tree with USE="openssl" is a QA violation, and should be
fixed asap.

Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS

[Markos Chandras]

On Sat, Aug 14, 2010 at 02:40:40AM -0400, Mike Frysinger wrote:
> On Sat, Aug 14, 2010 at 2:41 AM, Ryan Hill wrote:
> > On Sat, 14 Aug 2010 00:14:28 -0400 Mike Frysinger wrote:
> >> that's crap.  fix the package or at least work around it:
> >> LDFLAGS=`echo ${LDFLAGS}`
> >>
> >> we shouldnt be forced to add random hacks throughout the tree because
> >> of one or two random broken packages
> >
> > Yes, I meant don't commit it until someone fixes boost-build.  I just did so
> > go ahead.
> 
> sorry, i thought you meant that we should block the profile change 
> indefinitely
> -mike
> 
Now this doesn't seem to work


~$ cat 
development/gentoo-cvs/gentoo-x86/profiles/default/linux/amd64/dev/make.defaults

LDFLAGS="${LDFLAGS} -Wl,--hash-style=gnu"

~$  eselect profile list
Available profile symlink targets:
[1]   default/linux/amd64/10.0
[2]   default/linux/amd64/10.0/desktop
[3]   default/linux/amd64/10.0/desktop/gnome
[4]   default/linux/amd64/10.0/desktop/kde
[5]   default/linux/amd64/10.0/developer *

* simple compile output *
x86_64-pc-linux-gnu-g++ -O2 -march=native -pipe -Wall -ggdb -Wl,-O1
-Wl,--as-needed  -c -D_GNU_SOURCE   debugTracer.cpp

However if I add the new make.defaults to default/linux/amd64/10.0/developer
it works as expected

Are you sure that default/linux/amd64/dev/ is the correct place to touch?
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
Key ID: 441AC410
Key FP: AAD0 8591 E3CD 445D 6411 3477 F7F7 1E8E 441A C410


pgpIgEJudQL36.pgp
Description: PGP signature

Re: [gentoo-dev] Why (i.e. USE="openssl" instead of USE="ssl")

[Chí-Thanh Christopher Nguyễn]

Peter Hjalmarsson schrieb:

This is about my beloved USE="ssl". A bit long and ranty, but if you
want the consensus, just read the last part.


Today a new snapshot of gnash was uploaded where the old USE="ssl" was
renamed to USE="openssl".

So yet another package where if you want ssl support you have to
_personally_ audit what function this useflag has (i.e. does it enable
ssl or tune the ssl implementation?).

So I wanted to figure it out, does gnash provide ssl itself and the
USE="openssl" only tunes how it is implemented or does USE="openssl"
enable ssl?
   


The USE flag was renamed after discussion with upstream. Gnash does not 
provide any SSL implementation itself and (when invoked as NPAPI plugin) 
uses the browser's facilities. Possibly I could make more explicit that 
users only interested in the plugin don't need it.



Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] Why (i.e. USE="openssl" instead of USE="ssl")

[Peter Hjalmarsson]

This is about my beloved USE="ssl". A bit long and ranty, but if you
want the consensus, just read the last part.


Today a new snapshot of gnash was uploaded where the old USE="ssl" was
renamed to USE="openssl".

So yet another package where if you want ssl support you have to
_personally_ audit what function this useflag has (i.e. does it enable
ssl or tune the ssl implementation?).

So I wanted to figure it out, does gnash provide ssl itself and the
USE="openssl" only tunes how it is implemented or does USE="openssl"
enable ssl?

So what does the flag really do? Their local description does not say
very much:
local:openssl:www-plugins/gnash: Enable directly using OpenSSL

What is even "enabled directly"? Still not much smarter.
Unpacking the source and looking in ./configure --help and the strange
description for the use flag gets an explanation:
--enable-sslEnable using OpenSSL directly

Still not much smarter...

Looking inside configure.ac makes me smarter tho:

dnl Enable using OpenSSL with libnet.
AC_ARG_ENABLE(ssl,
  AC_HELP_STRING([--enable-ssl], [Enable using OpenSSL directly]),
[case "${enableval}" in
  yes) build_ssl=yes ;;
  no)  build_ssl=no ;;
  *)   AC_MSG_ERROR([bad value ${enableval} for --enable-ssl option]) ;;
esac], build_ssl=no)

So apparently it seems the flag enables ssl support using openssl.

No, I did not review the source to make sure that build_ssl does really
build ssl, but do I really have to to find out what a USE-flag does?

Personally I would still like the description for the useflag to really
describe the flag, like:
global:ssl: Adds support for Secure Socket Layer connections

(and thus in this case the use flag to still be USE="ssl")



And why I post here instead of making a bug is to try to start a
discussion that is still not finished[1]:
What function should useflags bring?

There are some packages (like networkmanager) that does not have a ssl
flag (it is always enabled), and the gnutls/nss useflags are used to
fine tune what implementation to use. If non selected the upstream
preferred (nss) is chosen.

Then there are some packages (like qemu) where there is only one flag
(USE="gnutls") that enables support for encrypten vnc.

Then there are packages like curl where the local description of
USE="ssl" says it all:
local:ssl:net-misc/curl: Enable crypto engine support (via openssl if
USE='-gnutls -nss')





So as a user, if I want to have Secure Socket Layer or Transport Layer
Security, do I really need to learn the name of every implementation
known to man and enable their respective use flag to ensure that my
whole system has support for it, or should I just have to enable
USE="ssl"?
And will I still be sure that those use flag did not disable a (maybe
superior or by maintainer preferred) internal ssl implementation?


[1] Last time I did a bugreport about this, here is the answer:
https://bugs.gentoo.org/show_bug.cgi?id=310681


Regards
Peter Hjalmarsson

Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS

[Markos Chandras]

On Fri, Aug 13, 2010 at 09:50:10PM -0600, Ryan Hill wrote:
> On Fri, 13 Aug 2010 21:43:35 -0600
> Ryan Hill  wrote:
> 
> 
> > The thing is, you can't right now. :D  LDFLAGS don't stack, meaning you'd
> > have to do something like
> > 
> > --- targets/developer/make.defaults 26 Jul 2010 19:15:05 -  1.9
> > +++ targets/developer/make.defaults 14 Aug 2010 03:31:18 -
> > @@ -12,3 +12,6 @@
> >  
> >  # Log eqawarn messages
> >  PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa"
> > +
> > +# Help find packages not respecting LDFLAGS
> > +LDFLAGS="-Wl,--hash-style=gnu ${LDFLAGS}"
> > 
> 
> Oops, I guess that should be default/linux/amd64/dev/make.defaults.
> 
> 
> -- 
> fonts, gcc-porting,   and it's all by design
> toolchain, wxwidgetsto keep us from losing our minds
> @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Yeah it should be a new make.defaults file under
/default/linux/amd64/dev/ folder. I will apply it locally and if that
works I will push it later this day

Thank you both

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org


pgpmH1v3BVJAw.pgp
Description: PGP signature