[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 http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode 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
Re: [gentoo-dev] Re: Bug wrangling
Steve Long a écrit : 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. Getting a team is an excellent idea. Jakub is one of those folks that turn a boring yet essential activity into a craft (with the best possible meaning of the word "craft"). We all know which devs/herds bugs should be assigned to, we all know most bugs aren't complete if emerge --info is not provided, that sort of things. But Real Bug Masters (tm) know all the dupes, know all the current problems in our various trees and arches, and act as bug-spam filters for the herds. So while we can and do *survive* without Jakub, his role is invaluable and having a proper team can only help us in the long term. 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. FWIW, Jakub never had CVS commit access, and specifically refused it. He's only ever worked with Bugzilla and IRC (to ping, poke or harass devs :) ) Cheers Rémi -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Goodbye
Hello, I guess I am tired of fighting with people here. I am too old for this crap. There are few brutal developers here that make Gentoo a terrible place to be. Well... I can handle few developers, but when devrel enters the picture with arguments such as "volunteers can do crappy job as long as they have fun" enough is enough. I signed-up to work on distribution if I have fun in the process it is great! But always keep in mind the delivery I provide to users. Gentoo has some fundamental issues, the obvious one is lack of leadership. There is *NOBODY* that formally responsible or cares about the delivery Gentoo (AS A WHOLE) provide to its users. The council is just a political body that discuss the void issues. As a result the laud and brutal developers dictate the tune. With no proper mechanism to decide if a decision that was taken aligns with Gentoo goals. The devrel process is ridiculous, as proxy between developers without ability to determine anything does not help anyone. During the short time I was around Gentoo lost some of the best developers that were around, due to similar reasons. If Gentoo community cannot provide its own goals, at least it should embrace standards. Compliant to standards may resolve many conflicts. Roy worked hard to make Gentoo POSIX shell compliant, but this was not accepted, but imagine fully Gentoo work with busybox based system, isn't this an advantage we have? especially on small systems. I appreciate flameeyes work on reducing the system size, I am aware how hard it is. There are new violations of HFS in Gentoo, but nobody cares. Jacub, one of the best developers around that actually cared about the service we provide to our users was suspended while trying to do so, and now he is not active anymore. There are some more examples... The brutal developers remain, the quiet leave. Gentoo is built on a lot of inexperienced students, but the backbone of core developers with real-life experience is very weak. I think that current approach of the developers community will not able to resolve this, as a result Gentoo community will not mature. Gentoo has a great piece of technology (portage), this is unique and with the right leadership may be the tool to make Gentoo more stable and popular, as a result extending the user community and gain more resources. But leadership derives goals, goals derive complaint, complaint derives means of enforcement. None of these currently available in the community. Personal note on leadership: vapier - you are good, so good that many envy you. But this does not give you the right to not being nice. You are on of the few people here that can take at least partially resolve the leadership issue. With a little patience and care. (Just to make it clear: I am not leaving because of vapier). Packages to reassign: mobile: dev-libs/libx86 sys-power/suspend sys-power/hibernate-script antivirus ./sys-fs/dazuko misc: net-misc/openvpn media-sound/mp3unicode I am available at email:[EMAIL PROTECTED] Have fun, Alon. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Bug wrangling
On 08:03 Tue 13 May , Rémi Cardona wrote: > We all know which devs/herds bugs should be assigned to, we all know most > bugs aren't complete if emerge --info is not provided, that sort of things. > But Real Bug Masters (tm) know all the dupes, know all the current problems > in our various trees and arches, and act as bug-spam filters for the herds. Would it be possible to add the tree categories as products and the packages as components thereof? That would significantly increase the odds of correct assignment, because we could save the per-package assignees in the database. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
