Re: [gentoo-dev] Regarding the tinderbox logs
On Wed, Oct 3, 2012 at 3:35 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 02/10/2012 21:14, Ryan Hill wrote: Well, duh. You designed, developed, and are the sole architect of the system. Not by choice... You made an error in the design. You might have had good reasons at the time, and you can argue them til you turn blue to anyone who will listen, but if your end consumers see it as a flaw it isn't going to change a thing. Here's the problem, it's the 80-20 rule. Just in this case reversed, in the sense that 80% of the noise comes from 20% of the people (and I'd argue even less than 20%). We have a system that works nicely, and most people don't even complain about it. A few asked why, and when they were told they said ok. A couple complained that it's not as easy but kept going and _one_ is destructively removing references to the logs and ignoring valid bugs on his own packages (caused by his own packages most of the time), because they smell. It does seem logical that I'm not going to rollback months of work just because one guy can't be bothered to play well with others, doesn't it? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ Nobody asked you to rollback months of work just because a few people can't deal with the way you submit your logs. But you should also respect their preferences. Each one of us has its personal way of dealing with his/her bugs (based on some loose standards and policies). If someone doesn't like your way of submitting logs then just accept it. It is not like they go and remove your tinderbox links from bugs/packages they don't maintain. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Regarding the tinderbox logs
Nobody asked you to rollback months of work just because a few people can't deal with the way you submit your logs. Actually somebody did, suggesting I shouldn't file bugs until the log's attached. And then proceeded to suggest that converting everything to python and using pybugz is a cakewalk (obviosuly without offering to even start the work). But you should also respect their preferences. Each one of us has its personal way of dealing with his/her bugs (based on some loose standards and policies). Sure. Preferences are great. Until said preferences mean that bugs that _are_ 100% valid get closed, repeatedly, without being looked at. Let's make an example. In the recent past, an update to binutils broke some of the libbfd (the library coming with it) users as headers were changed around. How many copies of the same bug do you think one has to file before policies should overrule preferences? (and this is not a matter of just refusing the log, it's refusing the _bug_ which is extremely easy to reproduce). If someone doesn't like your way of submitting logs then just accept it. It is not like they go and remove your tinderbox links from bugs/packages they don't maintain. Actually, that happened as well. Maybe you should actually review facts before posting sure that you know that's going on. Just saying. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Regarding the tinderbox logs
On Wed, Oct 10, 2012 at 10:41 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: Sure. Preferences are great. Until said preferences mean that bugs that _are_ 100% valid get closed, repeatedly, without being looked at. I can't speak to the specifics of whatever the elephant in the room is, but keep in mind that when you have 100 developers on a project there is only so much you can tailor things to individual preferences. I've gotten tinderbox bugs that are upstream issues that I personally accept as valid but which I'll probably never be able to influence upstream to change. I just read them, appreciate them, and then leave them open in the hope that I'll be bored one weekend and find some way to fix it. Usually I find Diego's bugs to be helpfully worded both with helpful logs and background info which saves me having to explore some arcane linking issue. If the result of a tinderbox run is we get 500 bugs that are legit, 3 false positives that waste somebody's time, and 5 legit but debate-ably unimportant bugs that particular maintainers don't want to look at, I'd say we came out ahead. This could be a culture thing. At work I tend to work with large regulated applications that often have hundreds of open bugs at any time - some for years with no intention whatsoever to actually close them. Bug lists aren't really used like worklists in this context, except for the few times a year everybody sits down and prioritizes the list and figures out what is worth fixing, if anything. So, having a few open bugs assigned to me doesn't really bother me. Maybe the solution is some kind of maintainer priority field for personal productivity which is to be set by maintainers only and can be filtered on if a maintainer just doesn't like seeing things in their daily view. Rich
Re: [gentoo-dev] Regarding the tinderbox logs
On Wed, Oct 10, 2012 at 3:41 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: Actually, that happened as well. Maybe you should actually review facts before posting sure that you know that's going on. Just saying. Ok -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
El dom, 07-10-2012 a las 08:55 +0200, Pacho Ramos escribió: El dom, 07-10-2012 a las 12:08 +0800, Ben de Groot escribió: On 7 October 2012 04:37, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Pacho Ramos schrieb: Hello I am noticing for a long time that bugs related with ekiga, opal, yate... are completely unattended by voip team for years. If nobody from that team is willing to maintain them, please move them to maintainer-needed to, at least, reflect reality. The members of the voip team are usually interested in a few specific packages only. Many of the packages which have become unmaintained had a maintainer once, but these were retired from Gentoo at some point. The package was then left with the herd. Nobody in the herd was interested to maintain them but nobody was sufficiently motivated to speak out against this either. Does voip herd belong to any project, is there a leader? Can you guys get together and decide who is doing what? And then remove inactive devs from the herd, and put unmaintained packages up for grabs / assign to maintainer-needed? That would make things more transparent and maybe get some movement in open bugs. Yes, that would be the right thing to do as now there are a lot of packages that are like in a limbo Any news here? I can move that packages to maintainer-needed if you send me the list of packages you don't want to maintain. Also, maybe telepathy stuff could be moved to its own herd (that is basically gnome team + tester... or maybe tester could join gnome team ;)) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
Pacho Ramos schrieb: I am noticing for a long time that bugs related with ekiga, opal, yate... are completely unattended by voip team for years. If nobody from that team is willing to maintain them, please move them to maintainer-needed to, at least, reflect reality. Any news here? I can move that packages to maintainer-needed if you send me the list of packages you don't want to maintain. Also, maybe telepathy stuff could be moved to its own herd (that is basically gnome team + tester... or maybe tester could join gnome team ;)) There is now one proxy maintainer for a couple of packages, he is currently waiting for voip overlay access in bug 437538. He will take care of linphone and related packages (see bug 399735 and its dependencies). Regarding the packages that can be moved to maintainer-needed: I think a good heuristic is if the package has several open bugs with no maintainer reaction, and hasn't been touched by anyone from voip herd in over a year. This would include the ekiga, opal and yate packages mentioned above. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: About unresolved bugs assigned to voip for ages
On Wed, Oct 10, 2012 at 5:53 PM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Pacho Ramos schrieb: I am noticing for a long time that bugs related with ekiga, opal, yate... are completely unattended by voip team for years. If nobody from that team is willing to maintain them, please move them to maintainer-needed to, at least, reflect reality. Any news here? I can move that packages to maintainer-needed if you send me the list of packages you don't want to maintain. Also, maybe telepathy stuff could be moved to its own herd (that is basically gnome team + tester... or maybe tester could join gnome team ;)) There is now one proxy maintainer for a couple of packages, he is currently waiting for voip overlay access in bug 437538. He will take care of linphone and related packages (see bug 399735 and its dependencies). Regarding the packages that can be moved to maintainer-needed: I think a good heuristic is if the package has several open bugs with no maintainer reaction, and hasn't been touched by anyone from voip herd in over a year. This would include the ekiga, opal and yate packages mentioned above. I'd gladly take maintainership of opal and ekiga, if nobody wants them. Cheers, -- Jesus Rivero (Neurogeek) Gentoo Developer
Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath
On 10/6/2012 1:31 AM, Fabian Groffen wrote:
On 06-10-2012 00:47:57 -0700, Gregory M. Turner wrote:
In dev-lang/python*, we use
append-ldflags '-L.'
to ensure linking is performed against the built libpython.so in-tree,
rather than than in the one in $(libdir). But, this doesn't work if
LDFLAGS contains -L$(libdir).
We could try to fix this like:
export LDFLAGS=-L. ${LDFLAGS}
or so. That would cover 99.9% of the cases out there. But very rarely,
indiscriminately placing our '-L.' before every other clause in LDFLAGS
might cause an unanticipated side-effect.
I think it would make more sense in this case to just add one more patch
to Python, such that the build-system just inserts it. I recall it's
necessary at least on FreeBSD, Darwin, Solaris, but I don't recall any
more why it works/worked on Linux fine.
I was thinking along these lines as well. As it turned out, however, I
was not able to find an automagical, PMS-compliant, non-crazy way to do
it that resolved my test-case (more on that below), without effectively
hooking econf().
Literally hooking a core API seems like a Pandora's box better left
unopened, so this is what I came up with (note: the fpectl stuff was
also in my overlay and the patches got entangled -- rather than editing
the hunk by hand, I just left it. It's orthogonal to this issue,
however, and for present purposes can be ignored):
--8-
--- PORTAGE/dev-lang/python/python-2.7.3-r2.ebuild
+++ OVERLAY/dev-lang/python/python-2.7.3-r2.ebuild
@@ -218,13 +255,6 @@
# http://bugs.python.org/issue15506
export ac_cv_path_PKG_CONFIG=$(tc-getPKG_CONFIG)
- # Set LDFLAGS so we link modules with -lpython2.7 correctly.
- # Needed on FreeBSD unless Python 2.7 is already installed.
- # Please query BSD team before removing this!
- # On AIX this is not needed, but would record '.' as runpath.
- [[ ${CHOST} == *-aix* ]] ||
- append-ldflags -L.
-
local dbmliborder
if use gdbm; then
dbmliborder+=${dbmliborder:+:}gdbm
@@ -248,11 +278,18 @@
myconf=${myconf} --enable-framework=${EPREFIX}/usr/lib \
|| myconf=${myconf} --enable-shared
+ if [[ ${CHOST} == *-cygwin* ]] ; then
+ fpeconfig=--without-fpectl
+ myconf=${myconf} ac_cv_func_bind_textdomain_codeset=yes
+ else
+ fpeconfig=--with-fpectl
+ fi
+
# note: for a framework build we need to use ucs2 because OSX
# uses that internally too:
# http://bugs.python.org/issue763708
- OPT= econf \
- --with-fpectl \
+ OPT= cpython_econf \
+ ${fpeconfig} \
$(use_enable ipv6) \
$(use_with threads) \
$( (use wide-unicode use !aqua) echo --enable-unicode=ucs4
|| echo --enable-unicode=ucs2) \
--- PORTAGE/eclass/python.eclass
+++ OVERLAY/eclass/python.eclass
@@ -401,6 +401,64 @@
fi
}
+# see http://thread.gmane.org/gmane.linux.gentoo.devel/80633/focus=80635
+_python_prepend_cwd_ldpath() {
+ local new=()
+ local f
+ local done=no
+ for f in ${LDFLAGS} ; do
+ case ${f} in
+ -Tbss=*|-Tdata=*|-Ttext=*|-Ttext-segment=*)
+ new+=( ${f} )
+ ;;
+ -L*|-T*|--library-path*|--script*)
+ if [[ ${done} == yes ]] ; then
+ new+=( ${f} )
+ elif [[ ${f} == -L. ]] ; then
+ # if it's somehow already there, don't
duplicate it
+ new+=( -L. )
+ done=yes
+ else
+ new+=( -L. ${f} )
+ done=yes
+ fi
+ ;;
+ *)
+ new+=( ${f} )
+ ;;
+ esac
+ done
+ [[ ${done} == no ]] new+=( -L. )
+ export LDFLAGS=${new[*]}
+}
+
+# @FUNCTION: cpython_econf
+# @DESCRIPTION:
+# econf() substitute for use in dev-lang/python ebuilds
+#
+# On some platforms, it is neccesary to prepend -L. to ldpath before
+# proceeding with python's configure process. Using cpython_econf()
+# instead of econf() will ensure that this is taken care of correctly
+# before python's configure step can proceed. This is not needed for
+# any python ebuilds other than dev-lang/python; any other ebuild
+# calling this function will receive an error.
+cpython_econf() {
+ if [[ ${CATEGORY}/${PN} != dev-lang/python ]] ; then
+ die cpython_econf can only be used by dev-lang/python ebuilds
+ fi
+ # econf will enforce ${EBUILD_PHASE} requirements, so we don't bother.
+
+
Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath
On Wednesday 10 October 2012 18:47:46 Gregory M. Turner wrote:
+ if [[ ${CHOST} == *-cygwin* ]] ; then
+ fpeconfig=--without-fpectl
just re-use myconf. this is what it's for.
+ myconf=${myconf} ac_cv_func_bind_textdomain_codeset=yes
just export it:
export ac_cv_func_bind_textdomain_codeset=yes
As for cpython_econf -- is it OK that it doesn't begin with python?
Or should it perhaps be python_cpython_econf?
i think it's all a giant hack for a problem i have yet to see described where
the user wasn't doing something wrong. it's one thing to add LDFLAGS=-L.
${LDFLAGS} to support their dumbness, but it's a completely different ballgame
to write an entire flag parser (which i'm going to assume isn't even really
necessary or covers all possible angles).
another alternative is to modify the python build system so that it uses the
full path to the library directly rather than searching for it via -L ...
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath
On 10/9/2012 2:26 PM, Mike Frysinger wrote:
On Saturday 06 October 2012 03:47:57 Gregory M. Turner wrote:
My god, I am a horrible self-editor. Sorry. Please ignore the magnum
opus above and allow me to try again.
In dev-lang/python*, we use
append-ldflags '-L.'
to ensure linking is performed against the built libpython.so in-tree,
rather than than in the one in $(libdir). But, this doesn't work if
LDFLAGS contains -L$(libdir).
well, some notes here ...
for users: putting -Lsome-system-path is wrong. it changes the meaning of
system paths when it comes to searching for linking by elevating it to user
specified path. imo, you should be fixing the source rather than the symptom.
for packagers: using -L$(libdir) is almost always wrong and pointless. the
toolchain itself knows the proper system path to search for libraries to link
against, and when you cross-compile, the --libdir you specify to configure is
not going to be valid when dereferenced on the build system.
Agreed on these points. Not until we combine the doubly broken
circumstances of (1) User specified -L/usr/$(libdir) in LDPATH and (2)
an ebuild that puts -L. into LDPATH to fix Makefile recipes that appear
more-or-less broken, do we get this conflict. This leads to a certain
odor of unsupportable circumstances which, I must admit, makes me
slightly uncomfortable trying to fix it.
Breaking this down:
(1) is worse than (2), but it does have some quasi-legitimate usages.
For example, prefix bootstrap does this (or used to), as do many of the
crossdev-wrapper scripts. I've also resorted to such usage, myself,
when repairing a prefix after I've broken its compiler. These cases
don't really seem completely correct or incorrect -- about the best
I can say for them it is that they are mostly efficacious, but prone to
problems.
As for (2)... meh. LDFLAGS, to my thinking, means something like: Use
these guidelines and parameters for linking, in preference to the
default guidelines that the build process would normally use. LDFLAGS
coming from make.conf have a slightly different meaning, I guess, but
the gist of it is the same.
So technically speaking, LDFLAGS=-L. ${LDFLAGS} or similar is not a
complete abomination. Still... I don't like it.
If the Makefiles are building against libraries expected to be in
${PWD}, it seems to me that the Makefiles should know to look there
automatically.
In the particular case of Gentoo's cpython, I have to admit I'm
concerned that if I start mucking around with the Makefiles/autotool
scaffolding, I'm going to break stuff. But maybe it's worth taking that
risk if it allows us to do things more correctly going forward... I
could at least take a crack at it and see what people think of the results.
-gmt
Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath
On 10/10/2012 20:37, Gregory M. Turner wrote:
If the Makefiles are building against libraries expected to be in
${PWD}, it seems to me that the Makefiles should know to look there
automatically.
Using the -L . -lfoo is a very bad style in general. Just think what
happen if you're trying to link to a libutil.a
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath
On Wednesday 10 October 2012 23:37:26 Gregory M. Turner wrote:
(1) is worse than (2), but it does have some quasi-legitimate usages.
For example, prefix bootstrap does this (or used to), as do many of the
crossdev-wrapper scripts. I've also resorted to such usage, myself,
when repairing a prefix after I've broken its compiler. These cases
don't really seem completely correct or incorrect -- about the best
I can say for them it is that they are mostly efficacious, but prone to
problems.
they're broken. and no, crossdev doesn't do this. it is properly sysrooted.
further, you cannot do multilib with users putting -Lsystem libdir into
their LDFLAGS. they just forced a single ABI and any other will simply fail.
the toolchain's compiler driver knows exactly where to find its own libraries.
if it doesn't, it's broken, and it should be fixed.
So technically speaking, LDFLAGS=-L. ${LDFLAGS} or similar is not a
complete abomination. Still... I don't like it.
it's significantly better than the proposed code which tries to parse the
meaning of various flags and insert it at the right point. i can't see it
being useful at all. it's a recipe for fragility and being unmaintainable.
If the Makefiles are building against libraries expected to be in
${PWD}, it seems to me that the Makefiles should know to look there
automatically.
yes, so why is the ebuild specifying -L. for it ? the package should already
have a -L to the right place, and if it wants to make sure it gets used before
the user's LDFLAGS, it should show up in the linking before it (or have the
build system prepend the value to LDFLAGS if it's appending currently).
In the particular case of Gentoo's cpython, I have to admit I'm
concerned that if I start mucking around with the Makefiles/autotool
scaffolding, I'm going to break stuff. But maybe it's worth taking that
risk if it allows us to do things more correctly going forward... I
could at least take a crack at it and see what people think of the results.
i'm not sure why this applies to the larger build system. i can understand
that the python build itself might not be putting the -L. in a place where a
user's misconfigured LDFLAGS will cause a problem.
but if you want the right answer, it's to reject broken user LDFLAGS. we
don't support wrong things like -fPIC or -fPIE in global CFLAGS. i don't
think we should be wasting time on LDFLAGS like this either.
-mike
signature.asc
Description: This is a digitally signed message part.
