[gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Sat, 14 Aug 2010 00:14:28 -0400
Mike Frysinger vap...@gentoo.org 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.
--
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
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
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
On Fri, Aug 13, 2010 at 09:50:10PM -0600, Ryan Hill wrote:
On Fri, 13 Aug 2010 21:43:35 -0600
Ryan Hill dirtye...@gentoo.org 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
[gentoo-dev] Why (i.e. USE=openssl instead of USE=ssl)
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] Why (i.e. USE=openssl instead of USE=ssl)
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
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
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)
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.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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
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
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
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
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
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
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 ri...@gentoo.org 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
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.
[gentoo-dev] Re: Why (i.e. USE=openssl instead of USE=ssl)
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)?
[gentoo-dev] Re: Why (i.e. USE=openssl instead of USE=ssl)
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?
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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
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
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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
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
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 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
pgpLxpDP8Uwvg.pgp
Description:
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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
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: Add --hash-style=gnu to LDFLAGS
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: Add --hash-style=gnu to LDFLAGS
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
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
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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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
Re: [gentoo-dev] keepdir /var/run/package/?
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? http://sources.gentoo.org/cgi-bin/viewvc.cgi/baselayout/branches/baselayout-1_12/bin/checkpath?view=log Ulrich
Re: [gentoo-dev] Re: Add --hash-style=gnu to LDFLAGS
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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, 14 Aug 2010 19:35:56 +0200 Harald van Dijk true...@gentoo.org 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
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, 14 Aug 2010 17:00:38 +0300 Markos Chandras hwoar...@gentoo.org 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
Re: [gentoo-dev] keepdir /var/run/package/?
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? http://sources.gentoo.org/cgi-bin/viewvc.cgi/baselayout/branches/baselayout-1_12/bin/checkpath?view=log clearly i cant remember anything anymore. checkpath is indeed in stable baselayout. -mike
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On Sat, Aug 14, 2010 at 02:46:21PM -0600, Ryan Hill wrote: On Sat, 14 Aug 2010 17:00:38 +0300 Markos Chandras hwoar...@gentoo.org 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] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
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 :-) :-)
[gentoo-dev] glibc-2.12 in ~arch
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
