[gentoo-dev] sys-libs/db, emerge and revdep-rebuild
Hi there, I had a different problem with the db upgrade last week: postfix broke. I had to run revdep-rebuild to fix it; this is fine, except that nothing prompted me to run revdep-rebuild. So: - Am I expected to run revdep-rebuild after every emerge -uavDN world now? - If so, can we get more integration with emerge itself? - If not, could future db upgrades grow an elog about revdep-rebuilding? postfix breakage was pretty annoying because (a) email is a pretty important part of servers, and (b) the postfix daemon itself kept working, but all of the little child processes failed, thus making the failure not as transparent as one might want. Cheers, Dirkjan
Re: [gentoo-dev] sys-libs/db, emerge and revdep-rebuild
On 09/06/2010 12:28 AM, Dirkjan Ochtman wrote: - Am I expected to run revdep-rebuild after every emerge -uavDN world now? Yes, that's always been the case. - If so, can we get more integration with emerge itself? I'd like us to add EAPI support for abi-slot dependencies, as discussed in these bugs: http://bugs.gentoo.org/show_bug.cgi?id=192319 http://bugs.gentoo.org/show_bug.cgi?id=327809 -- Thanks, Zac
[gentoo-dev] RFC Bugzilla interaction guide for devs editbugs users
Hi, After a discussion on IRC, a few of us were considering the value of adding suggestions on handling of bugs in Bugzilla from a developer (and editbugs user) perspective. These is the simplest set I have to start, but I'd really like other comments and ideas. 1. General case - You should only close bugs that you are assigned or if you (or an alias you represent) just fixed them. - If you fix a bug and AREN'T already getting mail for it, you should add yourself to the CC list, to listen for regressions or responses to TESTREQUEST. 2. Special cases 2.1. STABLEREQ, KEYWORDREQ The last arch on the list should close the bug when they have completed the action. 2.2. Security bugs The developer should comment, but ONLY members of the security team should: - change whiteboard - add/remove arches - change bug status/reso -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpzahr8yClTS.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in gnome-extra/hardware-monitor: ChangeLog hardware-monitor-1.4.3.ebuild
Le lundi 06 septembre 2010 à 07:30 +, Michael Weber (xmw) a écrit :
xmw 10/09/06 07:30:05
Modified: ChangeLog
Added:hardware-monitor-1.4.3.ebuild
Log:
Version bump to fix bug #328735
(Portage version: 2.1.8.3/cvs/Linux x86_64)
[...]
file :
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/gnome-extra/hardware-monitor/hardware-monitor-1.4.3.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewvc.cgi/gentoo-x86/gnome-extra/hardware-monitor/hardware-monitor-1.4.3.ebuild?rev=1.1content-type=text/plain
Index: hardware-monitor-1.4.3.ebuild
===
# Copyright 1999-2010 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header:
/var/cvsroot/gentoo-x86/gnome-extra/hardware-monitor/hardware-monitor-1.4.3.ebuild,v
1.1 2010/09/06 07:30:05 xmw Exp $
[...]
src_unpack() {
gnome2_src_unpack
}
gnome2 eclass exports the unpack phase and it is not overridden by
another eclass so this declaration is useless. Please drop it from the
ebuild.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
[gentoo-dev] Re: RFC Bugzilla interaction guide for devs editbugs users
Hi, Robin H. Johnson robb...@gentoo.org: 2.2. Security bugs The developer should comment, but ONLY members of the security team should: - change whiteboard - add/remove arches As security may be grateful for any kind of help, those two actions is often done by the maintainers. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] RFC Bugzilla interaction guide for devs editbugs users
On Mon, 6 Sep 2010 10:39:59 +0200, Dirkjan Ochtman d...@gentoo.org wrote: [...] 2.2. Security bugs The developer should comment, but ONLY members of the security team should: - change whiteboard - add/remove arches - change bug status/reso The arches can still remove themselves when they've done whatever they needed to do, right? Of course. -- Alex Legler | Gentoo Security / Ruby a...@gentoo.org | a...@jabber.ccc.de signature.asc Description: PGP signature
Re: [gentoo-dev] RFC Bugzilla interaction guide for devs editbugs users
On 09/06/2010 10:39 AM, Dirkjan Ochtman wrote: On Mon, Sep 6, 2010 at 10:32, Robin H. Johnson robb...@gentoo.org wrote: After a discussion on IRC, a few of us were considering the value of adding suggestions on handling of bugs in Bugzilla from a developer (and editbugs user) perspective. Good idea, I've been confused about the interaction models here. 1. General case - You should only close bugs that you are assigned or if you (or an alias you represent) just fixed them. - If you fix a bug and AREN'T already getting mail for it, you should add yourself to the CC list, to listen for regressions or responses to TESTREQUEST. Only add arches to stabilization requests if you're a maintainer? What about user issued KEYWORD/STABLE-REQ on maintainer-nee...@g.o assignd bugs/packages? Close as RESO/WONTFIX or add the arches? Michael -- Gentoo Developer
[gentoo-dev] Re: RFC Bugzilla interaction guide for devs editbugs users
Hi, Michael Weber x...@gentoo.org: What about user issued KEYWORD/STABLE-REQ on maintainer-nee...@g.o assignd bugs/packages? Close as RESO/WONTFIX or add the arches? Common sense. Practice has been to add arches if it fixes a problem in a current stable, if there is no stable version available or the current one is still ok, rethink. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: RFC Bugzilla interaction guide for devs editbugs users
On Mon, 6 Sep 2010 10:39:59 +0200 Dirkjan Ochtman d...@gentoo.org wrote: On Mon, Sep 6, 2010 at 10:32, Robin H. Johnson robb...@gentoo.org wrote: After a discussion on IRC, a few of us were considering the value of adding suggestions on handling of bugs in Bugzilla from a developer (and editbugs user) perspective. Good idea, I've been confused about the interaction models here. 1. General case - You should only close bugs that you are assigned or if you (or an alias you represent) just fixed them. Prefix Once assigned,. Can we add a point about bug-wranglers not messing with bugs after they've been assigned? I've had someone closing bugs filed directly from a dev to my herd because they didn't include emerge --info. - If you fix a bug and AREN'T already getting mail for it, you should add yourself to the CC list, to listen for regressions or responses to TESTREQUEST. Only add arches to stabilization requests if you're a maintainer? No. If the maintainer doesn't respond in a reasonable amount of time then I'm adding arches myself. If this weren't allowed then the GCC stabilization bugs would take approx 8 years to fix. -- fonts, gcc-porting, we hold our breath, we spin around the world toolchain, wxwidgetsyou and me cling to the outside of the earth @ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
