[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: virtualx.eclass

2011-03-12 Thread Tomáš Chvátal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 11.3.2011 23:30, Christian Faulhammer napsal(a): Hi, Tomas Chvatal (scarabeus) scarab...@gentoo.org: Sync virtualx.eclass from x11 overlay as per review ~week ago. Could we have some more verbose descriptions than that in the commit

[gentoo-dev] virtualx eclass possible issue

2011-03-12 Thread Paweł Hajdan, Jr.
One of my ebuilds is using virtualx eclass, and I noticed the following code inside the eclass: retval=$? # Now kill Xvfb kill $(cat /tmp/.X${XDISPLAY}-lock) else debug-print ${FUNCNAME}: attaching to running X display # Normal make if we can connect

[gentoo-dev] Last rites: dev-ruby/ruby-gnomeprint(ui)

2011-03-12 Thread Hans de Graaff
# Hans de Graaff gra...@gentoo.org (12 Mar 2011) # Mask for removal on 20110412 (#358431) # Needs libgnomeprint that is deprecated and unsupported for # a long time. Nothing in the tree needs this. dev-ruby/ruby-gnomeprint dev-ruby/ruby-gnomeprintui signature.asc Description: This is a

Re: [gentoo-dev] unbreaking net-print/foo2zjs

2011-03-12 Thread Paweł Hajdan, Jr.
I have just committed the live ebuild for foo2zjs. At least it works. On 3/7/11 1:05 PM, Hanno Böck wrote: I have a printer using foo2zjs and have my own ebuild for that. Though my printer is black-white and thus doesn't need the whole color-profile stuff and no firmware. Ah, I missed a few

[gentoo-dev] pax-utils.eclass: elog - einfo?

2011-03-12 Thread Paweł Hajdan, Jr.
I wonder why pax-utils.eclass uses elog instead of just einfo. An example message looks like this: * Fallback PaX marking -m * out/Release/chrome IMHO it's not very useful in the elog messages, but maybe there are scenarios in which it is useful. My idea is to just replace all elogs with

[gentoo-dev] Re: Quantity of open bugs

2011-03-12 Thread Diego Elio Pettenò
Il giorno gio, 10/03/2011 alle 20.25 +, Kevin F. Quinn ha scritto: * Number of open bugs is greater than 14,000 For the record, about 10% of those are reported by me through tinderbox (1506 open bugs reported by me as of today). A number of those date back in 2008 and earlier, and could

[gentoo-dev] Last rites: app-emacs/htmlfontify

2011-03-12 Thread Ulrich Mueller
# Ulrich Mueller u...@gentoo.org (12 Mar 2011) # Part of app-editors/emacs since version 23.2. # Cannot be compiled with Emacs 23. Last release in 2003. # Masked for removal in 60 days, bug 358351. app-emacs/htmlfontify

[gentoo-dev] Lastrite: dev-cpp/gtkmm:1.2

2011-03-12 Thread Pacho Ramos
# Pacho Ramos pa...@gentoo.org (12 Mar 2011) # Old, unused, no longer developed (bug #355825). # Removal in 30 days. =dev-cpp/gtkmm-1.2.9-r2 signature.asc Description: This is a digitally signed message part

Re: [gentoo-dev] Re: Quantity of open bugs

2011-03-12 Thread Donnie Berkholz
On 15:45 Sat 12 Mar , Diego Elio Pettenò wrote: I actually use the fact that these are still open to judge whether a package has to be removed from the tree, closing them would definitely be a bad idea for two reasons: I'm assuming you're talking only about broken builds here and not

[gentoo-dev] Re: Re: Quantity of open bugs

2011-03-12 Thread Diego Elio Pettenò
Il giorno sab, 12/03/2011 alle 11.09 -0600, Donnie Berkholz ha scritto: I'm assuming you're talking only about broken builds here and not QA-only bugs. My opinion is that if a tinderbox QA script is the only thing finding a nonfatal bug, and it's never reported or CC'd by a user, then

[gentoo-dev] Re: virtualx eclass possible issue

2011-03-12 Thread Ryan Hill
On Sat, 12 Mar 2011 11:37:28 +0100 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Shouldn't that last line look more like this (notice $retval instead of $?): [[ $retval -ne 0 ]] die ${FUNCNAME}: the ${VIRTALX_COMMAND} failed. Sure looks like it to me. -- fonts, gcc-porting,

Re: [gentoo-dev] virtualx eclass possible issue

2011-03-12 Thread Michał Górny
On Sat, 12 Mar 2011 11:37:28 +0100 Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Shouldn't that last line look more like this (notice $retval instead of $?): [[ $retval -ne 0 ]] die ${FUNCNAME}: the ${VIRTALX_COMMAND} failed. What do you think? I'd say even '${VIRTUALX_COMMAND}'.