From patrys at pld-linux.org  Wed Aug  1 21:07:35 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Wed, 1 Aug 2007 21:07:35 +0200
Subject: packaging rules
Message-ID: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>

Is there anything against switching all NameObsoletes (Obsoletes: gdm
in kdm etc.) to conflicts or dropping them altogether?

I am the admin and I want to decide what to install with what. If I
want 2 login managers, that's my problem, if I want 3 smtp services,
that's my problem.

Secondly, all managers except poldek try to "upgrade" gdm to kdm and
vice-versa, exim to postfix and back etc.

Obsoletes is there to mean "that package is no longer supported," not
"mutually exclusive, replace as you wish."

-- 
Patryk Zawadzki
Generated Content


From dhubleizh at o2.pl  Wed Aug  1 22:06:04 2007
From: dhubleizh at o2.pl (=?UTF-8?Q?Cezary_Krzy=C5=BCanowski?=)
Date: Wed, 1 Aug 2007 22:06:04 +0200
Subject: packaging rules
In-Reply-To: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
Message-ID: <416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>

2007/8/1, Patryk Zawadzki <patrys at pld-linux.org>:
>
> Is there anything against switching all NameObsoletes (Obsoletes: gdm
> in kdm etc.) to conflicts or dropping them altogether?
>
> I am the admin and I want to decide what to install with what. If I
> want 2 login managers, that's my problem, if I want 3 smtp services,
> that's my problem.
>

I'd suggest a help notice (I'm not sure is it possible with rpm -- I'd say
poldek had to do it, as one of the nice features that drag ppl to us
(mmazur(tm))). Something like:
"You are trying to install package %{name} which provides %{provides}, but
you've already have a package providing %{provides} installed in your
system: %{packages_having_the_provided_thing_list}.

If you'd like to install it anyway use the --force option.

Remember you have to manually configure the %{name} package to have it
working side by side with %{packages_having_the_provided_thing_list}."

That + implementing + 4 policies in poldek (automatically force,
automatically ignore without error, automatically fail with error (the
present poldeks behaviour), ask the user). I *think* some further checking
is needed, as there will happen situation, when the conflict macro means
that the packages literally can't be installed in the same system
side-by-side.

Cz at rny
-- 
"Fear leads to anger, anger leads to hate, hate leads to suffering" - Yoda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </mailman/pipermail/pld-devel-en/attachments/20070801/9c1cdc29/attachment.htm>

From qboosh at pld-linux.org  Wed Aug  1 22:35:58 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 1 Aug 2007 22:35:58 +0200
Subject: packaging rules
In-Reply-To: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
Message-ID: <20070801203558.GA811@stranger.qboosh.pl>

On Wed, Aug 01, 2007 at 09:07:35PM +0200, Patryk Zawadzki wrote:
> Is there anything against switching all NameObsoletes (Obsoletes: gdm
> in kdm etc.) to conflicts or dropping them altogether?
>
> I am the admin and I want to decide what to install with what. If I
> want 2 login managers, that's my problem, if I want 3 smtp services,
> that's my problem.

If you want to drop Obsoletes/Conflicts, make packages installable
together. If some packages conflict in rpm sense (i.e. have conflicting
files), packages should have proper Obsoletes or Conflicts tags.
Leaving users with --force is not an option.

If some packages are easily switchable replacements, Conflicts behaves
worse, because disallows to atomically replace package.

feature-Provides+Obsoletes is some solution, but causes problems with
old packages which didn't Provide given feature.

> Secondly, all managers except poldek try to "upgrade" gdm to kdm and
> vice-versa, exim to postfix and back etc.

I feel "all" really means yum (including its UIs)

> Obsoletes is there to mean "that package is no longer supported," not
> "mutually exclusive, replace as you wish."

In distros which don't provide alternative packages.
Or use "alternatives" mechanism, like Debian.


-- 
Jakub Bogusz    http://qboosh.pl/


From dhubleizh at o2.pl  Wed Aug  1 23:22:45 2007
From: dhubleizh at o2.pl (=?UTF-8?Q?Cezary_Krzy=C5=BCanowski?=)
Date: Wed, 1 Aug 2007 23:22:45 +0200
Subject: packaging rules
In-Reply-To: <20070801203558.GA811@stranger.qboosh.pl>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
	<20070801203558.GA811@stranger.qboosh.pl>
Message-ID: <416d9d70708011422u5e1a32bfq92cc761d9622aa61@mail.gmail.com>

2007/8/1, Jakub Bogusz <qboosh at pld-linux.org>:
>
>
> Leaving users with --force is not an option.


Why? It's a clear solution: Something conflicts, like default installs of
apache/lighttpd (or any other -- I'm not referring to this particular pair)
conflicting on the 80 port. You get "If you really now what you're doing do
a force". What's the problem? With good preconfigured poldek extensions You
wan't feel a difference! A bonus is that NU won't hang themselves while
trying to install something and getting something uninstalled behind theri
backs.

If some packages are easily switchable replacements, Conflicts behaves
> worse, because disallows to atomically replace package.
>
> True -- this is a neat feature, but logically it sucks -- a package
obsoletes something it provides. Maybe ask Jeff for some help? A new tag, or
mode?


I feel "all" really means yum (including its UIs)


smart, apt-rpm afaik

In distros which don't provide alternative packages.


We clearly do

Or use "alternatives" mechanism, like Debian.


That's not an option -- you don't want to have *one from a group* behavior,
but *all in a group* behavior, like all www servers at once!

Cz at rny
-- 
"Fear leads to anger, anger leads to hate, hate leads to suffering" - Yoda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </mailman/pipermail/pld-devel-en/attachments/20070801/6f0139ed/attachment.htm>

From aredridel at nbtsc.org  Wed Aug  1 23:23:57 2007
From: aredridel at nbtsc.org (Aredridel)
Date: Wed, 01 Aug 2007 15:23:57 -0600
Subject: packaging rules
In-Reply-To: <416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
	<416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>
Message-ID: <1186003437.23125.9.camel@localhost>

On Wed, 2007-08-01 at 22:06 +0200, Cezary Krzy?anowski wrote:
> 
> 2007/8/1, Patryk Zawadzki <patrys at pld-linux.org>:
>         Is there anything against switching all NameObsoletes
>         (Obsoletes: gdm
>         in kdm etc.) to conflicts or dropping them altogether?
>         
>         I am the admin and I want to decide what to install with what.
>         If I
>         want 2 login managers, that's my problem, if I want 3 smtp
>         services, 
>         that's my problem.
> 
> I'd suggest a help notice (I'm not sure is it possible with rpm -- I'd
> say poldek had to do it, as one of the nice features that drag ppl to
> us (mmazur(tm))). Something like: 
> "You are trying to install package %{name} which provides %{provides},
> but you've already have a package providing %{provides} installed in
> your system: %{packages_having_the_provided_thing_list}.
> 
> If you'd like to install it anyway use the --force option. 
> 
> Remember you have to manually configure the %{name} package to have it
> working side by side with %{packages_having_the_provided_thing_list}."
> 
> That + implementing + 4 policies in poldek (automatically force,
> automatically ignore without error, automatically fail with error (the
> present poldeks behaviour), ask the user). I *think* some further
> checking is needed, as there will happen situation, when the conflict
> macro means that the packages literally can't be installed in the same
> system side-by-side. 

Using just Provides: makes so much sense to me -- I've wished I could
have both installed at once several times without upgrades semi-silently
removing one. (An arch developer asked me yesterday how PLD handled
this.)

Aria
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: </mailman/pipermail/pld-devel-en/attachments/20070801/f20b342f/attachment.sig>

From patrys at pld-linux.org  Thu Aug  2 14:46:10 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Thu, 2 Aug 2007 14:46:10 +0200
Subject: packaging rules
In-Reply-To: <1186003437.23125.9.camel@localhost>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
	<416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>
	<1186003437.23125.9.camel@localhost>
Message-ID: <89b6ba3a0708020546k1e89ae68nfd48d9e25a5d016c@mail.gmail.com>

On 8/1/07, Aredridel <aredridel at nbtsc.org> wrote:
> Using just Provides: makes so much sense to me -- I've wished I could
> have both installed at once several times without upgrades semi-silently
> removing one. (An arch developer asked me yesterday how PLD handled
> this.)

That's what I wanted to do. Leave the provides for features and only
use conflicts where it's not possible to have both packages (but
conflicts per name, not per feature).

-- 
Patryk Zawadzki
Generated Content


From patrys at pld-linux.org  Fri Aug  3 18:48:09 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Fri, 3 Aug 2007 18:48:09 +0200
Subject: packaging rules
In-Reply-To: <89b6ba3a0708020546k1e89ae68nfd48d9e25a5d016c@mail.gmail.com>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
	<416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>
	<1186003437.23125.9.camel@localhost>
	<89b6ba3a0708020546k1e89ae68nfd48d9e25a5d016c@mail.gmail.com>
Message-ID: <89b6ba3a0708030948o2f292e12g378b8d0b54799f2f@mail.gmail.com>

So, is there anything against using feature-provides and conflicts
(only for really conflicting packages)?

Old packages should not be a problem if we rebuild all affected software.

-- 
Patryk Zawadzki
Generated Content


From wrobell at pld-linux.org  Sun Aug  5 22:01:40 2007
From: wrobell at pld-linux.org (wrobell)
Date: Sun, 5 Aug 2007 21:01:40 +0100
Subject: vim languages
Message-ID: <20070805200140.GA9662@borg>

speaking about ruby/python/tcl/perl support in vim.

i would like to switch off above languages support by default
(as it was almost always before, excluding perl for some reasons).

if one needs support for specific language, then please create new
subpackage (i.e. vim-python).

the reason is that i doubt that any of us writes scripts in *all*
above languages for vim. but if one really needs all of them, then
please create vim-lang-all (or something).

any comments?

regards,

    wrobell <wrobell at pld-linux.org>


From blues at pld-linux.org  Mon Aug  6 10:42:33 2007
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Mon, 6 Aug 2007 10:42:33 +0200 (CEST)
Subject: vim languages
In-Reply-To: <20070805200140.GA9662@borg>
References: <20070805200140.GA9662@borg>
Message-ID: <Pine.LNX.4.64N.0708061039590.9041@fgnss.gnfx.tqn.cy>

On Sun, 5 Aug 2007, wrobell wrote:
> speaking about ruby/python/tcl/perl support in vim.
> 
> i would like to switch off above languages support by default (as it was 
> almost always before, excluding perl for some reasons).
> 
> if one needs support for specific language, then please create new 
> subpackage (i.e. vim-python).
> 
> the reason is that i doubt that any of us writes scripts in *all* above 
> languages for vim. but if one really needs all of them, then please 
> create vim-lang-all (or something).
> 
> any comments?

Only two:
- additional package have to be build from the same spec to have every 
  type of vims in sync. Otherwise all of that will fail.
- please, look at debian. They have something like that...

-- 
pozdr.  Pawel Golaszewski          jid:blues<at>jabber<dot>gda<dot>pl
--------------------------------------------------------------------------
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.


From mmazur at kernel.pl  Mon Aug  6 17:42:33 2007
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Mon, 6 Aug 2007 17:42:33 +0200
Subject: vim languages
In-Reply-To: <20070805200140.GA9662@borg>
References: <20070805200140.GA9662@borg>
Message-ID: <200708061742.33256.mmazur@kernel.pl>

Dnia niedziela, 5 sierpnia 2007, wrobell napisa?:
> speaking about ruby/python/tcl/perl support in vim.
>
> i would like to switch off above languages support by default
> (as it was almost always before, excluding perl for some reasons).
>
> if one needs support for specific language, then please create new
> subpackage (i.e. vim-python).
>
> the reason is that i doubt that any of us writes scripts in *all*
> above languages for vim. but if one really needs all of them, then
> please create vim-lang-all (or something).
>
> any comments?

The basic packages should be 'low reqs' and 'high reqs' (which translates 
to -- no langs and all langs). Anything in between should be left to ppl 
directly interested.

I'm not however sure whether calling it 'vim-lang-all' is the right choice. It 
sounds kind of counterintuitive. The whole 'vim-lang' also sounds too far 
fetched -- I seriously doubt anyone's going to actually create 
those 'vim-langs', so imho it'll be better to call the full version vim-full, 
vim-loaded, or 'vim-whatever'. (Anyone got any bright ideas?)


-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From blues at pld-linux.org  Tue Aug  7 09:53:25 2007
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Tue, 7 Aug 2007 09:53:25 +0200 (CEST)
Subject: vim languages
In-Reply-To: <200708061742.33256.mmazur@kernel.pl>
References: <20070805200140.GA9662@borg> <200708061742.33256.mmazur@kernel.pl>
Message-ID: <Pine.LNX.4.64N.0708070948500.9041@fgnss.gnfx.tqn.cy>

On Mon, 6 Aug 2007, Mariusz Mazur wrote:
> > any comments?
> The basic packages should be 'low reqs' and 'high reqs' (which 
> translates to -- no langs and all langs). Anything in between should be 
> left to ppl directly interested.

"All-or-nothing" isn't the best choice...
I think that there should be 3 possibilities:
- vim like in current packages we know. It would be nice to keep it.
- vim-tiny (or minimal) - for monks
- vim-full - for those who like all the bells and whistles

