headers
Pacho Ramos | 2 Sep 2010 13:24
Picon
Favicon
Gravatar

Last rites: x11-themes/smooth-themes and x11-themes/smoothgnome

# Pacho Ramos <pacho <at> gentoo.org> (2 Sep 2010)
# They don't work since >=x11-themes/gtk-engines-2.16 lost 
# support for Smooth engine (bug #330181).
# Removal on 2010-10-01
x11-themes/smooth-themes
x11-themes/smoothgnome
Permalink | Reply | 0 comments |
headers
Mike Frysinger | 5 Sep 2010 01:37
Picon
Favicon
Gravatar

bash-4.1 for stable

if people have packages that dont work with bash-4.1, nows the time to file 
blockers of Bug 3360373
-mike
Permalink | Reply | 1 comment |
headers
Daniel Pielmeier | 5 Sep 2010 14:49
Picon
Favicon

Re: bash-4.1 for stable

2010/9/5 Mike Frysinger <vapier <at> gentoo.org>:
> if people have packages that dont work with bash-4.1, nows the time to file
> blockers of Bug 3360373
> -mike

Should be Bug #336037,  I guess.

--

-- 
Daniel Pielmeier
Permalink | Reply | 0 comments |
headers
Robin H. Johnson | 6 Sep 2010 02:25
Picon
Favicon
Gravatar

Automated Package Removal and Addition Tracker, for the week ending 2010-09-05 23h59 UTC

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2010-09-05 23h59 UTC.

Removals:
sys-apps/s390-oco                   	2010-08-30 03:30:27	vapier
dev-python/pygoogle                 	2010-08-31 12:07:46	hwoarang
gnome-base/eel                      	2010-09-02 11:30:12	pacho
gnome-extra/nautilus-cd-burner      	2010-09-02 11:31:46	pacho
dev-python/nautilus-cd-burner-python	2010-09-02 11:32:30	pacho
dev-dotnet/nautilusburn-sharp       	2010-09-02 11:33:18	pacho
dev-dotnet/heap-buddy               	2010-09-02 11:34:26	pacho
x11-plugins/gkrellm-hddtemp         	2010-09-02 16:53:45	lack
media-video/em84xx-modules          	2010-09-03 14:09:48	flameeyes
media-video/em84xx-libraries        	2010-09-03 14:09:49	flameeyes
media-plugins/vdr-em84xx            	2010-09-03 14:09:49	flameeyes
media-video/packetcommand           	2010-09-03 14:09:50	flameeyes
app-i18n/adaptit                    	2010-09-03 14:09:50	flameeyes
dev-util/pbuilder                   	2010-09-03 14:09:50	flameeyes
mail-client/exmh                    	2010-09-03 14:09:51	flameeyes
mail-client/nmh                     	2010-09-03 14:09:51	flameeyes

Additions:
dev-python/nltk                     	2010-08-30 17:13:45	hwoarang
app-editors/wxhexeditor             	2010-08-31 04:16:58	dirtyepic
x11-wm/parti                        	2010-08-31 09:04:56	xmw
net-analyzer/w3af                   	2010-08-31 09:37:17	hwoarang
media-radio/KochMorse               	2010-08-31 13:09:02	xmw
app-crypt/codegroup                 	2010-08-31 17:33:08	xmw
dev-ruby/thor                       	2010-08-31 20:14:24	a3li
sys-kernel/pf-sources               	2010-09-01 16:27:56	wired
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eray Aslan | 6 Sep 2010 07:29
Picon

Re: sys-libs/db and dll hell

On 01.09.2010 00:05, Robin H. Johnson wrote:
> Unfortunately there isn't really any graceful fix. The buildsystem needs
> to be patched, ideally to allow explicit passing of the DB include
> directory

Patch for the above accepted by upstream [1].  So, all is good.  Nice to
have a responsive upstream.

Thanks for the pointers.
--

-- 
Eray

[1]
http://github.com/heimdal/heimdal/commit/a1c14b231996ebd72de69df1de472f08e82c2288
Permalink | Reply | 0 comments |
headers
Dirkjan Ochtman | 6 Sep 2010 09:28
Picon
Favicon

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
Permalink | Reply | 2 comments |
headers
Zac Medico | 6 Sep 2010 10:10
Picon
Favicon
Gravatar

Re: 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
Permalink | Reply | 0 comments |
headers
Robin H. Johnson | 6 Sep 2010 10:32
Picon
Favicon
Gravatar

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
(Continue reading)

Permalink | Reply | 18 comments |
headers
Dirkjan Ochtman | 6 Sep 2010 10:39
Picon
Favicon

Re: RFC Bugzilla interaction guide for devs & editbugs users

On Mon, Sep 6, 2010 at 10:32, Robin H. Johnson <robbat2 <at> 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?

> 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

The arches can still remove themselves when they've done whatever they
needed to do, right?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Gilles Dartiguelongue | 6 Sep 2010 10:41
Picon
Favicon

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 +0000, 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.1&view=markup
> plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/gnome-extra/hardware-monitor/hardware-monitor-1.4.3.ebuild?rev=1.1&content-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 <eva <at> gentoo.org>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane