From patrys at pld-linux.org  Tue Sep  4 11:12:39 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 4 Sep 2007 11:12:39 +0200
Subject: [Th] vserver + vpoldek + vrpm
Message-ID: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>

Yesterday I finally forced vrpm and vpoldek to work predictably.

Details follow:

* vrpm won't work until the attached patch is applied to utils-vserver
(ncontext: vc_net_create(): Invalid argument)

* vpoldek won't work until you:

for i in /etc/vservers/*/apps/pkgmgmt/base/rpm/etc/macros
do
    echo '%_host_os %_os' >> $i
done

The reason is poldek in pm/rpm/misc.c line 200 expands %_host_os macro
which is otherwise not defined in vservers (lack of macro files?).

Anyone (qboosh? ;]) cares to point me in the right place to fix this?
Hope the above info helps anyone.

-- 
Patryk Zawadzki
Generated Content


From patrys at pld-linux.org  Tue Sep  4 11:37:23 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 4 Sep 2007 11:37:23 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
Message-ID: <89b6ba3a0709040237g50fb8640g33400b8526e7be35@mail.gmail.com>

Sorry, ate my patch.

-- 
Patryk Zawadzki
Generated Content
-------------- next part --------------
A non-text attachment was scrubbed...
Name: util-vserver-vrpm.patch
Type: text/x-patch
Size: 424 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070904/35c99125/attachment.bin>

From patrys at pld-linux.org  Tue Sep  4 14:48:15 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 4 Sep 2007 14:48:15 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <89b6ba3a0709040237g50fb8640g33400b8526e7be35@mail.gmail.com>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<89b6ba3a0709040237g50fb8640g33400b8526e7be35@mail.gmail.com>
Message-ID: <89b6ba3a0709040548q51056b2dgb8e2c39522a70c5a@mail.gmail.com>

Can anyone tell me what is the original util-vserver-vrpm.patch from
the spec trying to achieve? Other than making vrpm and vpoldek die of
course.

-- 
Patryk Zawadzki
Generated Content


From baggins at sith.mimuw.edu.pl  Tue Sep  4 15:35:24 2007
From: baggins at sith.mimuw.edu.pl (Jan Rekorajski)
Date: Tue, 4 Sep 2007 15:35:24 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <89b6ba3a0709040548q51056b2dgb8e2c39522a70c5a@mail.gmail.com>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<89b6ba3a0709040237g50fb8640g33400b8526e7be35@mail.gmail.com>
	<89b6ba3a0709040548q51056b2dgb8e2c39522a70c5a@mail.gmail.com>
Message-ID: <20070904133524.GA22933@sith.mimuw.edu.pl>

On Tue, 04 Sep 2007, Patryk Zawadzki wrote:

> Can anyone tell me what is the original util-vserver-vrpm.patch from
> the spec trying to achieve? Other than making vrpm and vpoldek die of
> course.

What's so hard in doing `cvs log util-vserver-vrpm.patch`?

Janek
-- 
Jan Rekorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio


From glen at delfi.ee  Tue Sep  4 15:36:20 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Tue, 4 Sep 2007 16:36:20 +0300
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <89b6ba3a0709040548q51056b2dgb8e2c39522a70c5a@mail.gmail.com>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<89b6ba3a0709040237g50fb8640g33400b8526e7be35@mail.gmail.com>
	<89b6ba3a0709040548q51056b2dgb8e2c39522a70c5a@mail.gmail.com>
Message-ID: <200709041636.20924.glen@delfi.ee>

On Tuesday 04 September 2007 15:48:15 Patryk Zawadzki wrote:
> Can anyone tell me what is the original util-vserver-vrpm.patch from
> the spec trying to achieve? Other than making vrpm and vpoldek die of
> course.

date: 2006/01/20 15:52:24;  author: baggins;  state: Exp;
- do chbind for rpm (lack of chbind breaks %pre/%post rpm scripts)

the %pre and %post scripts execute server restarts that do use network. 
without the chbind call the scripts just failed because no network privileges 
were present.

ie apache restarts after apache upgrades always failed.

-- 
glen


From patrys at pld-linux.org  Tue Sep  4 15:54:41 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 4 Sep 2007 15:54:41 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <200709041636.20924.glen@delfi.ee>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<89b6ba3a0709040237g50fb8640g33400b8526e7be35@mail.gmail.com>
	<89b6ba3a0709040548q51056b2dgb8e2c39522a70c5a@mail.gmail.com>
	<200709041636.20924.glen@delfi.ee>
Message-ID: <89b6ba3a0709040654g1a8fe0f3s66d9e3817df5009e@mail.gmail.com>

On 9/4/07, Elan Ruusam?e <glen at delfi.ee> wrote:
> On Tuesday 04 September 2007 15:48:15 Patryk Zawadzki wrote:
> > Can anyone tell me what is the original util-vserver-vrpm.patch from
> > the spec trying to achieve? Other than making vrpm and vpoldek die of
> > course.
>
> date: 2006/01/20 15:52:24;  author: baggins;  state: Exp;
> - do chbind for rpm (lack of chbind breaks %pre/%post rpm scripts)
>
> the %pre and %post scripts execute server restarts that do use network.
> without the chbind call the scripts just failed because no network privileges
> were present.
>
> ie apache restarts after apache upgrades always failed.

Current utils-vserver already issue a chbind much earlier and this
patched invocation always fails due to no "--nid $RPM_FAKE_CTX"
passed.

-- 
Patryk Zawadzki
Generated Content

From glen at delfi.ee  Tue Sep  4 17:37:21 2007
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Tue, 4 Sep 2007 18:37:21 +0300
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <89b6ba3a0709040654g1a8fe0f3s66d9e3817df5009e@mail.gmail.com>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<200709041636.20924.glen@delfi.ee>
	<89b6ba3a0709040654g1a8fe0f3s66d9e3817df5009e@mail.gmail.com>
Message-ID: <200709041837.21488.glen@delfi.ee>

On Tuesday 04 September 2007 16:54:41 Patryk Zawadzki wrote:
> On 9/4/07, Elan Ruusam?e <glen at delfi.ee> wrote:
> > On Tuesday 04 September 2007 15:48:15 Patryk Zawadzki wrote:
> > > Can anyone tell me what is the original util-vserver-vrpm.patch from
> > > the spec trying to achieve? Other than making vrpm and vpoldek die of
> > > course.
> >
> > date: 2006/01/20 15:52:24;  author: baggins;  state: Exp;
> > - do chbind for rpm (lack of chbind breaks %pre/%post rpm scripts)
> >
> > the %pre and %post scripts execute server restarts that do use network.
> > without the chbind call the scripts just failed because no network
> > privileges were present.
> >
> > ie apache restarts after apache upgrades always failed.
>
> Current utils-vserver already issue a chbind much earlier and this
> patched invocation always fails due to no "--nid $RPM_FAKE_CTX"
> passed.

so then the old patch is outdated.

-- 
glen


From patrys at pld-linux.org  Tue Sep  4 18:09:07 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 4 Sep 2007 18:09:07 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <200709041837.21488.glen@delfi.ee>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<200709041636.20924.glen@delfi.ee>
	<89b6ba3a0709040654g1a8fe0f3s66d9e3817df5009e@mail.gmail.com>
	<200709041837.21488.glen@delfi.ee>
Message-ID: <89b6ba3a0709040909g486e633p67b487f9773d6318@mail.gmail.com>

On 9/4/07, Elan Ruusam?e <glen at delfi.ee> wrote:
> so then the old patch is outdated.

Can anyone try the current util-vserver without this patch? I can't as
rpm 4.4.-9-8 does not work with vrpm at all :/

Since yesterday my production machine is unusable and I can't
downgrade rpm as db version changed.

-- 
Patryk Zawadzki
Generated Content

From n3npq at mac.com  Tue Sep  4 18:30:39 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Tue, 4 Sep 2007 12:30:39 -0400
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <89b6ba3a0709040909g486e633p67b487f9773d6318@mail.gmail.com>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<200709041636.20924.glen@delfi.ee>
	<89b6ba3a0709040654g1a8fe0f3s66d9e3817df5009e@mail.gmail.com>
	<200709041837.21488.glen@delfi.ee>
	<89b6ba3a0709040909g486e633p67b487f9773d6318@mail.gmail.com>
Message-ID: <66CF53C8-D52C-464D-BBB7-20549E15C4F3@mac.com>


On Sep 4, 2007, at 12:09 PM, Patryk Zawadzki wrote:

>
>
> Since yesterday my production machine is unusable and I can't
> downgrade rpm as db version changed.
>

Use db_dump from the newer rpm package, db_load from the older rpm  
package.

Do the following
     cd /var/lib/rpm
     mv Packages Packages-ORIG
     db_dump Packages-ORIG | db_load Packages
     rpm --rebuilddb -vv
     rpm -qa

73 de Jeff
>


From patrys at pld-linux.org  Tue Sep  4 18:54:03 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 4 Sep 2007 18:54:03 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <66CF53C8-D52C-464D-BBB7-20549E15C4F3@mac.com>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<200709041636.20924.glen@delfi.ee>
	<89b6ba3a0709040654g1a8fe0f3s66d9e3817df5009e@mail.gmail.com>
	<200709041837.21488.glen@delfi.ee>
	<89b6ba3a0709040909g486e633p67b487f9773d6318@mail.gmail.com>
	<66CF53C8-D52C-464D-BBB7-20549E15C4F3@mac.com>
Message-ID: <89b6ba3a0709040954n79b62942yfee3c45e7fd6db6b@mail.gmail.com>

On 9/4/07, Jeff Johnson <n3npq at mac.com> wrote:
>
> On Sep 4, 2007, at 12:09 PM, Patryk Zawadzki wrote:
> > Since yesterday my production machine is unusable and I can't
> > downgrade rpm as db version changed.
> Use db_dump from the newer rpm package, db_load from the older rpm
> package.

If there is no other solution I will do that tomorrow. I'd rather have
current rpm fixed though (if it's rpm that needs a fix).

-- 
Patryk Zawadzki
Generated Content


From gotar at polanet.pl  Thu Sep  6 14:32:10 2007
From: gotar at polanet.pl (Tomasz Pala)
Date: Thu, 6 Sep 2007 14:32:10 +0200
Subject: [th] qt4 problems
In-Reply-To: <20070827103653.GA16114@pepin.polanet.pl>
References: <20070616154052.GA16077@pepin.polanet.pl>
	<200706180915.03756.zswi@pers.pl>
	<20070827103653.GA16114@pepin.polanet.pl>
Message-ID: <20070906123210.GA4768@pepin.polanet.pl>

On Mon, Aug 27, 2007 at 12:36:53 +0200, Tomasz Pala wrote:

> > > 2. qt4 doesn't honour fontconfig setup (doesn't draw through
> > >    freetype/cairo/Xft and I've got badly subpixeled fonts) - is it fourth
> > >    rendering engine?

I'll answer myself - it is: src/gui/text/qfontengine_ft.cpp.

Does anyone know some patch like cairo-1.2.4-lcd-filter-1.patch or
xorg-lib-libXft-lcd-filter.patch for qt4?

-- 
Tomasz Pala <gotar at pld-linux.org>


From arekm at maven.pl  Thu Sep  6 18:23:57 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Thu, 6 Sep 2007 18:23:57 +0200
Subject: SOURCES: rpm.macros - add X.org helper macros (needs review)
In-Reply-To: <SOURCES_rpm.macros.1.389@pld-linux.org>
References: <SOURCES_rpm.macros.1.388@pld-linux.org>
	<SOURCES_rpm.macros.1.389@pld-linux.org>
Message-ID: <200709061823.57998.arekm@maven.pl>

On Thursday 06 of September 2007, arekm wrote:
> Author: arekm                        Date: Thu Sep  6 16:00:52 2007 GMT
> Module: SOURCES                       Tag: HEAD
> ---- Log message:
> - add X.org helper macros (needs review)

Please take a look at rpm-build-macros.spec and new xorg related macros. xorg 
macros should be sane but I want to make sure before rebuilding related xorg 
bits in Th.

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


From adamg at biomerieux.pl  Fri Sep  7 10:04:52 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Fri, 7 Sep 2007 10:04:52 +0200
Subject: ERRORS: openoffice.org.spec
In-Reply-To: <pld-builder.1189129037.470322.26117@builderth>
References: <87f5d967-089b-4d7e-aaeb-c5d8fc2558a3@pld.src.builder>
	<pld-builder.1189129037.470322.26117@builderth>
Message-ID: <20070907080452.GB10203@mysza.eu.org>

On Fri, Sep 07, 2007 at 01:37:17AM +0000, PLD th-x86_64 builder wrote:
> openoffice.org.spec (auto-th-openoffice_org-2_2_0-oof680_m14_0_8): FAILED
> 
> --- openoffice.org.spec:auto-th-openoffice_org-2_2_0-oof680_m14_0_8:
> Build-Time: user:151.94s sys:41.41s real:1860.07s (faults io:555 non-io:4259044)
> checking NEON_CFLAGS... -I/usr/include/neon  
> checking NEON_LIBS... -lneon  
> checking for neon < 0.27.0... configure: error: you need neon 0.24.x to 0.26.x for system-neon
> make: *** [stamp/build] Error 1
> error: Bad exit status from /tmp/B.fc7743/rpm-tmp.59766 (%build)

Won't do - we'll have to switch to ooo-2.3.0's snaps (and ooo-build from
trunk), or someone may try to port ooo80967.ucb.neon27.diff to 2.2 and
see what would explode...

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


From adamg at biomerieux.pl  Fri Sep  7 10:46:54 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Fri, 7 Sep 2007 10:46:54 +0200
Subject: libtool problems
Message-ID: <20070907084654.GA10991@mysza.eu.org>

Hi,

I'm having a problem with libtool (I guess) - it does not add --tag=CC
which causes build to fail. If I alter Makefile and add it by hand,
build passes, but then again, $DESTDIR is not taken into consideration.

No libtoolize / ac/am rebuild helps.
 
/usr/share/apr/build/libtool is used in this build (obtained through
apr-1-config --apr-libtool).

Any hints?

-- 
 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  Fri Sep  7 16:53:09 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 7 Sep 2007 16:53:09 +0200
Subject: libtool problems
In-Reply-To: <20070907084654.GA10991@mysza.eu.org>
References: <20070907084654.GA10991@mysza.eu.org>
Message-ID: <20070907145309.GA6478@stranger.qboosh.pl>

On Fri, Sep 07, 2007 at 10:46:54AM +0200, Adam Go??biowski wrote:
> Hi,
> 
> I'm having a problem with libtool (I guess) - it does not add --tag=CC
> which causes build to fail. If I alter Makefile and add it by hand,
> build passes, but then again, $DESTDIR is not taken into consideration.

--tag= is added by ac/am macros, when AC_PROG_LIBTOOL and automake is
used.

> No libtoolize / ac/am rebuild helps.
>  
> /usr/share/apr/build/libtool is used in this build (obtained through
> apr-1-config --apr-libtool).

Which package is it? I suppose it doesn't use AC_PROG_LIBTOOL if it uses
apr's libtool.


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


From adamg at biomerieux.pl  Fri Sep  7 17:53:37 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Fri, 7 Sep 2007 17:53:37 +0200
Subject: libtool problems
In-Reply-To: <20070907145309.GA6478@stranger.qboosh.pl>
References: <20070907084654.GA10991@mysza.eu.org>
	<20070907145309.GA6478@stranger.qboosh.pl>
Message-ID: <20070907155337.GA18077@mysza.eu.org>

On Fri, Sep 07, 2007 at 04:53:09PM +0200, Jakub Bogusz wrote:
> Which package is it? 

It happened to me while working on apache-mod_gnutls.spec.

> I suppose it doesn't use AC_PROG_LIBTOOL if it uses apr's libtool.

exactly - configure.ac lacked AC_PROG_LIBTOOL, thanks for the hint.

-- 
 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  Fri Sep  7 19:49:51 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Fri, 7 Sep 2007 19:49:51 +0200
Subject: SOURCES: rpm.macros - add X.org helper macros (needs review)
In-Reply-To: <200709061823.57998.arekm@maven.pl>
References: <SOURCES_rpm.macros.1.388@pld-linux.org>
	<SOURCES_rpm.macros.1.389@pld-linux.org>
	<200709061823.57998.arekm@maven.pl>
Message-ID: <20070907174951.GA20472@stranger.qboosh.pl>

We can use macros like this:

%{?requires_xorg_xserver_xinput}

to pervent spec parsing failures before macros BR checking (and without
requiring very fresh builder).


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


From aredridel at nbtsc.org  Sat Sep  8 21:06:21 2007
From: aredridel at nbtsc.org (Aria Stewart)
Date: Sat, 08 Sep 2007 13:06:21 -0600
Subject: Virtual P/R foo(eabi)
Message-ID: <1189278381.15952.7.camel@eridani.theinternetco.net>

crossarm-binutils.spec provides crossarm-binutils(gnueabi)
crossarm-gcc.spec requires crossarm-binutils(eabi)

Which one is correct (or if both, why?)

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/20070908/4aeb34fc/attachment.sig>

From adamg at biomerieux.pl  Sun Sep  9 01:44:10 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Sun, 9 Sep 2007 01:44:10 +0200
Subject: mod_gnutls's dhfile/rsafile generation
Message-ID: <20070908234410.GD32449@mysza.eu.org>

Hi,

I was thinking about apache mod_gnutls's dhfile/rsafile files being
generate in %post, which could be done by something similiar to:

--- cut ---
%post
if [ "$1" = "0" ]; then
	d=/etc/httpd/tls
	[ -f "$d/dhfile" ] || /usr/bin/certtool --generate-dh-params --bits 1024 --outfile $d/dhfile
	[ -f "$d/rsafile" ] || /usr/bin/certtool --generate-privkey --bits 512 --outfile $d/rsafile
fi
--- cut ---

but the process may take some time on slower machines, or those where
/dev/random tends to block while waiting for entropy pool.

Comments?

-- 
 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  Sun Sep  9 10:18:03 2007
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Sun, 9 Sep 2007 11:18:03 +0300
Subject: mod_gnutls's dhfile/rsafile generation
In-Reply-To: <20070908234410.GD32449@mysza.eu.org>
References: <20070908234410.GD32449@mysza.eu.org>
Message-ID: <200709091118.03526.glen@delfi.ee>

On Sunday 09 September 2007 02:44, Adam Go??biowski wrote:
> Hi,
>
> I was thinking about apache mod_gnutls's dhfile/rsafile files being
> generate in %post, which could be done by something similiar to:
>
> --- cut ---
> %post
> if [ "$1" = "0" ]; then
> 	d=/etc/httpd/tls
> 	[ -f "$d/dhfile" ] || /usr/bin/certtool --generate-dh-params --bits 1024
> --outfile $d/dhfile [ -f "$d/rsafile" ] || /usr/bin/certtool
> --generate-privkey --bits 512 --outfile $d/rsafile fi
> --- cut ---
>
> but the process may take some time on slower machines, or those where
> /dev/random tends to block while waiting for entropy pool.

other way is openssh way -- when service is started, but that's modifying 
apache.spec 

-- 
glen


From adamg at biomerieux.pl  Sun Sep  9 22:44:01 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Sun, 9 Sep 2007 22:44:01 +0200
Subject: mod_gnutls's dhfile/rsafile generation
In-Reply-To: <200709091118.03526.glen@delfi.ee>
References: <20070908234410.GD32449@mysza.eu.org>
	<200709091118.03526.glen@delfi.ee>
Message-ID: <20070909204401.GA19691@mysza.eu.org>

On Sun, Sep 09, 2007 at 11:18:03AM +0300, Elan Ruusam?e wrote:
> On Sunday 09 September 2007 02:44, Adam Go??biowski wrote:
> > Hi,
> >
> > I was thinking about apache mod_gnutls's dhfile/rsafile files being
> > generate in %post, which could be done by something similiar to:
> >
> > --- cut ---
> > %post
> > if [ "$1" = "0" ]; then
> > 	d=/etc/httpd/tls
> > 	[ -f "$d/dhfile" ] || /usr/bin/certtool --generate-dh-params --bits 1024
> > --outfile $d/dhfile [ -f "$d/rsafile" ] || /usr/bin/certtool
> > --generate-privkey --bits 512 --outfile $d/rsafile fi
> > --- cut ---
> >
> > but the process may take some time on slower machines, or those where
> > /dev/random tends to block while waiting for entropy pool.
> 
> other way is openssh way -- when service is started, but that's modifying 
> apache.spec 

Ah, didn't think of that.

This would mean keeping httpd down for some time (only once, but still),
and this could annoy some people. I think I'll go for the presented
option (%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 gotar at polanet.pl  Tue Sep 11 14:32:19 2007
From: gotar at polanet.pl (Tomasz Pala)
Date: Tue, 11 Sep 2007 14:32:19 +0200
Subject: logrotate archive on AC-branch
Message-ID: <20070911123219.GA28394@pepin.polanet.pl>

Hi,

I've just commited 41 C: logrotate < 3.7-4 and 4 R: logrotate >= 3.7-4 [*]
on HEAD. However there are 5 packages on AC-branch with logrotate files
switched to archive: tor, mysql, lighttpd, cups and bircd - just an info
for people who might be interested.


[*] I don't know if they shouldn't be replaced by C:
sardzent - why did you add R: logrotate >= 3.7.4 to nginx.spec?

-- 
Tomasz Pala <gotar at pld-linux.org>


From adamg at biomerieux.pl  Tue Sep 11 22:05:15 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Tue, 11 Sep 2007 22:05:15 +0200
Subject: OK: gcc.spec
In-Reply-To: <0516d727-bb30-450f-af3e-d33aeb446033@pld.src.builder>
References: <0516d727-bb30-450f-af3e-d33aeb446033@pld.src.builder>
Message-ID: <20070911200515.GC1373@mysza.eu.org>

On Tue, Sep 11, 2007 at 07:58:26PM +0000, PLD ti-src builder wrote:
> gcc.spec (auto-ti-gcc-4_2_1-2): OK

maybe a separate list (pld-logs-ti?) should be set up?

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


From hawk at limanowa.net  Tue Sep 11 22:12:42 2007
From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=)
Date: Tue, 11 Sep 2007 22:12:42 +0200
Subject: OK: gcc.spec
In-Reply-To: <20070911200515.GC1373@mysza.eu.org>
References: <0516d727-bb30-450f-af3e-d33aeb446033@pld.src.builder>
	<20070911200515.GC1373@mysza.eu.org>
Message-ID: <46E6F6BA.5000708@limanowa.net>

> maybe a separate list (pld-logs-ti?) should be set up?

Or I may simply remove list address from builder configs for now. There
may be quite big traffic there in next two months or so.

M.




From ankry at green.mif.pg.gda.pl  Wed Sep 12 09:22:37 2007
From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz)
Date: Wed, 12 Sep 2007 09:22:37 +0200 (CEST)
Subject: SPECS: kmando.spec (NEW) - new,
	based on opensuse spec: http://rep...
In-Reply-To: <SPECS_kmando.spec.1.1@pld-linux.org> from "glen" at Sep 11,
	2007 11:48:48 PM
Message-ID: <200709120722.l8C7MbA5004366@green.mif.pg.gda.pl>

glen wrote:
> +cat > $RPM_BUILD_ROOT%{_desktopdir}/kde/%{name}.desktop <<EOF
> +[Desktop Entry]
> +Encoding=UTF-8

Why not a separate SOURCE?
IMVHO, it would be easier to manage.

-- 
=======================================================================
  Andrzej M. Krzysztofowicz                  ankry at mif.pg.gda.pl
  phone (48)(58) 347 19 36
Faculty of Applied Phys. & Math.,   Gdansk University of Technology


From glen at delfi.ee  Wed Sep 12 09:36:12 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 12 Sep 2007 10:36:12 +0300
Subject: SPECS: kmando.spec (NEW) - new,
	based on opensuse spec: http://rep...
In-Reply-To: <200709120722.l8C7MbA5004366@green.mif.pg.gda.pl>
References: <200709120722.l8C7MbA5004366@green.mif.pg.gda.pl>
Message-ID: <200709121036.12421.glen@delfi.ee>

On Wednesday 12 September 2007 10:22:37 Andrzej Krzysztofowicz wrote:
> glen wrote:
> > +cat > $RPM_BUILD_ROOT%{_desktopdir}/kde/%{name}.desktop <<EOF
> > +[Desktop Entry]
> > +Encoding=UTF-8
>
> Why not a separate SOURCE?
> IMVHO, it would be easier to manage.

was there initially. i'd rather make efforts on compiling it than cosmetics 
which can be done later. but those c++ errors are over my head.

but feel free to move :)

-- 
glen


From kabasny at gmail.com  Sun Sep 16 11:41:43 2007
From: kabasny at gmail.com (Piotr Maciej Kabata)
Date: Sun, 16 Sep 2007 11:41:43 +0200
Subject: Wikipedia Article
Message-ID: <1189935703.3393.1.camel@kabasny>

Is anyone up to date with Wikipedia articles creation? because I am a
little not up to date with it. And the reason for the question goes
here:

The subject of this article may not satisfy the notability guideline or
one of the following guidelines for inclusion on Wikipedia: Biographies,
Books, Companies, Fiction, Music, Neologisms, Numbers, Web content, or
several proposals for new guidelines.

If you are familiar with the subject matter, please expand or rewrite
the article to establish its notability. The best way to address this
concern is to reference published, third-party sources about the
subject. If notability cannot be established, the article is more likely
to be considered for deletion, per Wikipedia:Guide to deletion.
This article has been tagged since May 2007.
	This article or section needs sources or references that appear in
reliable, third-party publications. Alone, primary sources and sources
affiliated with the subject of this article are not sufficient for an
accurate encyclopedia article. Please include more appropriate citations
from reliable sources.


greetings

kabasny



From jjjustjjjay at lavabit.com  Tue Sep 18 00:53:39 2007
From: jjjustjjjay at lavabit.com (Jay Charles Anderson)
Date: Mon, 17 Sep 2007 18:53:39 -0400
Subject: klogd
References: <mailman.104.1136479287.23910.pld-devel-en@lists.pld-linux.org>
Message-ID: <46EF0573.ED70E0FC@lavabit.com>

is kloged a a part of the opperating system or a add on program

Elan Ruusam?e wrote:

> klogd is broken. it loads symbols and then says there were no symbols:
>
> Jan  5 18:27:24 black kernel: klogd 1.4.1, log source = /proc/kmsg started.
> Jan  5 18:27:24 black kernel: Inspecting /boot/System.map-2.6.12.5-0.2
> Jan  5 18:27:24 black kernel: Loaded 26743 symbols from /boot/System.map-2.6.12.5-0.2.
> Jan  5 18:27:24 black kernel: Symbols match kernel version 2.6.12.
> Jan  5 18:27:24 black kernel: No module symbols loaded - kernel modules not enabled.
>
> somebody want's to fix this?
>
> --
> glen



From pld at nius.waw.pl  Tue Sep 18 15:54:16 2007
From: pld at nius.waw.pl (Marcin Kurzyna)
Date: Tue, 18 Sep 2007 15:54:16 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <89b6ba3a0709040954n79b62942yfee3c45e7fd6db6b@mail.gmail.com>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<66CF53C8-D52C-464D-BBB7-20549E15C4F3@mac.com>
	<89b6ba3a0709040954n79b62942yfee3c45e7fd6db6b@mail.gmail.com>
Message-ID: <200709181554.17137.pld@nius.waw.pl>

On Tuesday 04 September 2007 18:54:03 Patryk Zawadzki wrote:

> If there is no other solution I will do that tomorrow. I'd rather have
> current rpm fixed though (if it's rpm that needs a fix).

was this fixed in any way (so that vservers would work with current rpm/db)? 
i've just posted to users-pl about this because i thought this thred was only 
due to version mismatch however now i see it's the same problem.

if not - doeas anyone have working rpm/db pair available for download that i 
could use?

tia,
marcin


From pld at nius.waw.pl  Tue Sep 18 16:22:58 2007
From: pld at nius.waw.pl (Marcin Kurzyna)
Date: Tue, 18 Sep 2007 16:22:58 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <200709181554.17137.pld@nius.waw.pl>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<89b6ba3a0709040954n79b62942yfee3c45e7fd6db6b@mail.gmail.com>
	<200709181554.17137.pld@nius.waw.pl>
Message-ID: <200709181622.58517.pld@nius.waw.pl>

Ok, the problem is that rpm/db4(?) hardcodes file locations into database 
files so for example opening Basename searches always 
for /vservers/test-system/.rpmdb/Basenames which doesn't exist inside 
vserver. 

I've got vpoldek/vrpm working after:

mkdir -p /vservers/test-system/vservers/test-system/.rpmdb
cp /vservers/.pkg/test-system/rpm/state/* \
     /vservers/test-system/vservers/test-system/.rpmdb

as where/how to fix it - dunno. will leave to "someone who understands"(tm) 
rpm/db4 internals.

m.



From pld at nius.waw.pl  Tue Sep 18 16:36:12 2007
From: pld at nius.waw.pl (Marcin Kurzyna)
Date: Tue, 18 Sep 2007 16:36:12 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <200709181622.58517.pld@nius.waw.pl>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<200709181554.17137.pld@nius.waw.pl>
	<200709181622.58517.pld@nius.waw.pl>
Message-ID: <200709181636.12587.pld@nius.waw.pl>

To specify even more. Above hardcoded path is relevant only for 3 files:

Basenames  
Conflictname  
Providename

and of course hardlinks work as well. ok - end of self replys

marcin


From patrys at pld-linux.org  Tue Sep 18 16:53:54 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Tue, 18 Sep 2007 16:53:54 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <200709181636.12587.pld@nius.waw.pl>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<200709181554.17137.pld@nius.waw.pl>
	<200709181622.58517.pld@nius.waw.pl>
	<200709181636.12587.pld@nius.waw.pl>
Message-ID: <89b6ba3a0709180753r416281e9m945142f9e03c858a@mail.gmail.com>

On 9/18/07, Marcin Kurzyna <pld at nius.waw.pl> wrote:
> To specify even more. Above hardcoded path is relevant only for 3 files:
>
> Basenames
> Conflictname
> Providename
>
> and of course hardlinks work as well. ok - end of self replys

arekm promised to take a look into the backported code for any easy fixes.

-- 
Patryk Zawadzki
Generated Content


From adamg at biomerieux.pl  Tue Sep 18 19:16:35 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Tue, 18 Sep 2007 19:16:35 +0200
Subject: [Th] pixman and xorg-xserver-server
Message-ID: <20070918171635.GA1377@mysza.eu.org>

This is what I got today (fresh install, th-athlon):

/usr/bin/Xwrapper: symbol lookup error: /usr/lib/xorg/modules//libfb.so: undefined symbol: pixman_image_set_source_clipping

missing R: pixman in xorg-xserver-server? And why wasn't this dependecy
autogenerated?

-- 
 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 Sep 19 10:26:04 2007
From: glen at delfi.ee (Elan =?utf-8?q?Ruusam=C3=A4e?=)
Date: Wed, 19 Sep 2007 11:26:04 +0300
Subject: [Th] pixman and xorg-xserver-server
In-Reply-To: <20070918171635.GA1377@mysza.eu.org>
References: <20070918171635.GA1377@mysza.eu.org>
Message-ID: <200709191126.04586.glen@delfi.ee>

On Tuesday 18 September 2007 20:16, Adam Go??biowski wrote:
> missing R: pixman in xorg-xserver-server? And why wasn't this dependecy
> autogenerated?

perhaps the library in rpmbuildroot wasn't exekutable?

-- 
glen


From patrys at pld-linux.org  Wed Sep 19 16:09:08 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Wed, 19 Sep 2007 16:09:08 +0200
Subject: Unclear Firefox situation
Message-ID: <89b6ba3a0709190709o6fa8e110kb64e25b621500ba4@mail.gmail.com>

Older versions of Firefox used "Bon Echo" branding which is permitted
to all parties. Now it seems official branding is back. Any particular
reason? Are we allowed to do that? We can use "community edition"
instead of "Bon Echo" but I doubt we are allowed to ship it as
"Firefox."

-- 
Patryk Zawadzki
Generated Content


From qboosh at pld-linux.org  Wed Sep 19 19:46:04 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 19 Sep 2007 19:46:04 +0200
Subject: SPECS: squid.spec - fixes -m32 error that gcc doesn't recognize
In-Reply-To: <SPECS_squid.spec.1.281@pld-linux.org>
References: <SPECS_squid.spec.1.280@pld-linux.org>
	<SPECS_squid.spec.1.281@pld-linux.org>
Message-ID: <20070919174604.GA4596@stranger.qboosh.pl>

On Wed, Sep 19, 2007 at 06:43:09PM +0200, glen wrote:
> Author: glen                         Date: Wed Sep 19 16:43:09 2007 GMT
> Module: SPECS                         Tag: HEAD
> ---- Log message:
> - fixes -m32 error that gcc doesn't recognize

workarounds gcc error?
According to docs gcc should accept -m32 on PPC (see RS/6000 and PowerPC
options). Moreover, -m32/-m64 are used to choose ppc or ppc64 target.

BTW, gcc in Debian and PLD Th accepts -m32, so this patch even as
a workaround shouldn't appear on HEAD.


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


From hawk at limanowa.net  Wed Sep 19 21:42:06 2007
From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=)
Date: Wed, 19 Sep 2007 21:42:06 +0200
Subject: Unclear Firefox situation
In-Reply-To: <89b6ba3a0709190709o6fa8e110kb64e25b621500ba4@mail.gmail.com>
References: <89b6ba3a0709190709o6fa8e110kb64e25b621500ba4@mail.gmail.com>
Message-ID: <46F17B8E.1090003@limanowa.net>

> Older versions of Firefox used "Bon Echo" branding which is permitted
> to all parties. Now it seems official branding is back. Any particular
> reason? Are we allowed to do that? We can use "community edition"
> instead of "Bon Echo" but I doubt we are allowed to ship it as
> "Firefox."

I didn't used 2.0.0.7 yet but 2.0.0.6 was BonEcho on both Ac and Th.
Quick look at changelog says that it still should be BonEcho or I missed
something. Anyway, problem is more complex. We can't use branding for
Thunderbird and SeaMonkey as well. Last one is problematic as it doesn't
matter if you do official build or not, its always branded. Maybe we
should use Debian patches and change software names, logos etc to
Iceweasel, Iceape and Icedove? Does Debian allows use of these patches
in other distros? I have it in my looong todo but with low priority.

BTW: if I remember correctly license also disallows use of terms
"mozilla firefox" and "mozilla thunderbird" anywhere in package
including executable file names.

M.


From qboosh at pld-linux.org  Wed Sep 19 22:05:42 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 19 Sep 2007 22:05:42 +0200
Subject: Unclear Firefox situation
In-Reply-To: <46F17B8E.1090003@limanowa.net>
References: <89b6ba3a0709190709o6fa8e110kb64e25b621500ba4@mail.gmail.com>
	<46F17B8E.1090003@limanowa.net>
Message-ID: <20070919200541.GA19668@stranger.qboosh.pl>

On Wed, Sep 19, 2007 at 09:42:06PM +0200, Marcin Kr?l wrote:
> > Older versions of Firefox used "Bon Echo" branding which is permitted
> > to all parties. Now it seems official branding is back. Any particular
> > reason? Are we allowed to do that? We can use "community edition"
> > instead of "Bon Echo" but I doubt we are allowed to ship it as
> > "Firefox."
> 
> I didn't used 2.0.0.7 yet but 2.0.0.6 was BonEcho on both Ac and Th.
> Quick look at changelog says that it still should be BonEcho or I missed
> something. Anyway, problem is more complex. We can't use branding for
> Thunderbird and SeaMonkey as well. Last one is problematic as it doesn't
> matter if you do official build or not, its always branded. Maybe we
> should use Debian patches and change software names, logos etc to
> Iceweasel, Iceape and Icedove? Does Debian allows use of these patches
> in other distros? I have it in my looong todo but with low priority.

I think Debian does allow it, but I don't even remember those package
names. BTW: iceweasel.spec contains obsolete version of package, with
well known security bugs.

> BTW: if I remember correctly license also disallows use of terms
> "mozilla firefox" and "mozilla thunderbird" anywhere in package
> including executable file names.

"Mozilla Community Edition Policy" doesn't say anything about files
or filenames, just:

   You may not prefix the name product with "Mozilla" (e.g. "Mozilla
Firefox Community Edition" is not allowed.) nor use the official Firefox
or Thunderbird logos to identify the software.  You can, of course,
still use the unofficial ones.


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


From zswi at pers.pl  Wed Sep 19 22:22:57 2007
From: zswi at pers.pl (=?utf-8?q?Rafa=C5=82_Cygnarowski?=)
Date: Wed, 19 Sep 2007 22:22:57 +0200
Subject: Unclear Firefox situation
In-Reply-To: <20070919200541.GA19668@stranger.qboosh.pl>
References: <89b6ba3a0709190709o6fa8e110kb64e25b621500ba4@mail.gmail.com>
	<46F17B8E.1090003@limanowa.net>
	<20070919200541.GA19668@stranger.qboosh.pl>
Message-ID: <200709192223.02098.zswi@pers.pl>

Dnia ?roda, 19 wrze?nia 2007, Jakub Bogusz napisa?:
> "Mozilla Community Edition Policy" doesn't say anything about files
> or filenames, just:
>
>    You may not prefix the name product with "Mozilla" (e.g. "Mozilla
> Firefox Community Edition" is not allowed.) nor use the official Firefox
> or Thunderbird logos to identify the software.  You can, of course,
> still use the unofficial ones.

And earlier:

<quotation>
If an individual or organization is creating a Community Edition of Mozilla 
Firefox or Thunderbird, it must use the names "Firefox Community Edition" 
or "Thunderbird Community Edition" to identify this software. These names may 
be further qualified to identify the software (e.g. "Firefox Community 
Edition, French", "Thunderbird Community Edition, Joe's optimized AMD Opteron 
build", etc.). Localizers may also translate the words "Community Edition".
</quotation>

So... Mozilla Firefox should be called just Firefox... isn't it true?

Regards,
-- 
Rafa? Cygnarowski
rafi at pers.pl
-------------- 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/20070919/684e9838/attachment.sig>

From dhubleizh at o2.pl  Thu Sep 20 08:16:04 2007
From: dhubleizh at o2.pl (Cezary Krzyzanowski)
Date: Thu, 20 Sep 2007 08:16:04 +0200
Subject: Unclear Firefox situation
In-Reply-To: <200709192223.02098.zswi@pers.pl>
References: <89b6ba3a0709190709o6fa8e110kb64e25b621500ba4@mail.gmail.com>
	<46F17B8E.1090003@limanowa.net>
	<20070919200541.GA19668@stranger.qboosh.pl>
	<200709192223.02098.zswi@pers.pl>
Message-ID: <1190268965.3472.0.camel@ipv6-localnet>

Dnia 19-09-2007, ?r o godzinie 22:22 +0200, Rafa? Cygnarowski
napisa?(a):

> <quotation>
> If an individual or organization is creating a Community Edition of Mozilla 
> Firefox or Thunderbird, it must use the names "Firefox Community Edition" 
> or "Thunderbird Community Edition" to identify this software. These names may 
> be further qualified to identify the software (e.g. "Firefox Community 
> Edition, French", "Thunderbird Community Edition, Joe's optimized AMD Opteron 
> build", etc.). Localizers may also translate the words "Community Edition".
> </quotation>
> 
> So... Mozilla Firefox should be called just Firefox... isn't it true?
> 

Ehm -- and not 'Fierefox Community Edition' ??

Cz at rny



From hawk at limanowa.net  Thu Sep 20 08:31:00 2007
From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=)
Date: Thu, 20 Sep 2007 08:31:00 +0200
Subject: Unclear Firefox situation
In-Reply-To: <20070919200541.GA19668@stranger.qboosh.pl>
References: <89b6ba3a0709190709o6fa8e110kb64e25b621500ba4@mail.gmail.com>	<46F17B8E.1090003@limanowa.net>
	<20070919200541.GA19668@stranger.qboosh.pl>
Message-ID: <46F213A4.3070400@limanowa.net>

> I think Debian does allow it, but I don't even remember those package
> names. BTW: iceweasel.spec contains obsolete version of package, with
> well known security bugs.

Those Debian patches seems to simply replace logos and some texts in
source. After removing debian specific chunks from patches it would be
simple cp of current specs + one more patch + replacing software names
in specs.

M.


From dhubleizh at o2.pl  Thu Sep 20 08:33:09 2007
From: dhubleizh at o2.pl (Cezary Krzyzanowski)
Date: Thu, 20 Sep 2007 08:33:09 +0200
Subject: BR-s and R-s policy
Message-ID: <1190269989.3472.5.camel@ipv6-localnet>

Patrys asked me to up evolution spec to 1.12 (corresponding with GNOME
2.20) and I've spotted, that during the GNOME packages update all the
BR-s and R-s of gnome packages were upped to 2.20 line.

The question is -- Is this necessary? I mean I've looked into
evolution's configure.in and it seems it doesn't need half the newest
packages that are listed in BR-s and R-s in evolution.spec (like it
needs GConf2 >= 2.0.0, not newest, shiniest 2.19).

So is this some kind of policy, to require newest packages possible at
the time of upping spec?

Cz at rny



From hawk at limanowa.net  Thu Sep 20 08:52:27 2007
From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=)
Date: Thu, 20 Sep 2007 08:52:27 +0200
Subject: BR-s and R-s policy
In-Reply-To: <1190269989.3472.5.camel@ipv6-localnet>
References: <1190269989.3472.5.camel@ipv6-localnet>
Message-ID: <46F218AB.3090108@limanowa.net>

> So is this some kind of policy, to require newest packages possible at
> the time of upping spec?

It seems so. Its stupid IMO to bump version to highest possible ignoring
real requirements. For example many specs from HEAD are building
perfectly on Ac after dropping unecessary version requirements. In Ac
case it leads to creating and maintaining unecessary Ac branch. But
well, most of developers says thats good idea. I remember some
discussion about it but unfortunatelly I don't remember any arguments
why it is good solution to bump version everytime something gets updated.

M.


From arekm at maven.pl  Thu Sep 20 08:57:11 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Thu, 20 Sep 2007 08:57:11 +0200
Subject: BR-s and R-s policy
In-Reply-To: <46F218AB.3090108@limanowa.net>
References: <1190269989.3472.5.camel@ipv6-localnet>
	<46F218AB.3090108@limanowa.net>
Message-ID: <200709200857.11218.arekm@maven.pl>

On Thursday 20 of September 2007, Marcin Kr?l wrote:
> > So is this some kind of policy, to require newest packages possible at
> > the time of upping spec?
>
> It seems so. Its stupid IMO to bump version to highest possible ignoring
> real requirements. 

It's used to ensure that there are latest packages on the builders. That's the 
only reason I know.

> M.

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


From hawk at limanowa.net  Thu Sep 20 09:00:54 2007
From: hawk at limanowa.net (=?ISO-8859-2?Q?Marcin_Kr=F3l?=)
Date: Thu, 20 Sep 2007 09:00:54 +0200
Subject: BR-s and R-s policy
In-Reply-To: <200709200857.11218.arekm@maven.pl>
References: <1190269989.3472.5.camel@ipv6-localnet>	<46F218AB.3090108@limanowa.net>
	<200709200857.11218.arekm@maven.pl>
Message-ID: <46F21AA6.80803@limanowa.net>

> It's used to ensure that there are latest packages on the builders. That's the 
> only reason I know.

I always thought its RM job to maintain builders. But what do I know... :)

M.



From arekm at maven.pl  Thu Sep 20 09:12:48 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Thu, 20 Sep 2007 09:12:48 +0200
Subject: BR-s and R-s policy
In-Reply-To: <46F21AA6.80803@limanowa.net>
References: <1190269989.3472.5.camel@ipv6-localnet>
	<200709200857.11218.arekm@maven.pl> <46F21AA6.80803@limanowa.net>
Message-ID: <200709200912.49092.arekm@maven.pl>

On Thursday 20 of September 2007, Marcin Kr?l wrote:
> > It's used to ensure that there are latest packages on the builders.
> > That's the only reason I know.
>
> I always thought its RM job to maintain builders. But what do I know... :)

Not only RM has rights to send packages to builders.

> M.

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


From zswi at pers.pl  Thu Sep 20 09:30:57 2007
From: zswi at pers.pl (=?utf-8?q?Rafa=C5=82_Cygnarowski?=)
Date: Thu, 20 Sep 2007 09:30:57 +0200
Subject: Unclear Firefox situation
In-Reply-To: <1190268965.3472.0.camel@ipv6-localnet>
References: <89b6ba3a0709190709o6fa8e110kb64e25b621500ba4@mail.gmail.com>
	<200709192223.02098.zswi@pers.pl>
	<1190268965.3472.0.camel@ipv6-localnet>
Message-ID: <200709200931.03336.zswi@pers.pl>

Dnia czwartek, 20 wrze?nia 2007, Cezary Krzyzanowski napisa?:
> Dnia 19-09-2007, ?r o godzinie 22:22 +0200, Rafa? Cygnarowski
>
> napisa?(a):
> > <quotation>
> > If an individual or organization is creating a Community Edition of
> > Mozilla Firefox or Thunderbird, it must use the names "Firefox Community
> > Edition" or "Thunderbird Community Edition" to identify this software.
> > These names may be further qualified to identify the software (e.g.
> > "Firefox Community Edition, French", "Thunderbird Community Edition,
> > Joe's optimized AMD Opteron build", etc.). Localizers may also translate
> > the words "Community Edition". </quotation>
> >
> > So... Mozilla Firefox should be called just Firefox... isn't it true?
>
> Ehm -- and not 'Fierefox Community Edition' ??

Yes, I just shorted MFCE and FCE to MF and F... 
But it seems like Bon Echo name is illegal(?) int this case and we should 
use "Firefox".

Regards,
-- 
Rafa? Cygnarowski
rafi at pers.pl
-------------- 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/20070920/a2f4e39b/attachment.sig>

From dhubleizh at o2.pl  Thu Sep 20 10:02:52 2007
From: dhubleizh at o2.pl (Cezary Krzyzanowski)
Date: Thu, 20 Sep 2007 10:02:52 +0200
Subject: BR-s and R-s policy
In-Reply-To: <200709200857.11218.arekm@maven.pl>
References: <1190269989.3472.5.camel@ipv6-localnet>
	<46F218AB.3090108@limanowa.net>  <200709200857.11218.arekm@maven.pl>
Message-ID: <1190275372.13591.6.camel@ipv6-localnet>

Dnia 20-09-2007, Cz o godzinie 08:57 +0200, Arkadiusz Miskiewicz
napisa?(a):
> On Thursday 20 of September 2007, Marcin Kr?l wrote:
> > > So is this some kind of policy, to require newest packages possible at
> > > the time of upping spec?
> >
> > It seems so. Its stupid IMO to bump version to highest possible ignoring
> > real requirements. 
> 
> It's used to ensure that there are latest packages on the builders. That's the 
> only reason I know.
> 

Ehm -- but wouldn't that be achieved just by installing packages on
build?

Every package needs to be build anyway, so it would be just logical to
install it then.

Cz at rny



From hawk at limanowa.net  Thu Sep 20 10:41:30 2007
From: hawk at limanowa.net (=?ISO-8859-2?Q?Marcin_Kr=F3l?=)
Date: Thu, 20 Sep 2007 10:41:30 +0200
Subject: BR-s and R-s policy
In-Reply-To: <200709200912.49092.arekm@maven.pl>
References: <1190269989.3472.5.camel@ipv6-localnet>	<200709200857.11218.arekm@maven.pl>
	<46F21AA6.80803@limanowa.net> <200709200912.49092.arekm@maven.pl>
Message-ID: <46F2323A.9070102@limanowa.net>

> Not only RM has rights to send packages to builders.

I don't get it. If someone will send some package it will be
automagically upgraded on builders. If such upgrade will fail on deps
I'll usually know about it quite soon and will have to fix it manually
anyway. If someone will send something that I'll reject from moving to
main tree I'll have to downgrade it manually too.

The only good thing from bumping version I see is that when upgrade on
builders will fail user will be unable to build dependant stuff till
I'll fix it. I had such situation only once since RMing Ra and Ac and it
was piece of cake to fix (manual poldek upgra, rel++, stbr). I still
don't see any advantage in bumping those versions.

M.


From arekm at maven.pl  Thu Sep 20 10:49:30 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Thu, 20 Sep 2007 10:49:30 +0200
Subject: BR-s and R-s policy
In-Reply-To: <46F2323A.9070102@limanowa.net>
References: <1190269989.3472.5.camel@ipv6-localnet>
	<200709200912.49092.arekm@maven.pl> <46F2323A.9070102@limanowa.net>
Message-ID: <200709201049.30196.arekm@maven.pl>

On Thursday 20 of September 2007, Marcin Kr?l wrote:

> The only good thing from bumping version I see is that when upgrade on
> builders will fail user will be unable to build dependant stuff till
> I'll fix it.

It happens from time to time and this is exactly the problem I was referring 
to. (and user can fix the problem himself and resend)

> M.

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


From patrys at pld-linux.org  Thu Sep 20 11:19:58 2007
From: patrys at pld-linux.org (Patryk Zawadzki)
Date: Thu, 20 Sep 2007 11:19:58 +0200
Subject: Unclear Firefox situation
In-Reply-To: <200709200931.03336.zswi@pers.pl>
References: <89b6ba3a0709190709o6fa8e110kb64e25b621500ba4@mail.gmail.com>
	<200709192223.02098.zswi@pers.pl>
	<1190268965.3472.0.camel@ipv6-localnet>
	<200709200931.03336.zswi@pers.pl>
Message-ID: <89b6ba3a0709200219k547b409bua36e1ba5bafd3ad9@mail.gmail.com>

On 9/20/07, Rafa? Cygnarowski <zswi at pers.pl> wrote:
> Dnia czwartek, 20 wrze?nia 2007, Cezary Krzyzanowski napisa?:
> > Dnia 19-09-2007, ?r o godzinie 22:22 +0200, Rafa? Cygnarowski
> >
> > napisa?(a):
> > > <quotation>
> > > If an individual or organization is creating a Community Edition of
> > > Mozilla Firefox or Thunderbird, it must use the names "Firefox Community
> > > Edition" or "Thunderbird Community Edition" to identify this software.
> > > These names may be further qualified to identify the software (e.g.
> > > "Firefox Community Edition, French", "Thunderbird Community Edition,
> > > Joe's optimized AMD Opteron build", etc.). Localizers may also translate
> > > the words "Community Edition". </quotation>
> > >
> > > So... Mozilla Firefox should be called just Firefox... isn't it true?
> >
> > Ehm -- and not 'Fierefox Community Edition' ??
>
> Yes, I just shorted MFCE and FCE to MF and F...
> But it seems like Bon Echo name is illegal(?) int this case and we should
> use "Firefox".

Bon Echo is not illegal. The above rules apply to packages containing
"Firefox" (or any other Mozilla trademark) in their names.

-- 
Patryk Zawadzki
Generated Content

From hawk at limanowa.net  Thu Sep 20 11:25:26 2007
From: hawk at limanowa.net (=?ISO-8859-2?Q?Marcin_Kr=F3l?=)
Date: Thu, 20 Sep 2007 11:25:26 +0200
Subject: BR-s and R-s policy
In-Reply-To: <200709201049.30196.arekm@maven.pl>
References: <1190269989.3472.5.camel@ipv6-localnet>	<200709200912.49092.arekm@maven.pl>
	<46F2323A.9070102@limanowa.net> <200709201049.30196.arekm@maven.pl>
Message-ID: <46F23C86.9060003@limanowa.net>

>> The only good thing from bumping version I see is that when upgrade on
>> builders will fail user will be unable to build dependant stuff till
>> I'll fix it.
> 
> It happens from time to time and this is exactly the problem I was referring 
> to. (and user can fix the problem himself and resend)

Correct me if I'm wrong, but users don't have access to send commands to
builders (at least for Ac). How they're supposed to say builder to
perform upgrade which has failed on dependencies? They are usually
sending mails about failed upgrades and then RM has to fix problem
manually. So "fixing" will look exactly the same way without dependecies.

M.


From qboosh at pld-linux.org  Thu Sep 20 11:29:58 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 20 Sep 2007 11:29:58 +0200
Subject: BR-s and R-s policy
In-Reply-To: <1190269989.3472.5.camel@ipv6-localnet>
References: <1190269989.3472.5.camel@ipv6-localnet>
Message-ID: <20070920092958.GA6931@stranger.qboosh.pl>

On Thu, Sep 20, 2007 at 08:33:09AM +0200, Cezary Krzyzanowski wrote:
> Patrys asked me to up evolution spec to 1.12 (corresponding with GNOME
> 2.20) and I've spotted, that during the GNOME packages update all the
> BR-s and R-s of gnome packages were upped to 2.20 line.
> 
> The question is -- Is this necessary? I mean I've looked into
> evolution's configure.in and it seems it doesn't need half the newest
> packages that are listed in BR-s and R-s in evolution.spec (like it
> needs GConf2 >= 2.0.0, not newest, shiniest 2.19).

Bumping always to currently latest version is not necessary and
sometimes annoying.
But specifying versions of packages from the same GNOME release just in
packages belonging to the same GNOME release (and similarly for
KDE/XFCE/etc.) to get consistent package set is fine. It seems that
at least some GNOME packages are not tested with older dependent
packages and need some newer in fact.


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


From arekm at maven.pl  Thu Sep 20 12:00:17 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Thu, 20 Sep 2007 12:00:17 +0200
Subject: BR-s and R-s policy
In-Reply-To: <46F23C86.9060003@limanowa.net>
References: <1190269989.3472.5.camel@ipv6-localnet>
	<200709201049.30196.arekm@maven.pl> <46F23C86.9060003@limanowa.net>
Message-ID: <200709201200.18014.arekm@maven.pl>

On Thursday 20 of September 2007, Marcin Kr?l wrote:
> >> The only good thing from bumping version I see is that when upgrade on
> >> builders will fail user will be unable to build dependant stuff till
> >> I'll fix it.
> >
> > It happens from time to time and this is exactly the problem I was
> > referring to. (and user can fix the problem himself and resend)
>
> Correct me if I'm wrong, but users don't have access to send commands to
> builders (at least for Ac). How they're supposed to say builder to
> perform upgrade which has failed on dependencies? They are usually
> sending mails about failed upgrades and then RM has to fix problem
> manually. So "fixing" will look exactly the same way without dependecies.

User sends request for: libcrap, few seconds later for appX appY. libcrap 
installes fine on i386 but not i686. appX and appY on i386 rebuilds fine with 
new libcrap and with old libcrap on i686. Whoops.

> M.

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


From hawk at limanowa.net  Thu Sep 20 12:19:22 2007
From: hawk at limanowa.net (=?ISO-8859-2?Q?Marcin_Kr=F3l?=)
Date: Thu, 20 Sep 2007 12:19:22 +0200
Subject: BR-s and R-s policy
In-Reply-To: <200709201200.18014.arekm@maven.pl>
References: <1190269989.3472.5.camel@ipv6-localnet>	<200709201049.30196.arekm@maven.pl>
	<46F23C86.9060003@limanowa.net> <200709201200.18014.arekm@maven.pl>
Message-ID: <46F2492A.70305@limanowa.net>

> User sends request for: libcrap, few seconds later for appX appY. libcrap 
> installes fine on i386 but not i686. appX and appY on i386 rebuilds fine with 
> new libcrap and with old libcrap on i686. Whoops.

True, but only difference is that RM will have to delete appX and appY
for i686 and user or RM will need to resend it using auto- tag. I'd
prefer to have correct version deps and fix such issues myself than
doesn't have that issues but have to create and maintain additional
branches where they aren't needed.

M.


From baggins at sith.mimuw.edu.pl  Thu Sep 20 12:54:31 2007
From: baggins at sith.mimuw.edu.pl (Jan Rekorajski)
Date: Thu, 20 Sep 2007 12:54:31 +0200
Subject: BR-s and R-s policy
In-Reply-To: <20070920092958.GA6931@stranger.qboosh.pl>
References: <1190269989.3472.5.camel@ipv6-localnet>
	<20070920092958.GA6931@stranger.qboosh.pl>
Message-ID: <20070920105431.GC31311@sith.mimuw.edu.pl>

On Thu, 20 Sep 2007, Jakub Bogusz wrote:

> On Thu, Sep 20, 2007 at 08:33:09AM +0200, Cezary Krzyzanowski wrote:
> > Patrys asked me to up evolution spec to 1.12 (corresponding with GNOME
> > 2.20) and I've spotted, that during the GNOME packages update all the
> > BR-s and R-s of gnome packages were upped to 2.20 line.
> > 
> > The question is -- Is this necessary? I mean I've looked into
> > evolution's configure.in and it seems it doesn't need half the newest
> > packages that are listed in BR-s and R-s in evolution.spec (like it
> > needs GConf2 >= 2.0.0, not newest, shiniest 2.19).
> 
> Bumping always to currently latest version is not necessary and
> sometimes annoying.
> But specifying versions of packages from the same GNOME release just in
> packages belonging to the same GNOME release (and similarly for
> KDE/XFCE/etc.) to get consistent package set is fine. It seems that
> at least some GNOME packages are not tested with older dependent
> packages and need some newer in fact.

That's exactly the reason. There were problems in the past with packages
from different GNOME releases that did compile but didn't work.
The current "always latest BR" in GNOME it's to ensure the entire
environment is consistent.

Janek
-- 
Jan Rekorajski            |  ALL SUSPECTS ARE GUILTY. PERIOD!
baggins<at>mimuw.edu.pl   |  OTHERWISE THEY WOULDN'T BE SUSPECTS, WOULD THEY?
BOFH, MANIAC              |                   -- TROOPS by Kevin Rubio


From arekm at maven.pl  Thu Sep 20 12:57:50 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Thu, 20 Sep 2007 12:57:50 +0200
Subject: BR-s and R-s policy
In-Reply-To: <46F2492A.70305@limanowa.net>
References: <1190269989.3472.5.camel@ipv6-localnet>
	<200709201200.18014.arekm@maven.pl> <46F2492A.70305@limanowa.net>
Message-ID: <200709201257.50904.arekm@maven.pl>

On Thursday 20 of September 2007, Marcin Kr?l wrote:
> > User sends request for: libcrap, few seconds later for appX appY. libcrap
> > installes fine on i386 but not i686. appX and appY on i386 rebuilds fine
> > with new libcrap and with old libcrap on i686. Whoops.
>
> True, but only difference is that RM will have to delete appX and appY
> for i686 and user or RM will need to resend it using auto- tag. I'd
> prefer to have correct version deps and fix such issues myself than
> doesn't have that issues but have to create and maintain additional
> branches where they aren't needed.

While rising BR makes no need for any manual action on RM side and can be 
fixed immediately by user ;)

> M.

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


From glen at delfi.ee  Thu Sep 20 13:12:08 2007
From: glen at delfi.ee (Elan =?iso-8859-2?q?Ruusam=E4e?=)
Date: Thu, 20 Sep 2007 14:12:08 +0300
Subject: BR-s and R-s policy
In-Reply-To: <200709201257.50904.arekm@maven.pl>
References: <1190269989.3472.5.camel@ipv6-localnet>
	<46F2492A.70305@limanowa.net> <200709201257.50904.arekm@maven.pl>
Message-ID: <200709201412.09040.glen@delfi.ee>

On Thursday 20 September 2007 13:57:50 Arkadiusz Miskiewicz wrote:
> On Thursday 20 of September 2007, Marcin Kr?l wrote:
> > > User sends request for: libcrap, few seconds later for appX appY.
> > > libcrap installes fine on i386 but not i686. appX and appY on i386
> > > rebuilds fine with new libcrap and with old libcrap on i686. Whoops.
> >
> > True, but only difference is that RM will have to delete appX and appY
> > for i686 and user or RM will need to resend it using auto- tag. I'd
> > prefer to have correct version deps and fix such issues myself than
> > doesn't have that issues but have to create and maintain additional
> > branches where they aren't needed.
>
> While rising BR makes no need for any manual action on RM side and can be
> fixed immediately by user ;)

one can trash specs in place called SPECS/test.spec:RPM [1] and send that one to builders.

[1] http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/Attic/test.spec?only_with_tag=RPM

-- 
glen


From blues at pld-linux.org  Thu Sep 20 13:29:51 2007
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Thu, 20 Sep 2007 13:29:51 +0200 (CEST)
Subject: BR-s and R-s policy
In-Reply-To: <46F218AB.3090108@limanowa.net>
References: <1190269989.3472.5.camel@ipv6-localnet>
	<46F218AB.3090108@limanowa.net>
Message-ID: <alpine.LNX.0.9999.0709201327450.29739@fgnss.gnfx.tqn.cy>

On Thu, 20 Sep 2007, Marcin Kr?l wrote:
> > So is this some kind of policy, to require newest packages possible at
> > the time of upping spec?
> It seems so.

no, it's not.

It was done sometimes for things like KDE, gnome, etc to force the updates 
and ensure that libraries will be upgraded.

-- 
pozdr.  Pawe? Go?aszewski          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 arekm at maven.pl  Sun Sep 23 19:25:55 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sun, 23 Sep 2007 19:25:55 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <89b6ba3a0709180753r416281e9m945142f9e03c858a@mail.gmail.com>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<200709181636.12587.pld@nius.waw.pl>
	<89b6ba3a0709180753r416281e9m945142f9e03c858a@mail.gmail.com>
Message-ID: <200709231925.55404.arekm@maven.pl>

On Tuesday 18 of September 2007, Patryk Zawadzki wrote:
> On 9/18/07, Marcin Kurzyna <pld at nius.waw.pl> wrote:
> > To specify even more. Above hardcoded path is relevant only for 3 files:
> >
> > Basenames
> > Conflictname
> > Providename
> >
> > and of course hardlinks work as well. ok - end of self replys
>
> arekm promised to take a look into the backported code for any easy fixes.

Please test latest HEAD rpm and poldek.

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


From krystian at kamionek.net  Sun Sep 23 22:07:27 2007
From: krystian at kamionek.net (Krystian Tomczyk)
Date: Sun, 23 Sep 2007 22:07:27 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <200709231925.55404.arekm@maven.pl>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<200709181636.12587.pld@nius.waw.pl>
	<89b6ba3a0709180753r416281e9m945142f9e03c858a@mail.gmail.com>
	<200709231925.55404.arekm@maven.pl>
Message-ID: <1190578047.3340.1.camel@laptom>

Dnia 23-09-2007, N o godzinie 19:25 +0200, Arkadiusz Miskiewicz
napisa?(a):
> Please test latest HEAD rpm and poldek.
rpm -q rpm poldek
rpm-4.4.9-9.i686
poldek-0.21-0.20070703.00.4.i686
>From th-test - works for me :)
-- 
Pozdrawiam
Krystian T.

             "errare humanum est..."



From arekm at maven.pl  Sun Sep 23 22:12:56 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Sun, 23 Sep 2007 22:12:56 +0200
Subject: [Th] vserver + vpoldek + vrpm
In-Reply-To: <1190578047.3340.1.camel@laptom>
References: <89b6ba3a0709040212v295dcb08o57b953a83ef0c7de@mail.gmail.com>
	<200709231925.55404.arekm@maven.pl>
	<1190578047.3340.1.camel@laptom>
Message-ID: <200709232212.56595.arekm@maven.pl>

On Sunday 23 of September 2007, Krystian Tomczyk wrote:
> Dnia 23-09-2007, N o godzinie 19:25 +0200, Arkadiusz Miskiewicz
>
> napisa?(a):
> > Please test latest HEAD rpm and poldek.
>
> rpm -q rpm poldek
> rpm-4.4.9-9.i686
> poldek-0.21-0.20070703.00.4.i686
>
> >From th-test - works for me :)

Be VERY, VERY careful in using it. It turns out that it mixes something in db 
and can lead to rpmdb trashing (when using in and outside of chroot).

I'm going to delete it until proper solution is found.
-- 
Arkadiusz Mi?kiewicz        PLD/Linux Team
arekm / maven.pl            http://ftp.pld-linux.org/


From wrobell at pld-linux.org  Mon Sep 24 22:41:36 2007
From: wrobell at pld-linux.org (wrobell)
Date: Mon, 24 Sep 2007 21:41:36 +0100
Subject: BR-s and R-s policy
In-Reply-To: <20070920105431.GC31311@sith.mimuw.edu.pl>
References: <1190269989.3472.5.camel@ipv6-localnet>
	<20070920092958.GA6931@stranger.qboosh.pl>
	<20070920105431.GC31311@sith.mimuw.edu.pl>
Message-ID: <20070924204136.GD9829@borg>

On Thu, Sep 20, 2007 at 12:54:31PM +0200, Jan Rekorajski wrote:
> On Thu, 20 Sep 2007, Jakub Bogusz wrote:
> 
> > On Thu, Sep 20, 2007 at 08:33:09AM +0200, Cezary Krzyzanowski wrote:
> > > Patrys asked me to up evolution spec to 1.12 (corresponding with GNOME
> > > 2.20) and I've spotted, that during the GNOME packages update all the
> > > BR-s and R-s of gnome packages were upped to 2.20 line.
> > > 
> > > The question is -- Is this necessary? I mean I've looked into
> > > evolution's configure.in and it seems it doesn't need half the newest
> > > packages that are listed in BR-s and R-s in evolution.spec (like it
> > > needs GConf2 >= 2.0.0, not newest, shiniest 2.19).
> > 
> > Bumping always to currently latest version is not necessary and
> > sometimes annoying.
> > But specifying versions of packages from the same GNOME release just in
> > packages belonging to the same GNOME release (and similarly for
> > KDE/XFCE/etc.) to get consistent package set is fine. It seems that
> > at least some GNOME packages are not tested with older dependent
> > packages and need some newer in fact.
> 
> That's exactly the reason. There were problems in the past with packages
> from different GNOME releases that did compile but didn't work.
> The current "always latest BR" in GNOME it's to ensure the entire
> environment is consistent.

just to support above... if somethings goes wrong than "latest-versioning"
procedure prevents hell, which happened to me several times while upgrading
gnome in the past.

if one wants to kill this procedure, than we need another one to secure
work performed while upgrading complex set of packages.

regards,

    wrobell <wrobell at pld-linux.org>


From glen at delfi.ee  Thu Sep 27 09:56:19 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 27 Sep 2007 10:56:19 +0300
Subject: squid 2.6
Message-ID: <200709271056.20098.glen@delfi.ee>

are there any known incompatabilities from 2.5 -> 2.6?
if none known then i'd push 2.6 to ac-updates.

-- 
glen