> I'm not however sure whether calling it 'vim-lang-all' is the right choice. It 
> sounds kind of counterintuitive. The whole 'vim-lang' also sounds too far 
> fetched -- I seriously doubt anyone's going to actually create 
> those 'vim-langs', so imho it'll be better to call the full version vim-full, 
> vim-loaded, or 'vim-whatever'. (Anyone got any bright ideas?)

Debians choice:
vim - Vi IMproved - enhanced vi editor
vim-addon-manager - manager of addons for the Vim editor
vim-common - Vi IMproved - Common files
vim-doc - Vi IMproved - HTML documentation
vim-full - Vi IMproved - enhanced vi editor - full fledged version
vim-gnome - Vi IMproved - enhanced vi editor - with GNOME2 GUI
vim-gtk - Vi IMproved - enhanced vi editor - with GTK2 GUI
vim-gui-common - Vi IMproved - Common GUI files
vim-latexsuite - View, edit and compile LaTeX documents from within vim
vim-lesstif - Vi IMproved - enhanced vi editor - with LessTif GUI
vim-perl - Vi IMproved - enhanced vi editor - with Perl support
vim-python - Vi IMproved - enhanced vi editor - with Python support
vim-ruby - Vi IMproved - enhanced vi editor - with Ruby support
vim-runtime - Vi IMproved - Runtime files
vim-scripts - plugins for vim, adding bells and whistles
vim-syntax-gtk - Syntax files to highlight gtk+ keywords in vim
vim-tcl - Vi IMproved - enhanced vi editor - with TCL support
vim-tiny - Vi IMproved - enhanced vi editor - compact version
vim-vimoutliner - script for building an outline editor on top of Vim
vimhelp-fr - Vi IMproved - Documentation files (French translation)



-- 
pozdr.  Pawel Golaszewski          jid:blues<at>jabber<dot>gda<dot>pl
--------------------------------------------------------------------------
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.


From mmazur at kernel.pl  Tue Aug  7 13:30:02 2007
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Tue, 7 Aug 2007 13:30:02 +0200
Subject: vim languages
In-Reply-To: <Pine.LNX.4.64N.0708070948500.9041@fgnss.gnfx.tqn.cy>
References: <20070805200140.GA9662@borg> <200708061742.33256.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708070948500.9041@fgnss.gnfx.tqn.cy>
Message-ID: <200708071330.02410.mmazur@kernel.pl>

Dnia wtorek, 7 sierpnia 2007, Pawel Golaszewski napisa?:
> On Mon, 6 Aug 2007, Mariusz Mazur wrote:
> > > any comments?
> >
> > The basic packages should be 'low reqs' and 'high reqs' (which
> > translates to -- no langs and all langs). Anything in between should be
> > left to ppl directly interested.
>
> "All-or-nothing" isn't the best choice...
> I think that there should be 3 possibilities:
> - vim like in current packages we know. It would be nice to keep it.
> - vim-tiny (or minimal) - for monks
> - vim-full - for those who like all the bells and whistles

What's the difference between current vim and vim-full?


-- 
Oceniaj innych po zamiarach, a siebie po wynikach.
                                                                 Guy Kawasaki
Wykszta?cenie jest rzecz? godn? podziwu, acz dobrze czasem
pami?ta?, ?e niczego, co warto wiedzie?, nie da si? kogo? nauczy?.
                                                                  Oscar Wilde


From wrobell at pld-linux.org  Tue Aug  7 15:31:00 2007
From: wrobell at pld-linux.org (wrobell)
Date: Tue, 7 Aug 2007 14:31:00 +0100
Subject: vim languages
In-Reply-To: <200708071330.02410.mmazur@kernel.pl>
References: <20070805200140.GA9662@borg> <200708061742.33256.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708070948500.9041@fgnss.gnfx.tqn.cy>
	<200708071330.02410.mmazur@kernel.pl>
Message-ID: <20070807133100.GA3032@borg>

On Tue, Aug 07, 2007 at 01:30:02PM +0200, Mariusz Mazur wrote:
> Dnia wtorek, 7 sierpnia 2007, Pawel Golaszewski napisa?:
> > On Mon, 6 Aug 2007, Mariusz Mazur wrote:
> > > > any comments?
> > >
> > > The basic packages should be 'low reqs' and 'high reqs' (which
> > > translates to -- no langs and all langs). Anything in between should be
> > > left to ppl directly interested.
> >
> > "All-or-nothing" isn't the best choice...
> > I think that there should be 3 possibilities:
> > - vim like in current packages we know. It would be nice to keep it.
> > - vim-tiny (or minimal) - for monks
> > - vim-full - for those who like all the bells and whistles
> 
> What's the difference between current vim and vim-full?

current vim shall not be "full". for very long period of time there were no
complaints because of vim "non-fullness" if i remember well :]

maybe everyone is on holidays now, but it seems that switching off
languages is ok for now. if somebody needs all of them, then... vim-full?

regards,

    wrobell <wrobell at pld-linux.org>


From patrys at pld-linux.org  Tue Aug  7 15:34:33 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 7 Aug 2007 15:34:33 +0200
Subject: vim languages
In-Reply-To: <20070807133100.GA3032@borg>
References: <20070805200140.GA9662@borg> <200708061742.33256.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708070948500.9041@fgnss.gnfx.tqn.cy>
	<200708071330.02410.mmazur@kernel.pl> <20070807133100.GA3032@borg>
Message-ID: <89b6ba3a0708070634i679c45f9w76946dfdb082ffa9@mail.gmail.com>

On 8/7/07, wrobell <wrobell at pld-linux.org> wrote:
> current vim shall not be "full". for very long period of time there were no
> complaints because of vim "non-fullness" if i remember well :]

I use a custom build with python.

> maybe everyone is on holidays now, but it seems that switching off
> languages is ok for now. if somebody needs all of them, then... vim-full?

Why switch off all languages? Minimalistic vim is called vim-static.

-- 
Patryk Zawadzki
Generated Content


From wrobell at pld-linux.org  Tue Aug  7 15:53:43 2007
From: wrobell at pld-linux.org (wrobell)
Date: Tue, 7 Aug 2007 14:53:43 +0100
Subject: vim languages
In-Reply-To: <89b6ba3a0708070634i679c45f9w76946dfdb082ffa9@mail.gmail.com>
References: <20070805200140.GA9662@borg> <200708061742.33256.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708070948500.9041@fgnss.gnfx.tqn.cy>
	<200708071330.02410.mmazur@kernel.pl> <20070807133100.GA3032@borg>
	<89b6ba3a0708070634i679c45f9w76946dfdb082ffa9@mail.gmail.com>
Message-ID: <20070807135343.GE3032@borg>

On Tue, Aug 07, 2007 at 03:34:33PM +0200, Patryk Zawadzki wrote:
> On 8/7/07, wrobell <wrobell at pld-linux.org> wrote:
> > current vim shall not be "full". for very long period of time there were no
> > complaints because of vim "non-fullness" if i remember well :]
>
> I use a custom build with python.

well.. me too, so maybe you and me should create vim-python package.

> > maybe everyone is on holidays now, but it seems that switching off
> > languages is ok for now. if somebody needs all of them, then... vim-full?
>
> Why switch off all languages?

imho, nobody needs such cow (see my first e-mail, please). i really do not
see why i should have ruby (or tcl) installed for vim only. and if i reckon
well we do not have any package in CVS, which uses ruby on vim level. for
python you have at least bicyclerepairman.

> Minimalistic vim is called vim-static.

but i do not want minimalistic vim.

regards,

    wrobell <wrobell at pld-linux.org>




From mmazur at kernel.pl  Tue Aug  7 15:53:37 2007
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Tue, 7 Aug 2007 15:53:37 +0200
Subject: vim languages
In-Reply-To: <89b6ba3a0708070634i679c45f9w76946dfdb082ffa9@mail.gmail.com>
References: <20070805200140.GA9662@borg> <20070807133100.GA3032@borg>
	<89b6ba3a0708070634i679c45f9w76946dfdb082ffa9@mail.gmail.com>
Message-ID: <200708071553.37186.mmazur@kernel.pl>

Dnia wtorek, 7 sierpnia 2007, Patryk Zawadzki napisa?:
> > maybe everyone is on holidays now, but it seems that switching off
> > languages is ok for now. if somebody needs all of them, then... vim-full?
>
> Why switch off all languages? Minimalistic vim is called vim-static.

No, that's a static vim, not a minimalistic vim. We've already figured that 
one out.

-- 
Oceniaj innych po zamiarach, a siebie po wynikach.
                                                                 Guy Kawasaki
Wykszta?cenie jest rzecz? godn? podziwu, acz dobrze czasem
pami?ta?, ?e niczego, co warto wiedzie?, nie da si? kogo? nauczy?.
                                                                  Oscar Wilde


From mmazur at kernel.pl  Tue Aug  7 17:16:12 2007
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Tue, 7 Aug 2007 17:16:12 +0200
Subject: vim languages
In-Reply-To: <20070807135343.GE3032@borg>
References: <20070805200140.GA9662@borg>
	<89b6ba3a0708070634i679c45f9w76946dfdb082ffa9@mail.gmail.com>
	<20070807135343.GE3032@borg>
Message-ID: <200708071716.12471.mmazur@kernel.pl>

Dnia wtorek, 7 sierpnia 2007, wrobell napisa?:
> imho, nobody needs such cow (see my first e-mail, please). i really do not
> see why i should have ruby (or tcl) installed for vim only. and if i reckon
> well we do not have any package in CVS, which uses ruby on vim level. for
> python you have at least bicyclerepairman.

Because, as far as admin work goes, you just install the software and not use 
it. So yes, having both perl and python users is quite common.


-- 
Judge others by their intentions and yourself by your results.
                                                                 Guy Kawasaki
Education is an admirable thing, but it is well to remember from
time to time that nothing that is worth knowing can be taught.
                                                                  Oscar Wilde


From blues at pld-linux.org  Tue Aug  7 20:31:48 2007
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Tue, 7 Aug 2007 20:31:48 +0200 (CEST)
Subject: vim languages
In-Reply-To: <200708071330.02410.mmazur@kernel.pl>
References: <20070805200140.GA9662@borg> <200708061742.33256.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708070948500.9041@fgnss.gnfx.tqn.cy>
	<200708071330.02410.mmazur@kernel.pl>
Message-ID: <Pine.LNX.4.64N.0708072030570.4434@fgnss.gnfx.tqn.cy>

On Tue, 7 Aug 2007, Mariusz Mazur wrote:
> > > > any comments?
> > > The basic packages should be 'low reqs' and 'high reqs' (which
> > > translates to -- no langs and all langs). Anything in between should be
> > > left to ppl directly interested.
> >
> > "All-or-nothing" isn't the best choice...
> > I think that there should be 3 possibilities:
> > - vim like in current packages we know. It would be nice to keep it.
> > - vim-tiny (or minimal) - for monks
> > - vim-full - for those who like all the bells and whistles
> What's the difference between current vim and vim-full?

AFAIR current vim has only perl enabled by default.
Or only perl was enabled some time ago...

-- 
pozdr.  Pawel Golaszewski          jid:blues<at>jabber<dot>gda<dot>pl
--------------------------------------------------------------------------
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.


From qboosh at pld-linux.org  Tue Aug  7 21:16:29 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 7 Aug 2007 21:16:29 +0200
Subject: vim languages
In-Reply-To: <Pine.LNX.4.64N.0708072030570.4434@fgnss.gnfx.tqn.cy>
References: <20070805200140.GA9662@borg> <200708061742.33256.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708070948500.9041@fgnss.gnfx.tqn.cy>
	<200708071330.02410.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708072030570.4434@fgnss.gnfx.tqn.cy>
Message-ID: <20070807191629.GA30721@stranger.qboosh.pl>

On Tue, Aug 07, 2007 at 08:31:48PM +0200, Pawel Golaszewski wrote:
> On Tue, 7 Aug 2007, Mariusz Mazur wrote:
> > > > > any comments?
> > > > The basic packages should be 'low reqs' and 'high reqs' (which
> > > > translates to -- no langs and all langs). Anything in between should be
> > > > left to ppl directly interested.
> > >
> > > "All-or-nothing" isn't the best choice...
> > > I think that there should be 3 possibilities:
> > > - vim like in current packages we know. It would be nice to keep it.
> > > - vim-tiny (or minimal) - for monks
> > > - vim-full - for those who like all the bells and whistles
> > What's the difference between current vim and vim-full?
> 
> AFAIR current vim has only perl enabled by default.
> Or only perl was enabled some time ago...

So maybe let's enable perl and python, keeping tcl and ruby disabled
until someone proves that (s)he really needs them.


-- 
Jakub Bogusz    http://qboosh.pl/


From qboosh at pld-linux.org  Tue Aug  7 21:24:20 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 7 Aug 2007 21:24:20 +0200
Subject: packaging rules
In-Reply-To: <89b6ba3a0708030948o2f292e12g378b8d0b54799f2f@mail.gmail.com>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
	<416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>
	<1186003437.23125.9.camel@localhost>
	<89b6ba3a0708020546k1e89ae68nfd48d9e25a5d016c@mail.gmail.com>
	<89b6ba3a0708030948o2f292e12g378b8d0b54799f2f@mail.gmail.com>
Message-ID: <20070807192420.GB30721@stranger.qboosh.pl>

On Fri, Aug 03, 2007 at 06:48:09PM +0200, Patryk Zawadzki wrote:
> So, is there anything against using feature-provides and conflicts
> (only for really conflicting packages)?
> 
> Old packages should not be a problem if we rebuild all affected software.

It is a problem as just rebuilding them don't force installing them on all
existing machines. In such cases I propose changing package name Obsoletes
to Conflicts: package-name < (E:V-R before Provides has been added).

Also, you found a set of packages which are really mutually exclusive
and installing more than one makes no sense: issue*. Just dropping
Obsoletes makes an unresolved conflict in distribution (try poldek
--verify=fileconflicts). I think P+O: issue-package (literally, virtual
package with that name) is the way to go (keeping in mind previous
paragraph).


-- 
Jakub Bogusz    http://qboosh.pl/


From n3npq at mac.com  Tue Aug  7 21:36:41 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Tue, 7 Aug 2007 15:36:41 -0400
Subject: packaging rules
In-Reply-To: <20070807192420.GB30721@stranger.qboosh.pl>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
	<416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>
	<1186003437.23125.9.camel@localhost>
	<89b6ba3a0708020546k1e89ae68nfd48d9e25a5d016c@mail.gmail.com>
	<89b6ba3a0708030948o2f292e12g378b8d0b54799f2f@mail.gmail.com>
	<20070807192420.GB30721@stranger.qboosh.pl>
Message-ID: <42BCEF24-0465-4E03-B1A8-C08BE1FC76AC@mac.com>


On Aug 7, 2007, at 3:24 PM, Jakub Bogusz wrote:

> On Fri, Aug 03, 2007 at 06:48:09PM +0200, Patryk Zawadzki wrote:
>> So, is there anything against using feature-provides and conflicts
>> (only for really conflicting packages)?
>>
>> Old packages should not be a problem if we rebuild all affected  
>> software.
>
> It is a problem as just rebuilding them don't force installing them  
> on all
> existing machines. In such cases I propose changing package name  
> Obsoletes
> to Conflicts: package-name < (E:V-R before Provides has been added).
>

If you want Conflicts: behavior instead of Obsoletes: (or vice  
versa), its rather
trivial, like max 200 lines of code, to attach underlying semantic  
attributes, like persistence (ala Conflicts)
with discovery/autoerasenewer (like Obsoletes:).

All I ask is a a clear consensus on what is desired in rpm ;-)

> Also, you found a set of packages which are really mutually exclusive
> and installing more than one makes no sense: issue*. Just dropping
> Obsoletes makes an unresolved conflict in distribution (try poldek
> --verify=fileconflicts). I think P+O: issue-package (literally,  
> virtual
> package with that name) is the way to go (keeping in mind previous
> paragraph).
>

And? Try --exclude=/bin/sh and see what breaks. Non-closure, or  
enforcing
mutually exclusive, ain't exactly rocket science. Indeed, its an if  
statement
somewhere.

hth

73 de Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2205 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070807/df2c69e5/attachment.p7s>

From qboosh at pld-linux.org  Tue Aug  7 23:00:04 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 7 Aug 2007 23:00:04 +0200
Subject: packaging rules
In-Reply-To: <42BCEF24-0465-4E03-B1A8-C08BE1FC76AC@mac.com>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
	<416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>
	<1186003437.23125.9.camel@localhost>
	<89b6ba3a0708020546k1e89ae68nfd48d9e25a5d016c@mail.gmail.com>
	<89b6ba3a0708030948o2f292e12g378b8d0b54799f2f@mail.gmail.com>
	<20070807192420.GB30721@stranger.qboosh.pl>
	<42BCEF24-0465-4E03-B1A8-C08BE1FC76AC@mac.com>
Message-ID: <20070807210003.GA31327@stranger.qboosh.pl>

On Tue, Aug 07, 2007 at 03:36:41PM -0400, Jeff Johnson wrote:
> On Aug 7, 2007, at 3:24 PM, Jakub Bogusz wrote:
>> On Fri, Aug 03, 2007 at 06:48:09PM +0200, Patryk Zawadzki wrote:
>>> So, is there anything against using feature-provides and conflicts
>>> (only for really conflicting packages)?
>>>
>>> Old packages should not be a problem if we rebuild all affected software.
>>
>> It is a problem as just rebuilding them don't force installing them on all
>> existing machines. In such cases I propose changing package name Obsoletes
>> to Conflicts: package-name < (E:V-R before Provides has been added).
>>
>
> If you want Conflicts: behavior instead of Obsoletes: (or vice versa), its 
> rather
> trivial, like max 200 lines of code, to attach underlying semantic 
> attributes, like persistence (ala Conflicts)
> with discovery/autoerasenewer (like Obsoletes:).
>
> All I ask is a a clear consensus on what is desired in rpm ;-)

Currently we can't make a consensus ourselves ;)
The problem is the meaning of Obsoletes - it used to have two meanings
in PLD:
- some package (A) became is obsolete and new package (B) replaces its
  functionality (clear: A disappears from distro, B becomes available
  with Obsoletes: A)
- a set of packages provide the same functionality and we want at most
  only one of them to be installed (so every package Obsoletes the rest;
  or - since rpm 4.0.x(?) - all packages have Provides:
  some-virtual-provide and Obsoletes: some-virtual-provide)
(and now:
- some people want to be able to install more than one package providing
  similar functionality, like HTTP or SMTP servers)

With first two there was no problem until some higher-level package
managers (like yum) forced the first meaning (only) and started to
randomly replace e.g. SMTP servers with the other one in each run.


If you are willing to code something that helps, my proposal would be (of
course after making consensus in PLD first) to implement some flags for
Obsoletes tag, e.g.:

"Obsoletes(replacement):" (or "Replaces:"?) for mutually exclusive
  packages
"Obsoletes(hint):" ("suggested obsolete") for packages which don't
  physically conflict, but usually aren't installed together (e.g.
  SMTP servers, all configured to listen on the same port by default)

and plain "Obsoletes:" tag would be left for obsolete packages only.


For yum fans: such change in rpm alone probably won't solve anything
with yum, as their maintainers are unlinkely to implement this
(just like Suggests)...

>> Also, you found a set of packages which are really mutually exclusive
>> and installing more than one makes no sense: issue*. Just dropping
>> Obsoletes makes an unresolved conflict in distribution (try poldek
>> --verify=fileconflicts). I think P+O: issue-package (literally, virtual
>> package with that name) is the way to go (keeping in mind previous
>> paragraph).
>>
>
> And? Try --exclude=/bin/sh and see what breaks. Non-closure, or enforcing
> mutually exclusive, ain't exactly rocket science. Indeed, its an if 
> statement
> somewhere.

--exclude=/bin/sh to which program? rpm? I don't see such option...


-- 
Jakub Bogusz    http://qboosh.pl/


From n3npq at mac.com  Wed Aug  8 00:11:44 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Tue, 7 Aug 2007 18:11:44 -0400
Subject: packaging rules
In-Reply-To: <20070807210003.GA31327@stranger.qboosh.pl>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
	<416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>
	<1186003437.23125.9.camel@localhost>
	<89b6ba3a0708020546k1e89ae68nfd48d9e25a5d016c@mail.gmail.com>
	<89b6ba3a0708030948o2f292e12g378b8d0b54799f2f@mail.gmail.com>
	<20070807192420.GB30721@stranger.qboosh.pl>
	<42BCEF24-0465-4E03-B1A8-C08BE1FC76AC@mac.com>
	<20070807210003.GA31327@stranger.qboosh.pl>
Message-ID: <40D85C3F-5F80-4268-A12B-2D67B7FAECDF@mac.com>


On Aug 7, 2007, at 5:00 PM, Jakub Bogusz wrote:

>>
>> All I ask is a a clear consensus on what is desired in rpm ;-)
>
> Currently we can't make a consensus ourselves ;)

You're not alone ...

>
> The problem is the meaning of Obsoletes - it used to have two meanings
> in PLD:
> - some package (A) became is obsolete and new package (B) replaces its
>  functionality (clear: A disappears from distro, B becomes available
>  with Obsoletes: A)

This is what I call "package renaming", and is the reason for Obsoletes:
to get depsolvers snarled up in discovering new and alternative names.

>
> - a set of packages provide the same functionality and we want at most
>  only one of them to be installed (so every package Obsoletes the  
> rest;
>  or - since rpm 4.0.x(?) - all packages have Provides:
>  some-virtual-provide and Obsoletes: some-virtual-provide)
> (and now:

FWIW, other packages can be erased by, say, file path:
     Obsoletes: /usr/lib/lpd
will erase all other printer daemons when installing a new printer  
daemon.

>
> - some people want to be able to install more than one package  
> providing
>  similar functionality, like HTTP or SMTP servers)
>

This is the "alternatives" problem. Why one would want 1-of-N behavior  
has
always eluded me, reinstalling other rpm packages avoids the complexity.

> With first two there was no problem until some higher-level package
> managers (like yum) forced the first meaning (only) and started to
> randomly replace e.g. SMTP servers with the other one in each run.
>

Yup.

>
> If you are willing to code something that helps, my proposal would  
> be (of
> course after making consensus in PLD first) to implement some flags  
> for
> Obsoletes tag, e.g.:
>
> "Obsoletes(replacement):" (or "Replaces:"?) for mutually exclusive
>  packages

I would use something other than a Obsoletes:. Hysterically, RH
package style tried to remove end-of-life software, so the packages
already contained an Obsoletes:. What has always been a pain is
discovering the Newer! Better! Bestest! package that replaces the old  
one.

These days so many packages have been renamed, that virtual Provides:
are quite common, so I'd use
    Provides(hint): oldname
instead of
     Obsoletes(replaces): oldname
with exactly the same semantic interpretation.

>
> "Obsoletes(hint):" ("suggested obsolete") for packages which don't
>  physically conflict, but usually aren't installed together (e.g.
>  SMTP servers, all configured to listen on the same port by default)
>

All dependencies are permitted (hint) qualifiers, including Provides:
Conflicts:, and Obsoletes:. The RPMSENSE_MISSINGOK underlying
semantic just means the rpmlib itself will not do anything special,
like quitting with an error, for those hinted dependencies.

Feel free to add your own semantic interpretation.
> and plain "Obsoletes:" tag would be left for obsolete packages only.
>
>
> For yum fans: such change in rpm alone probably won't solve anything
> with yum, as their maintainers are unlinkely to implement this
> (just like Suggests)...
>
>>> Also, you found a set of packages which are really mutually  
>>> exclusive
>>> and installing more than one makes no sense: issue*. Just dropping
>>> Obsoletes makes an unresolved conflict in distribution (try poldek
>>> --verify=fileconflicts). I think P+O: issue-package (literally,  
>>> virtual
>>> package with that name) is the way to go (keeping in mind previous
>>> paragraph).
>>>
>>
>> And? Try --exclude=/bin/sh and see what breaks. Non-closure, or  
>> enforcing
>> mutually exclusive, ain't exactly rocket science. Indeed, its an if
>> statement
>> somewhere.
>
> --exclude=/bin/sh to which program? rpm? I don't see such option...
>

Gak, I can never remember all the rpm options I never use:

$ rpm --help | grep exclu
   --excludedocs                    do not install documentation
   --excludepath=<path>             skip files with leading component  
<path>

I was referring to --excludepath, which should cause all
     Requires: /bin/sh
to fail to be satisfied, a case of CLI induced non-closure for  
dependencies.

73 de Jeff


From wrobell at pld-linux.org  Wed Aug  8 00:33:19 2007
From: wrobell at pld-linux.org (wrobell)
Date: Tue, 7 Aug 2007 23:33:19 +0100
Subject: vim languages
In-Reply-To: <20070807191629.GA30721@stranger.qboosh.pl>
References: <20070805200140.GA9662@borg> <200708061742.33256.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708070948500.9041@fgnss.gnfx.tqn.cy>
	<200708071330.02410.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708072030570.4434@fgnss.gnfx.tqn.cy>
	<20070807191629.GA30721@stranger.qboosh.pl>
Message-ID: <20070807223319.GA17274@borg>

On Tue, Aug 07, 2007 at 09:16:29PM +0200, Jakub Bogusz wrote:
> On Tue, Aug 07, 2007 at 08:31:48PM +0200, Pawel Golaszewski wrote:
> > On Tue, 7 Aug 2007, Mariusz Mazur wrote:
> > > > > > any comments?
> > > > > The basic packages should be 'low reqs' and 'high reqs' (which
> > > > > translates to -- no langs and all langs). Anything in between should be
> > > > > left to ppl directly interested.
> > > >
> > > > "All-or-nothing" isn't the best choice...
> > > > I think that there should be 3 possibilities:
> > > > - vim like in current packages we know. It would be nice to keep it.
> > > > - vim-tiny (or minimal) - for monks
> > > > - vim-full - for those who like all the bells and whistles
> > > What's the difference between current vim and vim-full?
> > 
> > AFAIR current vim has only perl enabled by default.
> > Or only perl was enabled some time ago...
> 
> So maybe let's enable perl and python, keeping tcl and ruby disabled
> until someone proves that (s)he really needs them.

