[gentoo-dev] Bug wrangling
Hi, please be careful when assigning new bugs. Today I changed several bugs where the wrong maintainer was used or where the main maintainer has been forgotten. This only occured since we have no full-time bug-wrangler anymore. Was anyone successful to contact him, yet? V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Bug wrangling
On Mon, 2008-05-12 at 10:20 +0200, Christian Faulhammer wrote: Hi, please be careful when assigning new bugs. Today I changed several bugs where the wrong maintainer was used or where the main maintainer has been forgotten. This only occured since we have no full-time bug-wrangler anymore. Was anyone successful to contact him, yet? V-Li I am told he should be back sometime soon, like today. Apparently someone is in contact with him. Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Bug wrangling
On Mon, May 12, 2008 at 2:10 PM, Ferris McCormick [EMAIL PROTECTED] wrote: This only occured since we have no full-time bug-wrangler anymore. Was anyone successful to contact him, yet? I am told he should be back sometime soon, like today. Apparently someone is in contact with him. That he comes back or not is of no importance to bug wrangling. Or at least it should be. It is a mistake to solely rely on a developer for such a task. Developers come and go without warning, he just proved it, so ideally we need a team of 2 or 3 to handle bug wrangling. Also, one single developer handling this puts him/her in such a prominent position that it is bad for him/her, our users, other developers and the entire project. We had too many examples of this. Denis. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Bug wrangling
Denis Dupeyron schrieb: That he comes back or not is of no importance to bug wrangling. Or at least it should be. It is a mistake to solely rely on a developer for such a task. Developers come and go without warning, he just proved it, so ideally we need a team of 2 or 3 to handle bug wrangling. Also, one single developer handling this puts him/her in such a prominent position that it is bad for him/her, our users, other developers and the entire project. We had too many examples of this. Fully with you, yet the other people who do bug wrangling occasionally didn't do it as good as him mainly because he followed all major mailinglists and knew the common issues around. I have nowhere an idea how much time he put into his bugwrangling but I bet that reaches at least 5-6 hours a day. Replacing that is simply hard work and nothing else and I'd love to see people stepping up to help with that task. -Jokey -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Bug wrangling
Denis Dupeyron [EMAIL PROTECTED] said: That he comes back or not is of no importance to bug wrangling. Or at least it should be. It is a mistake to solely rely on a developer for such a task. Developers come and go without warning, he just proved it, so ideally we need a team of 2 or 3 to handle bug wrangling. Also, one single developer handling this puts him/her in such a prominent position that it is bad for him/her, our users, other developers and the entire project. We had too many examples of this. Making an actual bug wrangling team (subproject of QA) is something I've been toying around with in my head. I'd love to get an actual team set up so we can encourage users to help us get the information we need in bugs so it is less work for us. Several other distributions have such projects, so we have something we can use as a template. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpgsmBHX4PIH.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] global useflags
Markus Meier wrote: qt3support: Enable the Qt3Support libraries for Qt4 While it affects a few packages, they all are parts of the Qt toolkit (which we previously shipped in one big package). I can't see a scenario where this flag might be used on a package not released by Trolltech. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] LaTeX documentation
Hello *,
Many packages have documentation in LaTeX, and latex is being run (often
when USE=doc). This may cause a sandbox violation, if a font not yet
generated on this particular computer is encountered: latex calls metafont
to generate it, and metafont wants to write it to /var/cache/fonts (and
its subdirectories). The worst thing is that this bug is unpredictable: if
only commonly-used fonts are encountered, they are already in
/var/cache/fonts, and everything is OK; on some other computer, the same
package can produce a sandbox violation.
There are two methods commonly used to fight against this situation in
ebuilds: using addwrite or setting VARTEXFONTS=${T}/fonts. The second
method is, probably, better. The packages still using addwrite are:
app-doc/doxygen
app-office/kletterwizard
app-text/noweb
dev-lisp/cl-mcclim
dev-python/pyopenssl
dev-tex/feynmf
dev-tex/memoir
media-gfx/asymptote
media-libs/t1lib
media-libs/allegro
sci-chemistry/moldy
sci-mathematics/pari
sci-visualization/pyxplot
Probably, it would be a good idea to change these ebuilds.
The packages using the VARTEXFONTS method are
app-emulation/wine
app-text/jadetex
app-text/linuxdoc-tools
dev-lang/R
dev-tex/listings
dev-tex/texpower
dev-tex/envlab
dev-tex/bibtex2html
dev-tex/xcolor
dev-tex/latex2rtf
dev-tex/mh
media-libs/libcaca
media-libs/libdvdcss
media-libs/aubio
media-libs/libfishsound
sci-mathematics/octave
sci-visualization/gnuplot
Two of them convertex just recently: app-text/jadetex between 3.13-r1 and
3.13-r2, and dev-tex/listings between 1.3 and 1.4. Good for them.
Most disturbingly, there are a number of packages which (probably) run
latex and do neither addwrite nor VARTEXFONTS. An incomplete list of such
suspect packages is (for now, I only considered packages not directly
related to TeX/LaTeX, i.e., not in dev-tex or dev-texlive and not
TeX/LaTeX packages in app-text):
app-backup/bacula
app-emacs/pymacs
app-emacs/slime
app-emulation/xen-tools
app-i18n/canna
app-misc/tdl
app-misc/fdutils
dev-ada/xmlada
dev-ada/asis-gcc
dev-ada/asis-gpl
dev-embedded/avrdude
dev-haskell/lhs2tex (*)
dev-lang/mlton
dev-lang/mmix
dev-libs/beecrypt
dev-libs/libtomcrypt
dev-lisp/gcl
dev-lisp/cl-cffi
dev-lisp/cl-cgi-utils
dev-lisp/cl-iterate/cl-iterate-1.4 (**)
dev-lisp/cl-tclink (***)
dev-lisp/cl-xml-psychiatrist
dev-lisp/clisp
dev-python/python-xlib
dev-python/pyx
dev-tcltk/tkzinc
dev-tinyos/tos
dev-util/bnfc
dev-util/ragel
dev-util/darcs
games-board/freedoko
media-gfx/sane-backends
media-sound/musescore ()
media-video/dirac
net-analyzer/ns
net-analyzer/sonar
net-dialup/mgetty
sci-biology/wise
sci-libs/netcdf
sci-libs/pgplot
sci-mathematics/axiom
sci-mathematics/ginac
sci-mathematics/nusmv
sci-misc/gri
sci-misc/nco
sys-block/btrace
sys-cluster/mpich2
sys-cluster/pvfs2
sys-cluster/charm
sys-power/apcupsd
sys-power/powersave
(*) By the way, here a .pdf file is installed using dodoc, and hence will
be bzip2ed - not a goog idea
(**) but not later versions
(***) The only place where the USE flag doc is used commented out???
() USE flag doc never used??
These are (potentially) bombs waiting to blow up an unsuspecting user.
They should be carefully checked.
By the way, while investigating this question, I found quite a few
packages which still depend on virtual/tetex, while, probably,
virtual/latex-base would be better (in some of them, the USE flag tetex
then should become latex). Some suspects are:
app-doc/doxygen
app-emacs/slime
app-misc/tdl
app-misc/fdutils
app-misc/muttprint
app-misc/chesstask
app-office/eqe
app-office/texmaker
app-office/grisbi
app-office/kletterwizard
app-text/a2ps
app-text/dvipdfmx
app-text/noweb
app-text/active-dvi
app-text/evince
app-text/pdfjam
app-text/passivetex
app-text/kbibtex
app-vim/latexsuite
dev-ada/asis-gpl
dev-embedded/avrdude
dev-haskell/lhs2tex
dev-lang/mmix
dev-libs/libtomcrypt
dev-lisp/cl-mcclim
dev-lisp/cl-cgi-utils
dev-lisp/cl-iterate
dev-lisp/clisp
dev-lisp/cl-tclink
dev-lisp/cl-cffi
dev-perl/Template-Latex
dev-python/pyx
dev-python/epydoc
dev-tcltk/tkzinc
dev-tinyos/tos
dev-util/bnfc
dev-util/ragel
dev-util/darcs
games-board/freedoko
kde-base/kdvi
kde-base/kopete
media-gfx/asymptote
media-libs/vflib
media-libs/allegro
media-sound/musescore
net-analyzer/ns
net-analyzer/sonar
net-dialup/mgetty
sci-biology/wise
sci-chemistry/moldy
sci-electronics/gnucap
sci-geosciences/gpsbabel
sci-libs/libcore
sci-libs/pgplot
sci-libs/itpp
sci-mathematics/pari
sci-mathematics/nusmv
sci-misc/gri
sci-physics/jaxodraw
sci-physics/paw
sci-physics/cernlib
sci-physics/cernlib-montecarlo
sci-physics/geant
sci-visualization/pyxplot
sys-block/btrace
sys-cluster/mpich2
sys-cluster/charm
sys-power/apcupsd
sys-power/powersave
www-apps/mediawiki
www-servers/boa
x11-plugins/pidgin-latex
(I have not checked in detail, maybe, some of them indeed need tetex).
What do you think?
Andrey
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] global useflags
Jan Kundr?t wrote: Markus Meier wrote: qt3support: Enable the Qt3Support libraries for Qt4 While it affects a few packages, they all are parts of the Qt toolkit (which we previously shipped in one big package). I can't see a scenario where this flag might be used on a package not released by Trolltech. sci-visualization/qtiplot, for example Andrey -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] global useflags
Andrey Grozin wrote: sci-visualization/qtiplot, for example I don't see a reference to the qt3support flag in any of qtiplot ebuilds, could you please clarify what you mean? Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] global useflags
Jan Kundr?t wrote: I don't see a reference to the qt3support flag in any of qtiplot ebuilds, could you please clarify what you mean? I see, this thing has disappeared in recent versions... Sorry. There was a period when qtiplot required qt4 emerged with qt3support USE flag. So, it had pkg_setup which checked this and produced an error it necessary. qt3support was not a USE flag of qtiplot. So, I agree, there seems to be no reasons to make it a global USE flag. Andrey -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] global useflags
Andrey Grozin wrote: There was a period when qtiplot required qt4 emerged with qt3support USE flag. So, it had pkg_setup which checked this and produced an error it necessary. Ah, that's quite common -- a package FooBar is ported to Qt4, but it still uses some of the Qt4's Qt3support classes. This is handled by FooBar depending on qt4 being built with that particular USE flag, not a qt3support in for the FooBar package itself, though. Cheer, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] LaTeX documentation
Hi,
There are two methods commonly used to fight against this situation
in ebuilds: using addwrite or setting VARTEXFONTS=${T}/fonts. The
second method is, probably, better.
Packages should definitely go for the VARTEXFONTS one as I'll probably
drop forced global writable /var/cache/fonts at some point in the
texmf-update script (not that its a security issue but I really dont
like having it like that); if its not world writable and a package
needs to build some fonts and isn't run as root (default nowadays?) the
addwrite will not allow it to write there afaik and it will fail.
Nice you have such a list, please assign a bug to [EMAIL PROTECTED] for that and
I'll see what I can do to convert them (perhaps adding the maintainers
in case they want to know what's up and are willing to help).
See:
https://bugs.gentoo.org/show_bug.cgi?id=204433
http://groups.google.com/group/linux.gentoo.dev/browse_thread/thread/bf2e58fe200c0676/b72be3596cd2eb31
Most disturbingly, there are a number of packages which (probably)
run latex and do neither addwrite nor VARTEXFONTS. An incomplete list
of such suspect packages is (for now, I only considered packages not
directly related to TeX/LaTeX, i.e., not in dev-tex or dev-texlive
and not TeX/LaTeX packages in app-text):
[...]
These are (potentially) bombs waiting to blow up an unsuspecting
user. They should be carefully checked.
Yeah or maybe they dont need any unusual fonts; its probably sane to
set VARTEXFONTS regardless. Probably it'd be worth adding a latex
eclass that would just contain:
VARTEXFONTS=${T}/fonts
and inherit it from any package calling latex to avoid code duplication
(like e.g. the mono eclass do).
What do you think ?
By the way, while investigating this question, I found quite a few
packages which still depend on virtual/tetex, while, probably,
virtual/latex-base would be better
Yep, it would be cool to kill virtual/tetex because it does not make
much sense nowadays. Some might be false positives but please also file
a bug for [EMAIL PROTECTED] with that list and cc the maintainers to see what
can
be done.
Regards,
Alexis.
signature.asc
Description: PGP signature
[gentoo-dev] Re: Bug wrangling
Markus Ullmann [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 12 May 2008 15:49:30 +0200: Fully with you, yet the other people who do bug wrangling occasionally didn't do it as good as him mainly because he followed all major mailinglists and knew the common issues around. I have nowhere an idea how much time he put into his bugwrangling but I bet that reaches at least 5-6 hours a day. Replacing that is simply hard work and nothing else and I'd love to see people stepping up to help with that task. Yes. He knows his stuff and puts in quite a bit of time. Theoretical problems with relying on one person or not, that just can't be easily or well substituted, in practice, however much it might be a good idea not to rely solely on one person. Like it or not, he is a central enough cog in the machine that when he stops working, even with other cogs in place to try to do the same duty, the entire machine gets glitchy. So thanks, Jakob. We miss you! =8^) -- 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 -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Bug wrangling
Mark Loeser wrote: Making an actual bug wrangling team (subproject of QA) is something I've been toying around with in my head. I'd love to get an actual team set up so we can encourage users to help us get the information we need in bugs so it is less work for us. Several other distributions have such projects, so we have something we can use as a template. I brought this up last year[1][2] wrt WINE triage. GNOME has a similar thing ofc, so Gentoo devs are used to working with this model. Irrespective, it doesn't preclude the need for a good bugmaster[3] but should be seen as complementary to that person (it's rarely more than one apparently) iow to support that person in their work. That requires non-technical things (*cough* follow-up) like a sense of teamwork, and not looking down on people who don't have cvs commit access. Of course those also make it more likely that people will want to volunteer for triage, or indeed anything else (which can be a virtuous circle.) I'd moot Patrick as a useful bod because he can automate much of this. [1] http://article.gmane.org/gmane.linux.gentoo.devel/46855 [2] http://article.gmane.org/gmane.linux.gentoo.devel/49546 [3] http://tieguy.org/talks/LCA-2005-paper-html/index.html -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Re: RFC: qemu - add gcc-3.x dependency
Matthias Schwarzott wrote:
Well, you want it compact, without loops.
Here is it:
set -- /usr/bin/gcc-3*
Get first entry: CC=$1
Get last entry: eval CC=\${$#}
Nice one, yeah I thought : splitting was posix silly me ;)
I still shy clear of eval for general use and you have to go thru
contortions with sh, so I'll stick with BASH arrays and syntactic sugar
which gets twisted enough as it is.
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-portage-dev] [PATCH] unpack .deb files with deb2tgz
Attached patch is necessary for some extreme platforms, as can be read
in the comments.
--
Fabian Groffen
Gentoo on a different level
--- ../../trunk/bin/ebuild.sh 2008-04-27 17:36:18 +0200
+++ ./bin/ebuild.sh 2008-04-13 11:41:55 +0200
@@ -372,9 +372,22 @@
LHa|LHA|lha|lzh)
lha xfq ${srcdir}${x} || die $myfail
;;
- a|deb)
+ a)
ar x ${srcdir}${x} || die $myfail
;;
+ deb)
+ # Unpacking .deb archives can not always be
done with
+ # `ar`. For instance on AIX this doesn't work
out. If
+ # we have `deb2targz` installed, prefer it over
`ar` for
+ # that reason. We just make sure on AIX
`deb2targz` is
+ # installed.
+ if type -P deb2targz /dev/null; then
+ deb2targz ${srcdir}/${x} || die
$myfail
+ mv ${srcdir}/${x/.deb/.tar.gz}
data.tar.gz
+ else
+ ar x ${srcdir}/${x} || die $myfail
+ fi
+ ;;
lzma)
if [ ${y} == tar ]; then
lzma -dc ${srcdir}${x} | tar xof -
${tar_opts}
[gentoo-portage-dev] [PATCH] remove eselect compiler usage
eselect compiler has been removed from the tree, hence its usage can be removed from portage. -- Fabian Groffen Gentoo on a different level --- ../../trunk/pym/_emerge/__init__.py 2008-05-12 19:25:21 +0200 +++ ./pym/_emerge/__init__.py 2008-05-12 17:16:49 +0200 @@ -303,12 +318,6 @@ !!! other terminals also.\n ) - mystatus, myoutput = commands.getstatusoutput(eselect compiler show) - if mystatus == os.EX_OK and len(myoutput.split(/)) == 2: - part1, part2 = myoutput.split(/) - if part1.startswith(chost + -): - return myoutput.replace(chost + -, gcc_ver_prefix, 1) - mystatus, myoutput = commands.getstatusoutput(gcc-config -c) if mystatus == os.EX_OK and myoutput.startswith(chost + -): return myoutput.replace(chost + -, gcc_ver_prefix, 1)
[gentoo-portage-dev] [PATCH] show binhosts as repository
The following patch shows the url to the binhost in an emerge -av as repository name, instead of unknown. Unfortunately the patch doesn't store the binhost url, such that portage can't show where the package comes from when unmerged. -- Fabian Groffen Gentoo on a different level --- ../../trunk/pym/_emerge/__init__.py 2008-05-12 19:25:21 +0200 +++ ./pym/_emerge/__init__.py 2008-05-12 17:16:49 +0200 @@ -1117,6 +1126,6 @@ pkg_chost = pkg.metadata.get(CHOST) if pkg_chost and pkg_chost != pkgsettings[CHOST]: return False if not portage.eapi_is_supported(pkg.metadata[EAPI]): return False if not pkg.installed and \ @@ -4447,13 +4471,18 @@ pkg = x metadata = pkg.metadata ebuild_path = None - repo_name = metadata[repository] + if pkg_type == binary: + repo_name = self.roots[myroot].settings.get(PORTAGE_BINHOST) + else: + repo_name = metadata[repository] if pkg_type == ebuild: ebuild_path = portdb.findname(pkg_key) if not ebuild_path: # shouldn't happen raise portage.exception.PackageNotFound(pkg_key) repo_path_real = os.path.dirname(os.path.dirname( os.path.dirname(ebuild_path))) + elif pkg_type == binary: + repo_path_real = repo_name else: repo_path_real = portdb.getRepositoryPath(repo_name) pkg_use = metadata[USE].split() @@ -5422,6 +5451,11 @@ self._repo_paths_real = [ os.path.realpath(repo_path) \ for repo_path in repo_paths ] + if root_config.settings.get(PORTAGE_BINHOST): + binhost = root_config.settings.get(PORTAGE_BINHOST) + self._repo_paths.append(binhost) + self._repo_paths_real.append(binhost) + # pre-allocate index for PORTDIR so that it always has index 0. for root_config in roots.itervalues(): portdb = root_config.trees[porttree].dbapi
[gentoo-portage-dev] [PATCH] include status support for xterm-color and interix
Attached patch adds statusbar support for xterm-color and interix terminals. -- Fabian Groffen Gentoo on a different level --- ../../trunk/pym/portage/output.py 2008-05-12 19:25:13 +0200 +++ ./pym/portage/output.py 2008-05-08 21:17:50 +0200 @@ -246,7 +246,7 @@ if len(mystr) max_len: mystr = mystr[:max_len] myt=os.environ[TERM] - legal_terms = [xterm,Eterm,aterm,rxvt,screen,kterm,rxvt-unicode,gnome] + legal_terms = [xterm,xterm-color,Eterm,aterm,rxvt,screen,kterm,rxvt-unicode,gnome,interix] for term in legal_terms: if myt.startswith(term): if not raw:
