[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: virtualx.eclass
-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 logs? V-Li Yeah mea culpa, I thought of it right away when i sent it, but sadly we don't have way how to update commitmsg :) As described in request for comments 20 days ago: virtualx: Pretty much add eclass-debug info everywhere and fix formatting. migrate from export maketype to more reliable VIRTUALX_COMMAND global variable (can be set anytime). deprecate Xmake in favor of Xemake -j1 or VIRTUALX_COMMAND=emake -j1 Change the VIRTUALX_REQUIRED and VIRTUALX_USE to be bit saner and merged into one variable with qa deprecation warnings and fallback in place. New usage described in eclassdoc pretty well. Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk17NCYACgkQHB6c3gNBRYcq8QCeL/4jX9YeFrhDhhJ6saNn9XAa LNgAoJFanQEI/WE0MPct9gUs+acp5oho =Huyz -END PGP SIGNATURE-
[gentoo-dev] virtualx eclass possible issue
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 to an X display
debug-print ${FUNCNAME}: ${VIRTUALX_COMMAND} \$@\
${VIRTUALX_COMMAND} $@
retval=$?
fi
# die if our command failed
[[ $? -ne 0 ]] die ${FUNCNAME}: the ${VIRTALX_COMMAND} failed.
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?
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-ruby/ruby-gnomeprint(ui)
# 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 digitally signed message part
Re: [gentoo-dev] unbreaking net-print/foo2zjs
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 bits from your message when reading earlier. Could you please send me the ebuild you are using? If some printers can be supported with no additional firmware/files, creating a non-live, versioned-tarball based packages should be possible, and I can do it. Paweł Hajdan, Jr. signature.asc Description: OpenPGP digital signature
[gentoo-dev] pax-utils.eclass: elog - einfo?
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 einfos in pax-utils.eclass. What do you think? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Quantity of open bugs
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 be fixed reasonably quickly if the packages were maintained. And no, me or any other number of people going through to fix just those is not feasible, see my old post at [1] for some reasons. 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: - makes it harder to see whether the package has any maintainer at all; - would waste my time as I'd be re-opening the same exact bug at the following tinderbox iteration, as the original bug was closed (and no, I wouldn't go _reopening_ the bug, since I wouldn't remember there was one already most of the time, so the load on bugzilla would increase). So if somebody would still have doubts about this, I think the point is vetoed to close bugs without action as WONTFIX after any time at all. Rather get rid of the package in that case. And you can challenge that with the council if you wish as I'm weighting that in as part of QA, thank you very much. OTOH if a bug is waiting for user to report build logs or other kind of test results, closing as TEST-REQUEST or NEEDINFO is likely a good idea. [1] http://blog.flameeyes.eu/2009/12/28/the-five-minutes-fix-myth -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last rites: app-emacs/htmlfontify
# 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
# 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
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 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 it's about as low priority as you can get. So this might serve as a pointer to potentially unmaintained packages, but clearly more investigation is required before removal. -- Thanks, Donnie Donnie Berkholz Sr. Developer, Gentoo Linux Blog: http://dberkholz.com pgpXlUAj6ZLsw.pgp Description: PGP signature
[gentoo-dev] Re: Re: Quantity of open bugs
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 it's about as low priority as you can get. Not really. An user would never report that the package is bundling libraries, but that is actually pretty high in priority as it can lead to hidden security issues already resolved in the original library to sneak in the system. At the same time, very few users report ignored variables (CC, CFLAGS, LDFLAGS, ...) but they are just the same a problem. Especially when hardening flags are not used at all. So this might serve as a pointer to potentially unmaintained packages, but clearly more investigation is required before removal. There is always the need to do manual investigation. But in general when you see a package that - ignores LDFLAGS; - shows fortify source warnings; - ignores CC; - misuses autotools; - bundle libraries. you can pretty safely assume neither somebody is looking after it, nor using it. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/
[gentoo-dev] Re: virtualx eclass possible issue
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, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] virtualx eclass possible issue
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}'.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