as i know there is some ruby based outliner in the world... so it will
be required at some stage. but ruby is huge, so having it by default...

i am from python camp... but on other side i can understand people who use
ruby and hate python for some reason. having it just to use vim is sick,
too.

what is even strange... try one of 'help {tcl,perl,python,ruby,mzscheme}-dynamic'
and you will find at the very end of help file, that windows based build
supports dynamic library loading. crap.

regards,

    wrobell <wrobell at pld-linux.org>


From patrys at pld-linux.org  Wed Aug  8 13:55:11 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Wed, 8 Aug 2007 13:55:11 +0200
Subject: packaging rules
In-Reply-To: <20070807192420.GB30721@stranger.qboosh.pl>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
	<416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>
	<1186003437.23125.9.camel@localhost>
	<89b6ba3a0708020546k1e89ae68nfd48d9e25a5d016c@mail.gmail.com>
	<89b6ba3a0708030948o2f292e12g378b8d0b54799f2f@mail.gmail.com>
	<20070807192420.GB30721@stranger.qboosh.pl>
Message-ID: <89b6ba3a0708080455w1ee0eaa3k830232e921676b48@mail.gmail.com>

On 8/7/07, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> On Fri, Aug 03, 2007 at 06:48:09PM +0200, Patryk Zawadzki wrote:
> > So, is there anything against using feature-provides and conflicts
> > (only for really conflicting packages)?
> >
> > Old packages should not be a problem if we rebuild all affected software.
>
> It is a problem as just rebuilding them don't force installing them on all
> existing machines. In such cases I propose changing package name Obsoletes
> to Conflicts: package-name < (E:V-R before Provides has been added).
>
> Also, you found a set of packages which are really mutually exclusive
> and installing more than one makes no sense: issue*. Just dropping
> Obsoletes makes an unresolved conflict in distribution (try poldek
> --verify=fileconflicts). I think P+O: issue-package (literally, virtual
> package with that name) is the way to go (keeping in mind previous
> paragraph).

Added versioned Conflicts where possible. Can't add C: issue < 2.99-2
as they were and are all providing "issue."

I could drop the provide but I'm not sure if anything requires or
required that in Ac/Th.

-- 
Patryk Zawadzki
Generated Content


From wrobell at pld-linux.org  Fri Aug 10 22:09:47 2007
From: wrobell at pld-linux.org (wrobell)
Date: Fri, 10 Aug 2007 21:09:47 +0100
Subject: mono, gtk
Message-ID: <20070810200947.GN17274@borg>

when i try to load tomboy on ppc at th (latest stuff on ftp), then it fails
with stacktrace

    Native stacktrace:

            [0x10121384]
            [0x100350]
            [0x7f8f9c88]
            /lib/libc.so.6(abort+0x230) [0xfcba0f0]
            /usr/lib/libglib-2.0.so.0(g_logv+0x41c) [0xff522f8]
            /usr/lib/libglib-2.0.so.0(g_log+0x6c) [0xff52378]
            /usr/lib/libglib-2.0.so.0(g_assert_warning+0x8c) [0xff52414]
            [0x10127b8c]
            [0x1012783c]
            [0x10127d3c]
            [0x100350]
            [(nil)]


any hints? does it work on other platforms?

when i switch back to mono 1.3.x, then it works perfectly.

regards,

    wrobell <wrobell at pld-linux.org>


From wrobell at pld-linux.org  Fri Aug 10 22:24:54 2007
From: wrobell at pld-linux.org (wrobell)
Date: Fri, 10 Aug 2007 21:24:54 +0100
Subject: mono, gtk
In-Reply-To: <20070810200947.GN17274@borg>
References: <20070810200947.GN17274@borg>
Message-ID: <20070810202454.GO17274@borg>

On Fri, Aug 10, 2007 at 09:09:47PM +0100, wrobell wrote:
> when i try to load tomboy on ppc at th (latest stuff on ftp), then it fails
> with stacktrace
> 
>     Native stacktrace:
> 
>             [0x10121384]
>             [0x100350]
>             [0x7f8f9c88]
>             /lib/libc.so.6(abort+0x230) [0xfcba0f0]
>             /usr/lib/libglib-2.0.so.0(g_logv+0x41c) [0xff522f8]
>             /usr/lib/libglib-2.0.so.0(g_log+0x6c) [0xff52378]
>             /usr/lib/libglib-2.0.so.0(g_assert_warning+0x8c) [0xff52414]
>             [0x10127b8c]
>             [0x1012783c]
>             [0x10127d3c]
>             [0x100350]
>             [(nil)]
> 
> 
> any hints? does it work on other platforms?
> 
> when i switch back to mono 1.3.x, then it works perfectly.

f-spot fails in the same way. works whith mono 1.3.x, though.

regards,

    wrobell <wrobell at pld-linux.org>


From tommat at pimpek.one.pl  Sat Aug 11 11:45:08 2007
From: tommat at pimpek.one.pl (Tomasz Mateja)
Date: Sat, 11 Aug 2007 11:45:08 +0200
Subject: [Th/sparc] rpm + db4.6
Message-ID: <46BD8524.9030007@pimpek.one.pl>

Since the  db4.6 rpm on sparc seems not to work:

[root at moon RPMS]# rpm --rebuilddb
Bus error
[root at moon RPMS]# rpm --rebuilddb
rpmdb: unable to join the environment
error: db4 error(11) from dbenv->open: Resource temporarily unavailable
error: cannot open Packages index using db3 - Resource temporarily 
unavailable (11)

-- 
T.


From wrobell at pld-linux.org  Sat Aug 11 13:05:36 2007
From: wrobell at pld-linux.org (wrobell)
Date: Sat, 11 Aug 2007 12:05:36 +0100
Subject: [Th/sparc] rpm + db4.6
In-Reply-To: <46BD8524.9030007@pimpek.one.pl>
References: <46BD8524.9030007@pimpek.one.pl>
Message-ID: <20070811110536.GQ17274@borg>

On Sat, Aug 11, 2007 at 11:45:08AM +0200, Tomasz Mateja wrote:
> Since the  db4.6 rpm on sparc seems not to work:
> 
> [root at moon RPMS]# rpm --rebuilddb
> Bus error
> [root at moon RPMS]# rpm --rebuilddb
> rpmdb: unable to join the environment
> error: db4 error(11) from dbenv->open: Resource temporarily unavailable
> error: cannot open Packages index using db3 - Resource temporarily 
> unavailable (11)

have you tried to remove /var/lib/rpm/__db* locks before rebuilding
database?

    wrobell <wrobell at pld-linux.org>


From tommat at pimpek.one.pl  Sat Aug 11 13:11:23 2007
From: tommat at pimpek.one.pl (Tomasz Mateja)
Date: Sat, 11 Aug 2007 13:11:23 +0200
Subject: [Th/sparc] rpm + db4.6
In-Reply-To: <20070811110536.GQ17274@borg>
References: <46BD8524.9030007@pimpek.one.pl> <20070811110536.GQ17274@borg>
Message-ID: <46BD995B.2070000@pimpek.one.pl>

wrobell napisa?(a):
> On Sat, Aug 11, 2007 at 11:45:08AM +0200, Tomasz Mateja wrote:
>> Since the  db4.6 rpm on sparc seems not to work:
>>
>> [root at moon RPMS]# rpm --rebuilddb
>> Bus error
>> [root at moon RPMS]# rpm --rebuilddb
>> rpmdb: unable to join the environment
>> error: db4 error(11) from dbenv->open: Resource temporarily unavailable
>> error: cannot open Packages index using db3 - Resource temporarily 
>> unavailable (11)
> 
> have you tried to remove /var/lib/rpm/__db* locks before rebuilding
> database?
sure - that was my first shot,
but even with only Packages left it is not working, strange but on 
sparc64 everything is ok. (no compilation without -fpie wont help on sparc)

-- 
T.


From wolf.pld at gmail.com  Sat Aug 11 14:49:10 2007
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Sat, 11 Aug 2007 14:49:10 +0200
Subject: mono, gtk
In-Reply-To: <20070810202454.GO17274@borg>
References: <20070810200947.GN17274@borg> <20070810202454.GO17274@borg>
Message-ID: <20070811124910.GA3613@bajzel>

On Fri, Aug 10, 2007 at 09:24:54PM +0100, wrobell wrote:
> > when i switch back to mono 1.3.x, then it works perfectly.
> f-spot fails in the same way. works whith mono 1.3.x, though.
What mono 1.3.x?

wolf
-- 
  Bartek   .  
  Taudul   :  
          .:....................................................................
w o l f @ p l d - l i n u x . o r g            .:. http://wolf.valkyrie.one.pl/


From wrobell at pld-linux.org  Sat Aug 11 14:55:25 2007
From: wrobell at pld-linux.org (wrobell)
Date: Sat, 11 Aug 2007 13:55:25 +0100
Subject: mono, gtk
In-Reply-To: <20070811124910.GA3613@bajzel>
References: <20070810200947.GN17274@borg> <20070810202454.GO17274@borg>
	<20070811124910.GA3613@bajzel>
Message-ID: <20070811125525.GR17274@borg>

On Sat, Aug 11, 2007 at 02:49:10PM +0200, Bartosz Taudul wrote:
> On Fri, Aug 10, 2007 at 09:24:54PM +0100, wrobell wrote:
> > > when i switch back to mono 1.3.x, then it works perfectly.
> > f-spot fails in the same way. works whith mono 1.3.x, though.
> What mono 1.3.x?

sorry, mono 1.2.3.1

    wrobell <wrobell at pld-linux.org>


From mlukaszek at gmail.com  Wed Aug 15 15:24:48 2007
From: mlukaszek at gmail.com (=?ISO-8859-2?Q?Micha=B3_=A3ukaszek?=)
Date: Wed, 15 Aug 2007 15:24:48 +0200
Subject: Poldek regression - upgrade for different archs
Message-ID: <cfcac88a0708150624w15acdccpfcc8fd3cf42d10b4@mail.gmail.com>

This was already working some time ago, now it's broken again.

[prism at prism ~]$ alias po
alias po='poldek -n th -n th-test'
[prism at prism ~]$ LANG=C po -n th-i686 -n th-test-i686
Loading [pndir]th...
Loading [pndir]th...
Loading [pndir]th-test...
Loading [pndir]th-test...
Loading [pndir]th-i686...
Loading [pndir]th-test-i686...
26235 packages read
Loading [rpmdbcache]/var/lib/rpm...
972 packages loaded

Welcome to the poldek shell mode. Type "help" for help with commands.

poldek:/all-avail> llu glib2-*
available
      installed                 build date
            size
glib2-2.14.0-1.i686
      2.12.13-1.i686            2007/08/14 20:05
      2.5 MB
glib2-2.14.0-1.x86_64
      2.12.13-1.x86_64          2007/08/14 22:57
      2.6 MB
glib2-devel-2.14.0-1.x86_64
      2.12.13-1.x86_64          2007/08/14 22:57
    549.0 KB
3 packages, 5.6 MB

poldek:/all-avail> upgrade glib2-*
Processing dependencies...
glib2-2.12.13-1.i686 obsoleted by glib2-2.14.0-1.i686
There are 1 package to install, 1 to remove:
I glib2-2.14.0-1.i686
R glib2-2.12.13-1.i686
Need to get 543.3KB of archives. After unpacking 2.5MB will be used.
Executing sudo /bin/rpm --upgrade -vh --root / --noorder...
Preparing...                ########################################### [100%]
        file /usr/share/locale/am/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ar/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/az/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/be/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/be at latin/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/bg/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/bn/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/bn_IN/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/bs/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ca/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/cs/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/cy/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/da/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/de/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/dz/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/el/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/en_CA/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/en_GB/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/eo/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/es/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/et/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/eu/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/fa/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/fi/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/fr/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ga/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/gl/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/gu/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/he/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/hi/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/hr/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/hu/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/hy/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/id/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/is/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/it/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ja/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ka/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ko/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ku/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/lt/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/lv/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/mk/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ml/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/mn/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ms/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/nb/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ne/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/nl/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/nn/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/or/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/pa/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/pl/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/pt/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/pt_BR/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ro/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ru/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/rw/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/sk/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/sl/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/sq/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/sr/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/sr at Latn/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/sr at ije/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/sv/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/ta/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/te/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/th/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/tl/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/tr/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/tt/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/uk/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/vi/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/wa/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/xh/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/yi/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/zh_CN/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/zh_HK/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
        file /usr/share/locale/zh_TW/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.i686 conflicts with file from package
glib2-2.12.13-1.x86_64
Installing set #2
Processing dependencies...
glib2-devel-2.12.13-1.x86_64 obsoleted by glib2-devel-2.14.0-1.x86_64
glib2-2.12.13-1.x86_64 obsoleted by glib2-2.14.0-1.x86_64
There are 2 packages to install, 2 to remove:
I glib2-2.14.0-1.x86_64, glib2-devel-2.14.0-1.x86_64
R glib2-2.12.13-1.x86_64, glib2-devel-2.12.13-1.x86_64
Need to get 716.8KB of archives. After unpacking 3.1MB will be used.
Executing sudo /bin/rpm --upgrade -vh --root / --noorder...
Preparing...                ########################################### [100%]
        file /usr/share/locale/am/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ar/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/az/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/be/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/be at latin/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/bg/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/bn/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/bn_IN/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/bs/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ca/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/cs/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/cy/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/da/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/de/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/dz/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/el/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/en_CA/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/en_GB/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/eo/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/es/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/et/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/eu/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/fa/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/fi/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/fr/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ga/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/gl/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/gu/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/he/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/hi/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/hr/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/hu/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/hy/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/id/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/is/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/it/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ja/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ka/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ko/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ku/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/lt/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/lv/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/mk/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ml/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/mn/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ms/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/nb/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ne/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/nl/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/nn/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/or/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/pa/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/pl/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/pt/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/pt_BR/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ro/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ru/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/rw/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/sk/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/sl/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/sq/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/sr/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/sr at Latn/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/sr at ije/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/sv/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/ta/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/te/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/th/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/tl/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/tr/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/tt/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/uk/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/vi/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/wa/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/xh/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/yi/LC_MESSAGES/glib20.mo from install
of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/zh_CN/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/zh_HK/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
        file /usr/share/locale/zh_TW/LC_MESSAGES/glib20.mo from
install of glib2-2.14.0-1.x86_64 conflicts with file from package
glib2-2.12.13-1.i686
There were errors
poldek:/all-avail>

When done manually:
poldek:/all-avail> get glib2-2.14.0-1.x86_64 glib2-2.14.0-1.i686
glib2-devel-2.14.0-1.x86_64
Retrieving th-test-i686::glib2-2.14.0-1.i686.rpm...
.............................. 100.0% [543.3K (54.1K/s)]
Retrieving th-test::glib2-2.14.0-1.x86_64.rpm...
.............................. 100.0% [587.1K (55.4K/s)]
Retrieving th-test::glib2-devel-2.14.0-1.x86_64.rpm...
.............................. 100.0% [129.7K (42.1K/s)]
poldek:/all-avail>
[prism at prism ~]$ LANG=C sudo rpm -Uhv glib2-*
Preparing...                ########################################### [100%]
Repackaging...
   1:glib2                  ########################################### [ 33%]
   2:glib2                  ########################################### [ 67%]
   3:glib2-devel            ########################################### [100%]
Upgrading...
   1:glib2                  ########################################### [ 33%]
   2:glib2-devel            ########################################### [ 67%]
   3:glib2                  ########################################### [100%]
[prism at prism ~]$

-- 
regards,
Micha? ?ukaszek
prism at pld-linux.org

From tommat at pimpek.one.pl  Sun Aug 19 11:55:31 2007
From: tommat at pimpek.one.pl (Tomasz Mateja)
Date: Sun, 19 Aug 2007 11:55:31 +0200
Subject: [Th/sparc] rpm + db4.6
In-Reply-To: <46BD995B.2070000@pimpek.one.pl>
References: <46BD8524.9030007@pimpek.one.pl> <20070811110536.GQ17274@borg>
	<46BD995B.2070000@pimpek.one.pl>
Message-ID: <46C81393.8040001@pimpek.one.pl>

Tomasz Mateja napisa?(a):
> wrobell napisa?(a):
>> On Sat, Aug 11, 2007 at 11:45:08AM +0200, Tomasz Mateja wrote:
>>> Since the  db4.6 rpm on sparc seems not to work:
>>>
>>> [root at moon RPMS]# rpm --rebuilddb
>>> Bus error
>>> [root at moon RPMS]# rpm --rebuilddb
>>> rpmdb: unable to join the environment
>>> error: db4 error(11) from dbenv->open: Resource temporarily unavailable
>>> error: cannot open Packages index using db3 - Resource temporarily 
>>> unavailable (11)
>> have you tried to remove /var/lib/rpm/__db* locks before rebuilding
>> database?
> sure - that was my first shot,
> but even with only Packages left it is not working, strange but on 
> sparc64 everything is ok. (no compilation without -fpie wont help on sparc)
> 
It works with current db 4.6.19 it has fixed some unaligned access to 
memory.

-- 
T.


From n3npq at mac.com  Sun Aug 19 16:14:14 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 19 Aug 2007 10:14:14 -0400
Subject: [Th/sparc] rpm + db4.6
In-Reply-To: <46C81393.8040001@pimpek.one.pl>
References: <46BD8524.9030007@pimpek.one.pl> <20070811110536.GQ17274@borg>
	<46BD995B.2070000@pimpek.one.pl> <46C81393.8040001@pimpek.one.pl>
Message-ID: <7476E227-D0EC-4C2B-8A60-80A8D8A19ACC@mac.com>


On Aug 19, 2007, at 5:55 AM, Tomasz Mateja wrote:

>>
> It works with current db 4.6.19 it has fixed some unaligned access to
> memory.
>

Good to know there was a reason for upgrading to db-4.6.19 on rpm HEAD
last week. ;-)

FWIW, the db-4.6.19 release notes say
...

PATCHED IN RELEASE 4.6.19

[#15643]    Bus errors with 32-bit builds on 64-bit machines
[#15644]    Configuring a database for MVCC ignored in Java API
[#15651]    Bug in rep_backup.c deref'ing null ptr
[#15388]    Client with priority 0 elected in 2-site group

73 de Jeff


From arkadiusz.machol at gmail.com  Mon Aug 20 19:26:36 2007
From: arkadiusz.machol at gmail.com (=?ISO-8859-2?Q?Arkadiusz_Macho=B3?=)
Date: Mon, 20 Aug 2007 19:26:36 +0200
Subject: [SPECS] Several updates.
Message-ID: <5ac9d7250708201026q59a1452cq3e0d931b340ddddc@mail.gmail.com>

I've attached a few updates.
kernel-net-sch_srr.spec Fix compilation problem on 2.6.22 kernels
l7-protocols.spec updated to latest set of filters
squid.spec updated to latest stable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </mailman/pipermail/pld-devel-en/attachments/20070820/e55279af/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-net-sch_srr.spec.HEAD.diff
Type: application/octet-stream
Size: 761 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070820/e55279af/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: l7-protocols.spec.HEAD.diff
Type: application/octet-stream
Size: 777 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070820/e55279af/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: squid.spec.HEAD.diff
Type: application/octet-stream
Size: 675 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070820/e55279af/attachment-0002.obj>

From glen at delfi.ee  Mon Aug 20 20:45:00 2007
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Mon, 20 Aug 2007 21:45:00 +0300
Subject: [SPECS] Several updates.
In-Reply-To: <5ac9d7250708201026q59a1452cq3e0d931b340ddddc@mail.gmail.com>
References: <5ac9d7250708201026q59a1452cq3e0d931b340ddddc@mail.gmail.com>
Message-ID: <200708202145.01066.glen@delfi.ee>

On Monday 20 August 2007 20:26, Arkadiusz Macho? wrote:
> I've attached a few updates.
> kernel-net-sch_srr.spec Fix compilation problem on 2.6.22 kernels
> l7-protocols.spec updated to latest set of filters
> squid.spec updated to latest stable

applied.

-- 
glen


From dhubleizh at o2.pl  Tue Aug 21 13:31:05 2007
From: dhubleizh at o2.pl (Cezary Krzyzanowski)
Date: Tue, 21 Aug 2007 13:31:05 +0200
Subject: vim languages
In-Reply-To: <20070807191629.GA30721@stranger.qboosh.pl>
References: <20070805200140.GA9662@borg> <200708061742.33256.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708070948500.9041@fgnss.gnfx.tqn.cy>
	<200708071330.02410.mmazur@kernel.pl>
	<Pine.LNX.4.64N.0708072030570.4434@fgnss.gnfx.tqn.cy>
	<20070807191629.GA30721@stranger.qboosh.pl>
Message-ID: <1187695865.4276.38.camel@ipv6-localnet>

Dnia 07-08-2007, Wt o godzinie 21:16 +0200, Jakub Bogusz napisa?(a):
> > AFAIR current vim has only perl enabled by default.
> > Or only perl was enabled some time ago...
> 
> So maybe let's enable perl and python, keeping tcl and ruby disabled
> until someone proves that (s)he really needs them.

C'mon -- You must see it's bullshit. What better argument is "I like to
code in python -- please enable python" then "I've got a working perl
solution that needs perl"

That is not a solution.

I'd gladly do a vim + vim-{python,perl,ruby,you_name_it} package, but
vim's architecture isn't plugin like. The debians vims are just
different executables compiled with different languages. To choose what
is called when You type vim is made by alternatives mechanism in
debians.

Any other ideas then making 150 different binaries?

Cz at rny



From dhubleizh at o2.pl  Tue Aug 21 13:42:52 2007
From: dhubleizh at o2.pl (Cezary Krzyzanowski)
Date: Tue, 21 Aug 2007 13:42:52 +0200
Subject: packaging rules
In-Reply-To: <20070807210003.GA31327@stranger.qboosh.pl>
References: <89b6ba3a0708011207q3c4b0003s6091a3475787092@mail.gmail.com>
	<416d9d70708011306v7285bab7kf930d2ba30efebc8@mail.gmail.com>
	<1186003437.23125.9.camel@localhost>
	<89b6ba3a0708020546k1e89ae68nfd48d9e25a5d016c@mail.gmail.com>
	<89b6ba3a0708030948o2f292e12g378b8d0b54799f2f@mail.gmail.com>
	<20070807192420.GB30721@stranger.qboosh.pl>
	<42BCEF24-0465-4E03-B1A8-C08BE1FC76AC@mac.com>
	<20070807210003.GA31327@stranger.qboosh.pl>
Message-ID: <1187696572.4276.47.camel@ipv6-localnet>

Dnia 07-08-2007, Wt o godzinie 23:00 +0200, Jakub Bogusz napisa?(a):

> For yum fans: such change in rpm alone probably won't solve anything
> with yum, as their maintainers are unlinkely to implement this
> (just like Suggests)...

I belive we should not care bout that. I think if we already think of
our selves as avant-garde in terms of rpm usage *and* Jeff is there
reading and considering the changes we should not think back on what
other supporters will do. Red hat mainly doesn't care bout giving yum
new possibilities, but let's focus what *we* want. And maybe, that's
*maybe* other will follow, like Mandriva or Yast from Novell?

Let's focus on finding a reasonable and constant solution for the three
scenarios (the old->new package, the conflicting scenarios like issue
and the alternatives scenario like www daemon), poke Jeff to approve the
'our' way in the next rpm and then poke mis to make poldek use the
semantics we've chosen.

Patching yum and smart *shouldn't* (I know -- I'm not declaring to do
that, but I'm making statements ;/) be too much of trouble. AFAIR
(please don't yell Patrys) Patrys said he'll keep the suggesting patches
to yum, so maybe we'll (again an emtpy we) manage to keep another
package giving the wanted behavior in both yum and smart. 

Cz at rny



From wojciech at blaszkowski.com  Tue Aug 21 16:50:11 2007
From: wojciech at blaszkowski.com (Wojciech =?utf-8?q?B=C5=82aszkowski?=)
Date: Tue, 21 Aug 2007 16:50:11 +0200
Subject: SPECS: kernel-desktop.spec | patch85
Message-ID: <200708211650.11407@wojtosz>


additional info about what a patch85 does.

Pozdrawiam, Best regards, Mit freundlichen Gr??en,
--
Wojciech "Wojtosz" B?aszkowski
www.blaszkowski.com
GSM: +48 600 197 207
JID: wojtosz at jabber.biz.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-desktop.patch
Type: text/x-diff
Size: 863 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070821/dc8bd5f1/attachment.bin>

From adamg at biomerieux.pl  Tue Aug 21 17:10:13 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Tue, 21 Aug 2007 17:10:13 +0200
Subject: SPECS: kernel-desktop.spec | patch85
In-Reply-To: <200708211650.11407@wojtosz>
References: <200708211650.11407@wojtosz>
Message-ID: <20070821151013.GB18879@mysza.eu.org>

On Tue, Aug 21, 2007 at 04:50:11PM +0200, Wojciech B?aszkowski wrote:
> 
> additional info about what a patch85 does.

applied, thanks.


-- 
 http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
   PLD Linux developer    | Everybody needs some solid rock, I know I do.


From qboosh at pld-linux.org  Wed Aug 22 20:42:52 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 22 Aug 2007 20:42:52 +0200
Subject: SPECS: avahi.spec - add selinux BR and R
In-Reply-To: <SPECS_avahi.spec.1.74@pld-linux.org>
References: <SPECS_avahi.spec.1.73@pld-linux.org>
	<SPECS_avahi.spec.1.74@pld-linux.org>
Message-ID: <20070822184252.GA20711@stranger.qboosh.pl>

On Wed, Aug 22, 2007 at 08:16:13PM +0200, aredridel wrote:
> Author: aredridel                    Date: Wed Aug 22 18:16:13 2007 GMT
> Module: SPECS                         Tag: HEAD
> ---- Log message:
> - add selinux BR and R

That's bogus, just grep -r avahi sources - no matches.
And avahi libs aren't even indirectly linked with libselinux.


-- 
Jakub Bogusz    http://qboosh.pl/


From adamg at biomerieux.pl  Thu Aug 23 11:55:05 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Thu, 23 Aug 2007 11:55:05 +0200
Subject: db and rpm db
Message-ID: <20070823095505.GC4699@mysza.eu.org>

This happened to me twice today:


--------------------
Installing set #9
Processing dependencies...
db4.6-4.6.18-1.i686 obsoleted by db4.6-4.6.19-1.i686
There are 1 package to install, 1 to remove:
I db4.6-4.6.19-1.i686
R db4.6-4.6.18-1.i686
Need to get 417.5KB of archives (417.5KB to download).
After unpacking 1.1MB will be used.
Retrieving th-test::db4.6-4.6.19-1.i686.rpm...
.............................. 100.0% [417.5K (243.2K/s)]
Executing rpm --upgrade -vh --root / --noorder...
Preparing...                ########################################### [100%]
   1:db4.6                  ########################################### [100%]
Installing set #10
Processing dependencies...
SysVinit-2.86-9.i686 obsoleted by SysVinit-2.86-10.i686
There are 1 package to install, 1 to remove:
I SysVinit-2.86-10.i686
R SysVinit-2.86-9.i686
Need to get 240.2KB of archives (240.2KB to download).
After unpacking 302.3KB will be used.
Retrieving th-test::SysVinit-2.86-10.i686.rpm...
.............................. 100.0% [240.2K (240.2K/s)]
Executing rpm --upgrade -vh --root / --noorder...
pmdb: munmap: Invalid argument
rpmdb: munmap: Invalid argument
rpmdb: munmap: Invalid argument
rpmdb: munmap: Invalid argument
rpmdb: unable to join the environment
error: db4 error(11) from dbenv->open: Resource temporarily unavailable
error: cannot open Packages index using db3 - Resource temporarily unavailable (11)
error: cannot open Packages database in /var/lib/rpm

-----------------------

rpm --rebuilddb seems to fix this issue (I didn't try removing __db*). 
Perhaps some trigger in db-4.6.19? Is it possible to do `rpm --rebuilddb' in %post?

-- 
 http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
   PLD Linux developer    | Everybody needs some solid rock, I know I do.


From patrys at pld-linux.org  Thu Aug 23 12:54:20 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Thu, 23 Aug 2007 12:54:20 +0200
Subject: db and rpm db
In-Reply-To: <20070823095505.GC4699@mysza.eu.org>
References: <20070823095505.GC4699@mysza.eu.org>
Message-ID: <89b6ba3a0708230354x3c9679cclf12751fca759422d@mail.gmail.com>

On 8/23/07, Adam Go??biowski <adamg at biomerieux.pl> wrote:
> This happened to me twice today:

Happened to me yesterday.

> rpm --rebuilddb seems to fix this issue (I didn't try removing __db*).
> Perhaps some trigger in db-4.6.19? Is it possible to do `rpm --rebuilddb' in %post?

rebuilddb resulted in exactly the same messages. Then I downgraded
db4.6 and rpm was working again.

-- 
Patryk Zawadzki
Generated Content

From qboosh at pld-linux.org  Thu Aug 23 13:16:18 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 23 Aug 2007 13:16:18 +0200
Subject: db and rpm db
In-Reply-To: <20070823095505.GC4699@mysza.eu.org>
References: <20070823095505.GC4699@mysza.eu.org>
Message-ID: <20070823111618.GA30145@mail>

On Thu, Aug 23, 2007 at 11:55:05AM +0200, Adam Go??biowski wrote:
> This happened to me twice today:

> Executing rpm --upgrade -vh --root / --noorder...
> pmdb: munmap: Invalid argument
> rpmdb: munmap: Invalid argument
> rpmdb: munmap: Invalid argument
> rpmdb: munmap: Invalid argument
> rpmdb: unable to join the environment
> error: db4 error(11) from dbenv->open: Resource temporarily unavailable
> error: cannot open Packages index using db3 - Resource temporarily unavailable (11)
> error: cannot open Packages database in /var/lib/rpm
> 
> -----------------------
> 
> rpm --rebuilddb seems to fix this issue (I didn't try removing __db*). 

The same for me, rm __db* was sufficient.


-- 
Jakub Bogusz    http://qboosh.pl/


From patrys at pld-linux.org  Thu Aug 23 13:19:14 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Thu, 23 Aug 2007 13:19:14 +0200
Subject: db and rpm db
In-Reply-To: <20070823111618.GA30145@mail>
References: <20070823095505.GC4699@mysza.eu.org> <20070823111618.GA30145@mail>
Message-ID: <89b6ba3a0708230419i77f09640qd50fc302d8c8f29d@mail.gmail.com>

On 8/23/07, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> On Thu, Aug 23, 2007 at 11:55:05AM +0200, Adam Go??biowski wrote:
> > rpm --rebuilddb seems to fix this issue (I didn't try removing __db*).
> The same for me, rm __db* was sufficient.

Is it possible to remove it by a trigger? Triggers are run in the
middle of transaction and removing transaction state might have
unpredictable results. Maybe we need a macro that tells rpm to clean
after itself when upgrading:

%post
%mark_rpm_db_for_flush or something?

Jeff?

-- 
Patryk Zawadzki
Generated Content

From n3npq at mac.com  Thu Aug 23 14:42:04 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Thu, 23 Aug 2007 08:42:04 -0400
Subject: Fwd: db and rpm db
References: <7FFCC5AE-A11E-4990-B066-C443182129DE@mac.com>
Message-ID: <97022F50-A45C-4AD4-AB94-1B9ECBADAF2D@mac.com>



Begin forwarded message:

>
> On Aug 23, 2007, at 7:19 AM, Patryk Zawadzki wrote:
>
>> On 8/23/07, Jakub Bogusz <qboosh at pld-linux.org> wrote:
>>> On Thu, Aug 23, 2007 at 11:55:05AM +0200, Adam Go??biowski wrote:
>>>> rpm --rebuilddb seems to fix this issue (I didn't try removing  
>>>> __db*).
>>> The same for me, rm __db* was sufficient.
>>
>> Is it possible to remove it by a trigger? Triggers are run in the
>> middle of transaction and removing transaction state might have
>> unpredictable results. Maybe we need a macro that tells rpm to clean
>> after itself when upgrading:
>>
>
> Handling an error from an open db cache while changing the db  
> implementation
> should not be done in db %post. For starters, you will find the  
> dbenv always in use
> by rpm --upgrade.
>
> A trigger on db change could be added to the rpm package, but triggers
> are run in the middle of a transaction, with an open/live db cache,  
> and that
> may cause a similar problem.
>
> Does poldek have a dbenv open between invocations of rpm --upgrade?
> Closing and reopening the rpmdb in poldek will be needed as well if  
> you
> wish to invalidate the old cache in a dbenv while upgrading db.
>
> All that is known atm is that a "rm -f /var/lib/rpm/__db* on a  
> likely quiescent
> dbenv "fixes" the symptoms.
>
> 73 de Jeff



From qboosh at pld-linux.org  Thu Aug 23 17:07:10 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 23 Aug 2007 17:07:10 +0200
Subject: Fwd: db and rpm db
In-Reply-To: <97022F50-A45C-4AD4-AB94-1B9ECBADAF2D@mac.com>
References: <7FFCC5AE-A11E-4990-B066-C443182129DE@mac.com>
	<97022F50-A45C-4AD4-AB94-1B9ECBADAF2D@mac.com>
Message-ID: <20070823150710.GA19275@stranger.qboosh.pl>

On Thu, Aug 23, 2007 at 08:42:04AM -0400, Jeff Johnson wrote:
> Begin forwarded message:
> > On Aug 23, 2007, at 7:19 AM, Patryk Zawadzki wrote:
> >
> >> On 8/23/07, Jakub Bogusz <qboosh at pld-linux.org> wrote:
> >>> On Thu, Aug 23, 2007 at 11:55:05AM +0200, Adam Go??biowski wrote:
> >>>> rpm --rebuilddb seems to fix this issue (I didn't try removing  
> >>>> __db*).
> >>> The same for me, rm __db* was sufficient.
> >>
> >> Is it possible to remove it by a trigger? Triggers are run in the
> >> middle of transaction and removing transaction state might have
> >> unpredictable results. Maybe we need a macro that tells rpm to clean
> >> after itself when upgrading:
> >>
> >
> > Handling an error from an open db cache while changing the db  
> > implementation
> > should not be done in db %post. For starters, you will find the  
> > dbenv always in use
> > by rpm --upgrade.
> >
> > A trigger on db change could be added to the rpm package, but triggers
> > are run in the middle of a transaction, with an open/live db cache,  
> > and that
> > may cause a similar problem.
> >
> > Does poldek have a dbenv open between invocations of rpm --upgrade?
> > Closing and reopening the rpmdb in poldek will be needed as well if  
> > you
> > wish to invalidate the old cache in a dbenv while upgrading db.
> >
> > All that is known atm is that a "rm -f /var/lib/rpm/__db* on a  
> > likely quiescent
> > dbenv "fixes" the symptoms.

In my case database wasn't open - rpm finished its work after db4.6
upgrade, and failed when I ran it again to upgrade some other package.
I didn't use poldek during all those operations, just pure rpm
invocations from bash.


-- 
Jakub Bogusz    http://qboosh.pl/


From n3npq at mac.com  Thu Aug 23 17:21:33 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Thu, 23 Aug 2007 11:21:33 -0400
Subject: db and rpm db
In-Reply-To: <20070823150710.GA19275@stranger.qboosh.pl>
References: <7FFCC5AE-A11E-4990-B066-C443182129DE@mac.com>
	<97022F50-A45C-4AD4-AB94-1B9ECBADAF2D@mac.com>
	<20070823150710.GA19275@stranger.qboosh.pl>
Message-ID: <C7CEF3D4-2F51-4378-A4D1-1DA431ED01A8@mac.com>


On Aug 23, 2007, at 11:07 AM, Jakub Bogusz wrote:

> On Thu, Aug 23, 2007 at 08:42:04AM -0400, Jeff Johnson wrote:
>
> In my case database wasn't open - rpm finished its work after db4.6
> upgrade, and failed when I ran it again to upgrade some other package.
> I didn't use poldek during all those operations, just pure rpm
> invocations from bash.
>

Ah, that helps.

A trigger to fire
     rm -f /var/lib/rpm/__db
automagically when Berkeley DB is upgraded is then likely viable.

OTOH, insturmenting a trigger for a one tome 4.6.18 -> 4.6.19 problem
that is fixed by doing
     rm -f /var/lib/rpm/__db*
is perhaps overkill.

What is likely deficient is that the dbenv internals have changed  
incompatibly
between 4.6.18 -> 4.6.19. An incompatibility would normally be  
handled by rev'ing
the version stamp, but the incompatible change is not being tracked  
by the current
version stamp of "4.6".

In other words, changing Berkeley DB to version stamp a dbenv as
"4.6.18" and "4.6.19" rather than "4.6" might be the best fix of all.

hth

73 de Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2205 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070823/9efbbe1a/attachment.p7s>

From patrys at pld-linux.org  Fri Aug 24 13:15:51 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Fri, 24 Aug 2007 13:15:51 +0200
Subject: Splash screens
Message-ID: <89b6ba3a0708240415o5a674d30gbd16c2e6ac40399b@mail.gmail.com>

Is there any blessed or supported way to inject new splash screens
(and generally any piece of software) to be run either from initrd or
rc.sysinit level?

Ideally I'd request pluggable code support (initramfs-tools from
debian) but anything will do. I'd like to make usplash and splashy
work with PLD.

-- 
Patryk Zawadzki
Generated Content


From deejay1 at srem.org  Fri Aug 24 16:37:35 2007
From: deejay1 at srem.org (=?iso-8859-2?q?=A3ukasz_Jerna=B6?=)
Date: Fri, 24 Aug 2007 16:37:35 +0200
Subject: Splash screens
In-Reply-To: <89b6ba3a0708240415o5a674d30gbd16c2e6ac40399b@mail.gmail.com>
References: <89b6ba3a0708240415o5a674d30gbd16c2e6ac40399b@mail.gmail.com>
Message-ID: <200708241637.36837.deejay1@srem.org>

Dnia pi?tek, 24 sierpnia 2007, Patryk Zawadzki napisa?:
> Is there any blessed or supported way to inject new splash screens
> (and generally any piece of software) to be run either from initrd or
> rc.sysinit level?

AFAIK no, but you can make one and I will bless it ;>

-- 
?ukasz [DeeJay1] Jerna?


From gotar at polanet.pl  Mon Aug 27 12:36:53 2007
From: gotar at polanet.pl (Tomasz Pala)
Date: Mon, 27 Aug 2007 12:36:53 +0200
Subject: [th] qt4 problems
In-Reply-To: <200706180915.03756.zswi@pers.pl>
References: <20070616154052.GA16077@pepin.polanet.pl>
	<200706180915.03756.zswi@pers.pl>
Message-ID: <20070827103653.GA16114@pepin.polanet.pl>

On Mon, Jun 18, 2007 at 09:15:03AM +0200, Rafa? Cygnarowski wrote:
> >
> > 1. closing any qt4 application (e.g. kpoldek) crashes entire X server,

It was icewm's segfault in 1.2.25 (and probably others), 1.2.30 works ok.

> > 2. qt4 doesn't honour fontocnfig setup (doesn't draw through
> >    freetype/cairo/Xft and I've got badly subpixeled fonts) - is it fourth
> >    rendering engine?
> I didn't seen such behaviour. What Qt4 version you use? What is your 
> xorg*drivers*? What about your freetype/cairo/Xft?

QtCore-4.3.0-1
xorg-driver-video-nvidia-100.14.11-1
freetype compiled with LEGACY filter
cairo/Xft uses freetype filter (so it's LEGACY as in vanilla builds)
BCI enabled, autohinter disabled

Everything in my system uses LEGACY (on the right):
http://www.quarto.pl/~gotar/freetype-rgb-matrix.png

However every Qt4 app looks like this:
http://www.quarto.pl/~gotar/qt4.png

anyone familiar with Qt4 can tell me how to switch to legacy filter?

-- 
Tom Pala <gotar at pld-linux.org>           http://vfmg.sourceforge.net/
                                         http://tccs.sourceforge.net/


From glen at pld-linux.org  Tue Aug 28 18:26:15 2007
From: glen at pld-linux.org (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Tue, 28 Aug 2007 19:26:15 +0300
Subject: Fwd: ERRORS: mozilla-firefox.spec
Message-ID: <200708281926.15612.glen@pld-linux.org>

hey

please bring down this secondary *outdated* ac-amd64 builder whoever put it 
online or *fix* it!

-- 
glen
mozilla-firefox.spec (auto-ac-mozilla-firefox-2_0_0_6-1): FAILED

--- mozilla-firefox.spec:auto-ac-mozilla-firefox-2_0_0_6-1:
Build-Time: user:1720.43s sys:294.71s real:3417.91s (faults io:120 
non-io:33348032)



*** buildlog for mozilla-firefox.spec
request from: glen
started at: Tue Aug 28 16:18:16 2007
fetching 
http://ep09.pld-linux.org/~buildsrc/srpms/95b0d9ae-c478-4af1-9e79-13a2b9271a22/mozilla-firefox-2.0.0.6-1.src.rpm
fetched 42470312 bytes, 534.8 K/s
installing srpm: mozilla-firefox-2.0.0.6-1.src.rpm
Building target platforms: amd64-pld-linux
Building for target amd64-pld-linux
checking BR
no BR needed
building RPM using: cd rpm/SPECS; TMPDIR=/tmp/B.6ef8ae nice -n 18 
rpmbuild -bb  --target amd64-pld-linux mozilla-firefox.spec
Building target platforms: amd64-pld-linux
Building for target amd64-pld-linux
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.2431
+ umask 022
+ cd /home/users/builder/rpm/BUILD
+ export LC_ALL=C
+ export LANG=C
+ unset LINGUAS
+ :
+ unset LANGUAGE
+ :
+ unset LC_MESSAGES
+ :
+ unset DISPLAY
+ :
+ cd /home/users/builder/rpm/BUILD
+ rm -rf mozilla-firefox-2.0.0.6
+ /bin/mkdir -p mozilla-firefox-2.0.0.6
+ cd mozilla-firefox-2.0.0.6
+ /usr/bin/bzip2 -dc /home/users/builder/rpm/SOURCES/firefox-2.0.0.6-source.tar.bz2
+ tar -xf -
+ STATUS=0
+ [ 0 -ne 0 ]
+ /usr/bin/unzip -qq /home/users/builder/rpm/SOURCES/tidy_08x_source.zip
+ STATUS=0
+ [ 0 -ne 0 ]
+ /bin/id -u
+ [ 1001 = 0 ]
+ true .
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ mv mozilla_tidy_source/mozilla/extensions/tidy mozilla/extensions/tidy
+ mv mozilla_tidy_source/tidy_extension .
+ rm -rf mozilla/extensions/tidy/opensp
+ cd mozilla
+ echo Patch #0 (mozilla-install.patch):
Patch #0 (mozilla-install.patch):
+ patch -p1 -s
+ < /home/users/builder/rpm/SOURCES/mozilla-install.patch 
+ echo Patch #1 (mozilla-firefox-lib_path.patch):
Patch #1 (mozilla-firefox-lib_path.patch):
+ patch -p1 -s
+ < /home/users/builder/rpm/SOURCES/mozilla-firefox-lib_path.patch 
+ echo Patch #2 (mozilla-firefox-addon-tidy.patch):
Patch #2 (mozilla-firefox-addon-tidy.patch):
+ patch -p1 -s
+ < /home/users/builder/rpm/SOURCES/mozilla-firefox-addon-tidy.patch 
+ echo Patch #3 (mozilla-firefox-nopangoxft.patch):
Patch #3 (mozilla-firefox-nopangoxft.patch):
+ patch -p1 -s
+ < /home/users/builder/rpm/SOURCES/mozilla-firefox-nopangoxft.patch 
+ echo Patch #5 (mozilla-firefox-fonts.patch):
Patch #5 (mozilla-firefox-fonts.patch):
+ patch -p1 -s
+ < /home/users/builder/rpm/SOURCES/mozilla-firefox-fonts.patch 
+ echo Patch #6 (mozilla-firefox-myspell.patch):
Patch #6 (mozilla-firefox-myspell.patch):
+ patch -p1 -s
+ < /home/users/builder/rpm/SOURCES/mozilla-firefox-myspell.patch 
+ echo Patch #7 (mozilla-firefox-agent.patch):
Patch #7 (mozilla-firefox-agent.patch):
+ patch -p1 -s
+ < /home/users/builder/rpm/SOURCES/mozilla-firefox-agent.patch 
+ sed -i s/\(-lgss\)\(\W\)/\1disable\2/ configure
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.3084
+ umask 022
+ cd /home/users/builder/rpm/BUILD
+ cd mozilla-firefox-2.0.0.6
+ export LC_ALL=C
+ export LANG=C
+ unset LINGUAS
+ :
+ unset LANGUAGE
+ :
+ unset LC_MESSAGES
+ :
+ unset DISPLAY
+ :
+ cd mozilla
+ /usr/bin/pkg-config mozilla-nspr --cflags-only-I
+ export CFLAGS=-O2 -fno-strict-aliasing  -I/usr/include/nspr  
+ /usr/bin/pkg-config mozilla-nspr --cflags-only-I
+ export CXXFLAGS=-O2 -fno-strict-aliasing  -I/usr/include/nspr  
+ cp -f /usr/share/automake/config.guess /usr/share/automake/config.sub 
build/autoconf
+ cp -f /usr/share/automake/config.guess /usr/share/automake/config.sub 
nsprpub/build/autoconf
+ cp -f /usr/share/automake/config.guess /usr/share/automake/config.sub 
directory/c-sdk/config/autoconf
+ cat
+ << "EOF" 
+ > .mozconfig 
+ /usr/bin/make -j1 -f client.mk build CC=amd64-pld-linux-gcc 
CXX=amd64-pld-linux-g++


[...]

In file included from SpValid.cpp:26:
/usr/include/OpenSP/InternalInputSource.h:37: error: extra qualification `
   OpenSP::InternalInputSource::' on member `asInternalInputSource' ignored
SpValid.cpp:28:31: OpenSP/lib/Parser.h: No such file or directory
SpValid.h: In constructor `SpValidApp::SpValidApp(SpResult*)':
SpValid.h:45: warning: `SpValidApp::batchMode_' will be initialized after
SpValid.h:43: warning:   `Boolean SpValidApp::prologOnly_'
SpValid.cpp:192: warning:   when initialized here
SpValid.cpp:198: error: `NsgmlsMessages' undeclared (first use this function)
SpValid.cpp:198: error: (Each undeclared identifier is reported only once for 
   each function it appears in.)
SpValid.cpp:198: error: syntax error before `::' token
SpValid.cpp: In member function `virtual void SpValidApp::processOption(char, 
   const char*)':
SpValid.cpp:229: error: syntax error before `::' token
SpValid.cpp:233: error: jump to case label
SpValid.cpp:220: error:   crosses initialization of `Boolean found'
SpValid.cpp:236: error: jump to case label
SpValid.cpp:220: error:   crosses initialization of `Boolean found'
SpValid.cpp:240: error: jump to case label
SpValid.cpp:220: error:   crosses initialization of `Boolean found'
SpValid.cpp:243: error: jump to case label
SpValid.cpp:220: error:   crosses initialization of `Boolean found'
SpValid.cpp:247: error: jump to case label
SpValid.cpp:220: error:   crosses initialization of `Boolean found'
/usr/include/OpenSP/Vector.h: In constructor `OpenSP::Vector<T>::Vector() 
[with 
   T = OpenSP::StringC]':
/usr/include/OpenSP/Attribute.h:57:   instantiated from here
/usr/include/OpenSP/Vector.h:66: warning: `
   OpenSP::Vector<OpenSP::StringC>::ptr_' will be initialized after
/usr/include/OpenSP/Vector.h:65: warning:   `size_t 
   OpenSP::Vector<OpenSP::StringC>::size_'
/usr/include/OpenSP/Vector.h:24: warning:   when initialized here
/usr/include/OpenSP/Vector.h: In constructor `OpenSP::Vector<T>::Vector() 
[with 
   T = OpenSP::LeafContentToken*]':
/usr/include/OpenSP/ContentToken.h:59:   instantiated from here
/usr/include/OpenSP/Vector.h:66: warning: `
   OpenSP::Vector<OpenSP::LeafContentToken*>::ptr_' will be initialized after
/usr/include/OpenSP/Vector.h:65: warning:   `size_t 
   OpenSP::Vector<OpenSP::LeafContentToken*>::size_'
/usr/include/OpenSP/Vector.h:24: warning:   when initialized here
/usr/include/OpenSP/Vector.h: In constructor `OpenSP::Vector<T>::Vector(long 
   unsigned int) [with T = OpenSP::LeafContentToken*]':
/usr/include/OpenSP/ContentToken.h:60:   instantiated from here
/usr/include/OpenSP/Vector.h:66: warning: `
   OpenSP::Vector<OpenSP::LeafContentToken*>::ptr_' will be initialized after
/usr/include/OpenSP/Vector.h:65: warning:   `size_t 
   OpenSP::Vector<OpenSP::LeafContentToken*>::size_'
/usr/include/OpenSP/Vector.h:25: warning:   when initialized here
/usr/include/OpenSP/Vector.h: In constructor `OpenSP::Vector<T>::Vector() 
[with 
   T = OpenSP::Transition]':
/usr/include/OpenSP/ContentToken.h:184:   instantiated from here
/usr/include/OpenSP/Vector.h:66: warning: `
   OpenSP::Vector<OpenSP::Transition>::ptr_' will be initialized after
/usr/include/OpenSP/Vector.h:65: warning:   `size_t 
   OpenSP::Vector<OpenSP::Transition>::size_'
/usr/include/OpenSP/Vector.h:24: warning:   when initialized here
/usr/include/OpenSP/Vector.h: In constructor `OpenSP::Vector<T>::Vector(long 
   unsigned int, const T&) [with T = OpenSP::Ptr<OpenSP::NamedResource>]':
/usr/include/OpenSP/PointerTable.cxx:56:   instantiated from `P 
OpenSP::PointerTable<P, K, HF, KF>::insert(P, bool) [with P = 
OpenSP::Ptr<OpenSP::NamedResource>, K = OpenSP::StringC, HF = OpenSP::Hash, 
KF = OpenSP::NamedResourceKeyFunction]'
/usr/include/OpenSP/NamedResourceTable.h:37:   instantiated from 
`OpenSP::Ptr<T> OpenSP::NamedResourceTable<T>::insert(const OpenSP::Ptr<T>&, 
bool) [with T = OpenSP::Entity]'
/usr/include/OpenSP/Dtd.h:164:   instantiated from here
/usr/include/OpenSP/Vector.h:66: warning: `
   OpenSP::Vector<OpenSP::Ptr<OpenSP::NamedResource> >::ptr_' will be 
   initialized after
/usr/include/OpenSP/Vector.h:65: warning:   `size_t 
   OpenSP::Vector<OpenSP::Ptr<OpenSP::NamedResource> >::size_'
/usr/include/OpenSP/Vector.cxx:35: warning:   when initialized here
/usr/include/OpenSP/Vector.h: In constructor `OpenSP::Vector<T>::Vector(long 
   unsigned int, const T&) [with T = OpenSP::Named*]':
/usr/include/OpenSP/PointerTable.cxx:56:   instantiated from `P 
OpenSP::PointerTable<P, K, HF, KF>::insert(P, bool) [with P = OpenSP::Named*, 
K = OpenSP::StringC, HF = OpenSP::Hash, KF = OpenSP::NamedTableKeyFunction]'
/usr/include/OpenSP/NamedTable.h:28:   instantiated from `T* 
OpenSP::NamedTable<T>::insert(T*) [with T = OpenSP::ElementType]'
/usr/include/OpenSP/Dtd.h:278:   instantiated from here
/usr/include/OpenSP/Vector.h:66: warning: 
`OpenSP::Vector<OpenSP::Named*>::ptr_
   ' will be initialized after
/usr/include/OpenSP/Vector.h:65: warning:   `size_t 
   OpenSP::Vector<OpenSP::Named*>::size_'
/usr/include/OpenSP/Vector.cxx:35: warning:   when initialized here
make[5]: *** [SpValid.o] Error 1
make[5]: Leaving directory 
`/home/users/builder/rpm/BUILD/mozilla-firefox-2.0.0.6/mozilla/extensions/tidy/spvalid'
make[4]: *** [libs] Error 2
make[4]: Leaving directory 
`/home/users/builder/rpm/BUILD/mozilla-firefox-2.0.0.6/mozilla/extensions/tidy'
make[3]: *** [libs] Error 2
make[3]: Leaving directory 
`/home/users/builder/rpm/BUILD/mozilla-firefox-2.0.0.6/mozilla/extensions'
make[2]: *** [tier_99] Error 2
make[2]: Leaving directory 
`/home/users/builder/rpm/BUILD/mozilla-firefox-2.0.0.6/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory 
`/home/users/builder/rpm/BUILD/mozilla-firefox-2.0.0.6/mozilla'
make: *** [build] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.3084 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.3084 (%build)
error: No files produced.
Begin-PLD-Builder-Info
Build-Time: user:1720.43s sys:294.71s real:3417.91s (faults io:120 
non-io:33348032)

End-PLD-Builder-Info


-------------- next part --------------
An embedded message was scrubbed...
From: PLD ac-amd64 builder <builder-ac-amd64 at pld-linux.org>
Subject: ERRORS: mozilla-firefox.spec
Date: Tue, 28 Aug 2007 15:15:18 +0000
Size: 11470
URL: </mailman/pipermail/pld-devel-en/attachments/20070828/397de61a/attachment.eml>

From hawk at limanowa.net  Tue Aug 28 22:24:42 2007
From: hawk at limanowa.net (=?ISO-8859-2?Q?Marcin_Kr=F3l?=)
Date: Tue, 28 Aug 2007 22:24:42 +0200
Subject: Fwd: ERRORS: mozilla-firefox.spec
In-Reply-To: <200708281926.15612.glen@pld-linux.org>
References: <200708281926.15612.glen@pld-linux.org>
Message-ID: <46D4848A.7050408@limanowa.net>

> hey
> 
> please bring down this secondary *outdated* ac-amd64 builder whoever put it 
> online or *fix* it!

The old amd64 builder is not running. Builder account on previous
machine is empty. At least I was told so. We have third amd64 builder? :)

M.


From hawk at limanowa.net  Tue Aug 28 22:30:52 2007
From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=)
Date: Tue, 28 Aug 2007 22:30:52 +0200
Subject: Fwd: ERRORS: mozilla-firefox.spec
In-Reply-To: <46D4848A.7050408@limanowa.net>
References: <200708281926.15612.glen@pld-linux.org>
	<46D4848A.7050408@limanowa.net>
Message-ID: <46D485FC.8050902@limanowa.net>

> The old amd64 builder is not running. Builder account on previous
> machine is empty. At least I was told so. We have third amd64 builder? :)

I'll answer myself. Yes, we may have third builder. The very old one in
old jajcus workplace. However I can't check if its there. Machine is up
but ssh is either not running or firewalled. Jajcus, any chances that
this theory is true?

M.


From patrys at pld-linux.org  Tue Aug 28 22:38:22 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 28 Aug 2007 22:38:22 +0200
Subject: [th] bootsplash + geninitrd
Message-ID: <89b6ba3a0708281338i3595d8f8ga121d8df6b24f7f0@mail.gmail.com>

If I have bootsplash [1] installed and use geninitrd [2] to generate
initramfs for recent kernel [3], the splash initializes fine but I end
up with a kernel panic (unable to mount initrd, tried: romfs).

Why does it think it's romfs? Removing bootsplash (or just unpacking
and repacking which drops trailing data too) fixes the problem.

[1] bootsplash-3.2-3.i686
[2] geninitrd-8682-1.noarch
[3] kernel-2.6.21.7-1.i686

-- 
Patryk Zawadzki
Generated Content


From pluto at agmk.net  Tue Aug 28 23:18:57 2007
From: pluto at agmk.net (=?utf-8?q?Pawe=C5=82_Sikora?=)
Date: Tue, 28 Aug 2007 23:18:57 +0200
Subject: SPECS (TH-branch): samba.spec - rel 2 (glen) [was: pld-cvs-commit
	Digest, Vol 28, Issue 342]
In-Reply-To: <mailman.1614.1188333901.32370.pld-cvs-commit@lists.pld-linux.org>
References: <mailman.1614.1188333901.32370.pld-cvs-commit@lists.pld-linux.org>
Message-ID: <200708282318.58016.pluto@agmk.net>

On Tuesday 28 of August 2007 22:45:01 
>    9. SPECS (TH-branch): samba.spec - rel 2 (glen)

TH-branch? did i miss th-release?

-- 
MIT is like the Paris Hilton of technology universities.
   Every guy knows about it and wants to get inside.


From adamg at biomerieux.pl  Tue Aug 28 23:12:12 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Tue, 28 Aug 2007 23:12:12 +0200
Subject: Fwd: ERRORS: mozilla-firefox.spec
In-Reply-To: <46D485FC.8050902@limanowa.net>
References: <200708281926.15612.glen@pld-linux.org>
	<46D4848A.7050408@limanowa.net> <46D485FC.8050902@limanowa.net>
Message-ID: <20070828211212.GA8125@mysza.eu.org>

On Tue, Aug 28, 2007 at 10:30:52PM +0200, Marcin Kr?l wrote:
> > The old amd64 builder is not running. Builder account on previous
> > machine is empty. At least I was told so. We have third amd64 builder? :)
> 
> I'll answer myself. Yes, we may have third builder. The very old one in
> old jajcus workplace. However I can't check if its there. Machine is up
> but ssh is either not running or firewalled. Jajcus, any chances that
> this theory is true?

Well, according to mail headers these are oberon.pld-linux.org and
rhea.pld-linux.org.

-- 
 http://www.mysza.eu.org/ | Everybody needs someone sure, someone true,
   PLD Linux developer    | Everybody needs some solid rock, I know I do.


From glen at delfi.ee  Wed Aug 29 01:04:30 2007
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Wed, 29 Aug 2007 02:04:30 +0300
Subject: SPECS (TH-branch): samba.spec - rel 2 (glen) [was: pld-cvs-commit
	Digest, Vol 28, Issue 342]
In-Reply-To: <200708282318.58016.pluto@agmk.net>
References: <mailman.1614.1188333901.32370.pld-cvs-commit@lists.pld-linux.org>
	<200708282318.58016.pluto@agmk.net>
Message-ID: <200708290204.30849.glen@delfi.ee>

On Wednesday 29 August 2007 00:18, Pawe? Sikora wrote:
> On Tuesday 28 of August 2007 22:45:01
>
> >    9. SPECS (TH-branch): samba.spec - rel 2 (glen)
>
> TH-branch? did i miss th-release?

wanted rel up on existing samba, but samba at HEAD was broken at that time:

 Diff to: previous 1.369: preferred, colored
 Changes since revision 1.369: +10 -3 lines
- up to 3.0.25c; vscan vfs doesn't build

-- 
glen


From glen at delfi.ee  Tue Aug 28 18:55:25 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Tue, 28 Aug 2007 19:55:25 +0300
Subject: [ac] kde style plastic
Message-ID: <200708281955.25530.glen@delfi.ee>

i've noticed that kde style plastic is gone.
at least with latest updates, but i'm afraid it's gone for long time already

however it seems present in th :(

ac:
kdelibs-3.5.7-2.amd64
kdebase-core-3.5.7-2.amd64

th:
kdelibs-3.5.7-9.i686
kdebase-core-3.5.7-4.i686

i didn't notice the problem with -1 in ac (maybe i had just different style)

-- 
glen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: th-plastic.jpg
Type: image/jpeg
Size: 85411 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070828/77ff05ac/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ac-plastic.jpg
Type: image/jpeg
Size: 83312 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070828/77ff05ac/attachment-0001.jpg>

From glen at delfi.ee  Wed Aug 29 19:12:44 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 29 Aug 2007 20:12:44 +0300
Subject: [ac] kde style plastic
Message-ID: <200708292012.44440.glen@delfi.ee>

i've noticed that kde style plastic is gone.
at least with latest updates, but i'm afraid it's gone for long time already

however it seems present in th :(

ac:
kdelibs-3.5.7-2.amd64
kdebase-core-3.5.7-2.amd64

th:
kdelibs-3.5.7-9.i686
kdebase-core-3.5.7-4.i686

i didn't notice the problem with -1 in ac (maybe i had just different style)

[abram: accept this message ;)]
-- 
glen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: th-plastic.jpg
Type: image/jpeg
Size: 85411 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070829/68b06952/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ac-plastic.jpg
Type: image/jpeg
Size: 83312 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070829/68b06952/attachment-0001.jpg>

From kabasny at gmail.com  Thu Aug 30 15:03:42 2007
From: kabasny at gmail.com (Piotr Maciej Kabata)
Date: Thu, 30 Aug 2007 15:03:42 +0200
Subject: jakarta-commons-beanutils.spec patch
Message-ID: <1188479023.8390.6.camel@kabasny>

PL
Witam, budujac jakarta-commons-beanutils natknalem sie na dziwnego buga
- w BR by? tenze sam jakarta-commons-beanutils. 
Mam nadzieje ?e to nie by?o celowe, bowiem po poprawce zbudowal sie
ladnie. patch w zalaczniku
pozdrawiam

EN
Welcome, while building jakarta-commons-beanutils I have encountered a
strange bug - in BR existed the very same jakarta-commons-beanutils I
was building. Hopefully after patching (my first submitted patch, shame
that it is that short) it has built
so if it was a bug not ment to be there, please patch it

greetings

kabasny
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jakarta-commons-beanutils.spec.diff
Type: text/x-patch
Size: 97 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070830/5545d8ee/attachment.bin>

From kamil.listy at klecza.pl  Thu Aug 30 18:33:35 2007
From: kamil.listy at klecza.pl (Kamil Dziedzic)
Date: Thu, 30 Aug 2007 18:33:35 +0200
Subject: [ac] kde style plastic
In-Reply-To: <200708292012.44440.glen@delfi.ee>
References: <200708292012.44440.glen@delfi.ee>
Message-ID: <200708301833.36740.kamil.listy@klecza.pl>

Elan Ruusam?e wrote:
> i didn't notice the problem with -1 in ac (maybe i had just different
> style)
I have still -1 and I have this style.

Anyone could confirm its missing in -2? If so I will wait with update until 
this style will come back:D

-- 
Regards, Kamil Dziedzic




From arekm at maven.pl  Fri Aug 31 08:30:28 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Fri, 31 Aug 2007 08:30:28 +0200
Subject: ANN: carme downtime
Message-ID: <200708310830.28756.arekm@maven.pl>


Hello,

carme will be offline later today (and possibly tomorrow) - contents are going 
to be copied to new machine (2 x quad core 2.13GHz, 4GB RAM, 1.4TB of disk 
space in software raid5 + system on raid10).

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From arekm at maven.pl  Fri Aug 31 13:11:08 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Fri, 31 Aug 2007 13:11:08 +0200
Subject: ANN: carme downtime
In-Reply-To: <200708310830.28756.arekm@maven.pl>
References: <200708310830.28756.arekm@maven.pl>
Message-ID: <200708311311.08406.arekm@maven.pl>

On Friday 31 of August 2007, Arkadiusz Miskiewicz wrote:
> Hello,
>
> carme will be offline later today (and possibly tomorrow) - contents are
> going to be copied to new machine (2 x quad core 2.13GHz, 4GB RAM, 1.4TB of
> disk space in software raid5 + system on raid10).

carme is back online.

-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From glen at delfi.ee  Fri Aug 31 23:12:17 2007
From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=)
Date: Sat, 1 Sep 2007 00:12:17 +0300
Subject: [ac] kde style plastic
In-Reply-To: <200708301833.36740.kamil.listy@klecza.pl>
References: <200708292012.44440.glen@delfi.ee>
	<200708301833.36740.kamil.listy@klecza.pl>
Message-ID: <200709010012.17307.glen@delfi.ee>

On Thursday 30 August 2007 19:33:35 Kamil Dziedzic wrote:
> Elan Ruusam?e wrote:
> > i didn't notice the problem with -1 in ac (maybe i had just different
> > style)
>
> I have still -1 and I have this style.
>
> Anyone could confirm its missing in -2? If so I will wait with update until
> this style will come back:D

okay. updating qt to 3.3.8 solved the problem [1].

perhaps kdeXXX should be version dependant on qt then?

[1] kopete chat log:
(10:20:14) < someone wrote to pl mailing list about differences between packages installed on builders and packages on ac ftp
(10:20:36) < qt on ftp is 3.3.7 and on builder is 3.3.8 - that's why styles are not avilable (styles were built with new qt)
(10:20:49) < try upgrading qt to 3.3.8 to see if plastic becomes available

-- 
glen