From qboosh at pld-linux.org  Wed Jul  4 10:19:06 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 4 Jul 2007 10:19:06 +0200
Subject: SPECS (AC-branch): qt4.spec - built lrelease waits forever for
	fut...
In-Reply-To: <SPECS_qt4.spec.1.138.2.5@pld-linux.org>
References: <SPECS_qt4.spec.1.138.2.4@pld-linux.org>
	<SPECS_qt4.spec.1.138.2.5@pld-linux.org>
Message-ID: <20070704081906.GA26830@mail>

On Wed, Jul 04, 2007 at 09:32:27AM +0200, glen wrote:
> Author: glen                         Date: Wed Jul  4 07:32:27 2007 GMT
> Module: SPECS                         Tag: AC-branch
> ---- Log message:
> - built lrelease waits forever for futex (on ac-alpha and on fly) -- block alpha

How ac-alpha can hang on futex if it's unsupported on Linux 2.4? :)


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


From glen at delfi.ee  Wed Jul  4 11:56:22 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 4 Jul 2007 12:56:22 +0300
Subject: SPECS (AC-branch): qt4.spec - built lrelease waits forever for
	fut...
In-Reply-To: <20070704081906.GA26830@mail>
References: <SPECS_qt4.spec.1.138.2.4@pld-linux.org>
	<SPECS_qt4.spec.1.138.2.5@pld-linux.org>
	<20070704081906.GA26830@mail>
Message-ID: <200707041256.22895.glen@delfi.ee>

On Wednesday 04 July 2007 11:19:06 Jakub Bogusz wrote:
> On Wed, Jul 04, 2007 at 09:32:27AM +0200, glen wrote:
> > Author: glen                         Date: Wed Jul  4 07:32:27 2007 GMT
> > Module: SPECS                         Tag: AC-branch
> > ---- Log message:
> > - built lrelease waits forever for futex (on ac-alpha and on fly) --
> > block alpha
>
> How ac-alpha can hang on futex if it's unsupported on Linux 2.4? :)

i was able to debug on fly, but ac-alpha build log when it was killed was 
terminated at same place.

+ cp /home/users/glen/rpm/SOURCES/qt4_pl.ts translations/qt_pl.ts
+ bin/lrelease translations/qt_pl.ts -qm translations/qt_pl.qm
+ LD_LIBRARY_PATH=lib


strace shows:
) = -1 EINTR (Interrupted system call)
--- SIGWINCH (Window changed) @ 0 (0) ---
futex(0x12004e094, FUTEX_WAIT, 1, NULL) = -1 EINTR (Interrupted system call)
--- SIGWINCH (Window changed) @ 0 (0) ---
futex(0x12004e094, FUTEX_WAIT, 1, NULL) = -1 EINTR (Interrupted system call)
--- SIGWINCH (Window changed) @ 0 (0) ---
futex(0x12004e094, FUTEX_WAIT, 1, NULL) = -1 EINTR (Interrupted system call)
--- SIGWINCH (Window changed) @ 0 (0) ---
futex(0x12004e094, FUTEX_WAIT, 1, NULL) = -1 EINTR (Interrupted system call)
--- SIGWINCH (Window changed) @ 0 (0) ---
futex(0x12004e094, FUTEX_WAIT, 1, NULL <unfinished ...>
[glen at fly qt-x11-opensource-src-4.3.0]$ arch; uname -a
alpha
Linux fly 2.6.2 #3 Wed Feb 11 10:19:22 CET 2004 alpha EV56 unknown PLD Linux


-- 
glen


From jerome.auge at cesamnet.fr  Wed Jul  4 22:13:40 2007
From: jerome.auge at cesamnet.fr (=?ISO-8859-1?Q?J=E9r=F4me_Aug=E9?=)
Date: Wed, 04 Jul 2007 22:13:40 +0200
Subject: make-3.81 in AC
Message-ID: <468BFF74.7080103@cesamnet.fr>

Hi,

Building an openwrt firmware, I stumbled on a bug with make : sometime
it exits with "make: *** virtual memory exhausted.  Stop.", without
reasons, swap being 100% free.
It seems various people are having this error message with other
projects/Makefiles, and it went away by upgrading to make 3.81.

I upgraded make with the make-3.81-1 package from TH and it fixed my
problem.

Can someone update make to version 3.81 in AC ?

Regards,
J?r?me Aug?


From glen at delfi.ee  Wed Jul  4 23:46:02 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 5 Jul 2007 00:46:02 +0300
Subject: make-3.81 in AC
In-Reply-To: <468BFF74.7080103@cesamnet.fr>
References: <468BFF74.7080103@cesamnet.fr>
Message-ID: <200707050046.02160.glen@delfi.ee>

it seems already built:

$ autotag make.spec
make.spec:auto-ac-make-3_81-1

hghw why it was never moved to ac-main/ac-updates

On Wednesday 04 July 2007 23:13, J?r?me Aug? wrote:
> Hi,
>
> Building an openwrt firmware, I stumbled on a bug with make : sometime
> it exits with "make: *** virtual memory exhausted.  Stop.", without
> reasons, swap being 100% free.
> It seems various people are having this error message with other
> projects/Makefiles, and it went away by upgrading to make 3.81.
>
> I upgraded make with the make-3.81-1 package from TH and it fixed my
> problem.
>
> Can someone update make to version 3.81 in AC ?
>
> Regards,
> J?r?me Aug?
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



-- 
glen


From tomasz.wittner at gmail.com  Wed Jul  4 23:58:09 2007
From: tomasz.wittner at gmail.com (Tomasz Wittner)
Date: Wed, 4 Jul 2007 23:58:09 +0200
Subject: make-3.81 in AC
In-Reply-To: <200707050046.02160.glen@delfi.ee>
References: <468BFF74.7080103@cesamnet.fr> <200707050046.02160.glen@delfi.ee>
Message-ID: <200707042358.09845.tomasz.wittner@gmail.com>

On Wed 4. of July 2007, 23:46, Elan Ruusam?e wrote:
> it seems already built:
>
> $ autotag make.spec
> make.spec:auto-ac-make-3_81-1
>
> hghw why it was never moved to ac-main/ac-updates
Here is explanation:
http://src.ac.pld-linux.org/~buildsrc/queue.html
I upgraded make on Ac-branch and sent it to builders right after reading 
Jerome's e-mail.
[...]
-- 
Tomasz Wittner


From glen at delfi.ee  Thu Jul  5 00:26:34 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 5 Jul 2007 01:26:34 +0300
Subject: make-3.81 in AC
In-Reply-To: <200707042358.09845.tomasz.wittner@gmail.com>
References: <468BFF74.7080103@cesamnet.fr> <200707050046.02160.glen@delfi.ee>
	<200707042358.09845.tomasz.wittner@gmail.com>
Message-ID: <200707050126.34820.glen@delfi.ee>

On Thursday 05 July 2007 00:58, Tomasz Wittner wrote:
> On Wed 4. of July 2007, 23:46, Elan Ruusam?e wrote:
> > it seems already built:
> >
> > $ autotag make.spec
> > make.spec:auto-ac-make-3_81-1
> >
> > hghw why it was never moved to ac-main/ac-updates
>
> Here is explanation:
> http://src.ac.pld-linux.org/~buildsrc/queue.html
> I upgraded make on Ac-branch and sent it to builders right after reading
> Jerome's e-mail.
> [...]

could you explain or copy paste some log?
as twittner (yours) request failed, while mine (test and ready) succeeded.
and your request as no log at this time

42739. 2007.07.04 23:42:20 from glen a33bea1e-ef31-4325-b917-f0f05d2438d4, 3, upgrade
 make-3.81-1.src.rpm (make.spec -R auto-ac-make-3_81-1 ) [ac-i686:OK ac-i586:OK ac-i386:OK ac-athlon:OK ac-alpha:? ac-sparc:OK ac-amd64:OK ac-ppc:OK]

42738. 2007.07.04 23:01:42 from twittner 60ffabe3-12f1-4d1c-8462-2c480e83e2a6, 2, upgrade
 make-3.81-1.src.rpm (make.spec -R AC-branch ) [ac-i686:OK ac-i586:OK ac-i386:OK ac-athlon:OK ac-alpha:OK ac-sparc:OK ac-amd64:OK ac-ppc:OK]

42737. 2007.07.04 22:32:15 from twittner b11b97e0-1e2a-495b-88c0-e0b114b9efaa, 2, test-build
 make-3.81-1.src.rpm (make.spec -R HEAD ) [ac-i686:FAIL ac-i586:FAIL ac-i386:FAIL ac-athlon:FAIL ac-alpha:FAIL ac-sparc:FAIL ac-amd64:FAIL ac-ppc:FAIL]

-- 
glen


From blues at pld-linux.org  Thu Jul  5 10:04:33 2007
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Thu, 5 Jul 2007 10:04:33 +0200 (CEST)
Subject: make-3.81 in AC
In-Reply-To: <200707050126.34820.glen@delfi.ee>
References: <468BFF74.7080103@cesamnet.fr> <200707050046.02160.glen@delfi.ee>
	<200707042358.09845.tomasz.wittner@gmail.com>
	<200707050126.34820.glen@delfi.ee>
Message-ID: <Pine.LNX.4.64N.0707051003360.31884@fgnss.gnfx.tqn.cy>

On Thu, 5 Jul 2007, Elan Ruusam?e wrote:
> could you explain or copy paste some log? as twittner (yours) request 
> failed, while mine (test and ready) succeeded. and your request as no 
> log at this time
[...]
> 42738. 2007.07.04 23:01:42 from twittner 60ffabe3-12f1-4d1c-8462-2c480e83e2a6, 2, upgrade
>  make-3.81-1.src.rpm (make.spec -R AC-branch ) [ac-i686:OK ac-i586:OK ac-i386:OK ac-athlon:OK ac-alpha:OK ac-sparc:OK ac-amd64:OK ac-ppc:OK]
                                     ^^^^^^^^^
> 42737. 2007.07.04 22:32:15 from twittner b11b97e0-1e2a-495b-88c0-e0b114b9efaa, 2, test-build
>  make-3.81-1.src.rpm (make.spec -R HEAD ) [ac-i686:FAIL ac-i586:FAIL ac-i386:FAIL ac-athlon:FAIL ac-alpha:FAIL ac-sparc:FAIL ac-amd64:FAIL ac-ppc:FAIL]
                                     ^^^^

This is the reason.

-- 
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 adamg at biomerieux.pl  Mon Jul  9 09:42:53 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Mon, 9 Jul 2007 09:42:53 +0200
Subject: geninitrd 8385 patches and comments
In-Reply-To: <20070522131106.GA16290@jajo.eggsoft.pl>
References: <20070522131106.GA16290@jajo.eggsoft.pl>
Message-ID: <20070709074253.GA20821@mysza.eu.org>

On Tue, May 22, 2007 at 03:11:06PM +0200, Jacek Konieczny wrote:
> I made two patches (attached) to address the second problem:
> 1. geninitrd-rootdev.patch
> 2. geninitrd-lvm_initramfs.patch

I've applied those patches on trunk. 

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


From radek at pld-linux.org  Fri Jul 13 11:09:53 2007
From: radek at pld-linux.org (Radoslaw Zielinski)
Date: Fri, 13 Jul 2007 11:09:53 +0200
Subject: [th][builders] access to /dev/tty*, /dev/pts -- perl-Expect
Message-ID: <20070713090953.GA3580@bzium>

perl-Expect's tests fail while trying to access tty / pty:

http://buildlogs.pld-linux.org/index.php?dist=th&arch=i686&ok=0&id=1ffb2a57b980bf3e1ad09b22ddc74e3b
http://buildlogs.pld-linux.org/index.php?dist=th&arch=x86_64&ok=0&id=69566d6707d2de644bbcbfd1c9462363
http://buildlogs.pld-linux.org/index.php?dist=th&arch=ppc&ok=0&id=48d5eef804499b4df71045c61b47524a

I assume it's builder's configuration; passes just fine on athlon and i486.

Ideas?

-- 
Rados?aw Zieli?ski <radek at pld-linux.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070713/cf623409/attachment.sig>

From ankry at green.mif.pg.gda.pl  Fri Jul 13 11:18:54 2007
From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz)
Date: Fri, 13 Jul 2007 11:18:54 +0200 (CEST)
Subject: [th][builders] access to /dev/tty*, /dev/pts -- perl-Expect
In-Reply-To: <20070713090953.GA3580@bzium> from "Radoslaw Zielinski" at Jul 13,
	2007 11:09:53 AM
Message-ID: <200707130918.l6D9Isls028673@green.mif.pg.gda.pl>

Radoslaw Zielinski wrote:
> perl-Expect's tests fail while trying to access tty / pty:
> 
> http://buildlogs.pld-linux.org/index.php?dist=3Dth&arch=3Di686&ok=3D0&id=3D=
> 1ffb2a57b980bf3e1ad09b22ddc74e3b
> http://buildlogs.pld-linux.org/index.php?dist=3Dth&arch=3Dx86_64&ok=3D0&id=
> =3D69566d6707d2de644bbcbfd1c9462363
> http://buildlogs.pld-linux.org/index.php?dist=3Dth&arch=3Dppc&ok=3D0&id=3D4=
> 8d5eef804499b4df71045c61b47524a
> 
> I assume it's builder's configuration; passes just fine on athlon and i486.
> 
> Ideas?

First: I would suggest sb with access to the builders checking whether
       /dev/pts is mounted...

-- 
=======================================================================
  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 adamg at biomerieux.pl  Sat Jul 14 09:52:43 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Sat, 14 Jul 2007 09:52:43 +0200
Subject: httpd.worker - kernel killer?
Message-ID: <20070714075243.GA7700@mysza.eu.org>

Hi,

Our CVS suddenly stopped working yesterday. When I used 'xm cons' to get
a console I saw the following:


tty1 ep09-cvs login: Unable to handle kernel paging request at ffff880013318604 RIP:
<ffffffff802056ac>{gr_lookup_task_ip_table+60}
PGD 81e067 PUD 81f067 PMD 8b9067 PTE 0
Oops: 0000 [1] SMP
CPU 0
Modules linked in: ipv6 8250 serial_core reiserfs xfs exportfs ext3 mbcache jbd

Pid: 1222, comm: httpd.worker Not tainted 2.6.16.52-1xenUsmp #1
RIP: e030:[<ffffffff802056ac>] <ffffffff802056ac>{gr_lookup_task_ip_table+60}
RSP: e02b:ffff88001d68fea0  EFLAGS: 00010286
RAX: ffff880013318380 RBX: ffff880015567940 RCX: 0000000000007fed
RDX: ffff880008829fa0 RSI: 00000000101f49d9 RDI: 00000000bb5f00c1
RBP: ffff880001a623c0 R08: 0000000000000e9e R09: 0000000000005000
R10: 00000000ffffffff R11: 0000000000000000 R12: ffff88001e8516c0
R13: 0000000000887798 R14: 0000000000887778 R15: 0000000000000001
FS:  0000000000000000(0063) GS:ffffffff80468000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process httpd.worker (pid: 1222, threadinfo ffff88001d68e000, task ffff88001fe1c7b0)
Stack: ffffffff80205812 ffff88001e8516c0 ffff88001d68fed8 ffff8800189d03c0
       ffffffff8025bbc6 0000000000000000 0000001100000010 bb5f00c10e9e0002
       0000000000000000 0000000000000000
Call Trace: <ffffffff80205812>{gr_attach_curr_ip+82}
       <ffffffff8025bbc6>{sys_accept+326} <ffffffff8019f2a6>{do_sys_poll+454}
       <ffffffff8019e480>{__pollwait+0} <ffffffff8010b08a>{system_call+134}
       <ffffffff8010b004>{system_call+0}

Code: 39 b8 84 02 00 00 75 ea 39 b0 88 02 00 00 75 e2 66 44 39 80
RIP <ffffffff802056ac>{gr_lookup_task_ip_table+60} RSP <ffff88001d68fea0>
CR2: ffff880013318604



This is a domU running on a smp kernel (built from LINUX_2_6_16) on
amd64, however I had the same error (also caused by httpd.worker) on a
i686 smp. 

In both cases other domUs were unaffected. 

Any hints on how this could be debugged?

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


From ankry at green.mif.pg.gda.pl  Sun Jul 15 09:22:48 2007
From: ankry at green.mif.pg.gda.pl (Andrzej Krzysztofowicz)
Date: Sun, 15 Jul 2007 09:22:48 +0200 (CEST)
Subject: SPECS: perl-Devel-ebug.spec - release 2: tests off (until the
	fuck...
In-Reply-To: <SPECS_perl_Devel_ebug.spec.1.2@pld-linux.org> from "radek" at
	Jul 14, 2007 02:08:37 PM
Message-ID: <200707150722.l6F7MmdC024368@green.mif.pg.gda.pl>

radek wrote:
>  # Conditional build:
> -%bcond_without	tests		# do not perform "make test"
> +%bcond_with	tests		# do not perform "make test"

Tests should not be disabled without comment what is the problem in spec.

-- 
=======================================================================
  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 deejay1 at srem.org  Sun Jul 15 10:44:59 2007
From: deejay1 at srem.org (=?iso-8859-2?q?=A3ukasz_Jerna=B6?=)
Date: Sun, 15 Jul 2007 10:44:59 +0200
Subject: rpm and mono
Message-ID: <200707151045.01413.deejay1@srem.org>

Hello.

I just want to drop a note here that current mono-find-requires doesn't find 
libraries p-invoked from mono assemblies. They can be partially get from 
monodis --moduleref <assembly> but some sort of mechanism for pulling the 
complete soname would be needed, because just the name of the lib is included 
in the output from the previous command. Any hints?

-- 
?ukasz [DeeJay1] Jerna?


From qboosh at pld-linux.org  Sun Jul 15 13:45:31 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 15 Jul 2007 13:45:31 +0200
Subject: rpm and mono
In-Reply-To: <200707151045.01413.deejay1@srem.org>
References: <200707151045.01413.deejay1@srem.org>
Message-ID: <20070715114531.GA6001@stranger.qboosh.pl>

On Sun, Jul 15, 2007 at 10:44:59AM +0200, ?ukasz Jerna? wrote:
> Hello.
> 
> I just want to drop a note here that current mono-find-requires doesn't find 
> libraries p-invoked from mono assemblies. They can be partially get from 
> monodis --moduleref <assembly> but some sort of mechanism for pulling the 
> complete soname would be needed, because just the name of the lib is included 
> in the output from the previous command. Any hints?

We can read ${dllname}.config and determine dll->soname aliases.
But there is a problem with translating sonames to rpm Requires - they
are arch-dependent (because of "()(64-bit)" suffix on most 64-bit
systems with 64-bit mono).


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


From wolf.pld at gmail.com  Sun Jul 15 13:58:29 2007
From: wolf.pld at gmail.com (Bartosz Taudul)
Date: Sun, 15 Jul 2007 13:58:29 +0200
Subject: rpm and mono
In-Reply-To: <200707151045.01413.deejay1@srem.org>
References: <200707151045.01413.deejay1@srem.org>
Message-ID: <20070715115829.GA17221@bajzel>

On Sun, Jul 15, 2007 at 10:44:59AM +0200, ?ukasz Jerna? wrote:
> I just want to drop a note here that current mono-find-requires doesn't find 
> libraries p-invoked from mono assemblies. They can be partially get from 
> monodis --moduleref <assembly> but some sort of mechanism for pulling the 
> complete soname would be needed, because just the name of the lib is included 
> in the output from the previous command. Any hints?
In proper cross platform apps p-invokes should use windows dlls and unix
libraries should be specified in dllmap. What about that?

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


From n3npq at mac.com  Sun Jul 15 17:24:19 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 15 Jul 2007 11:24:19 -0400
Subject: rpm and mono
In-Reply-To: <20070715114531.GA6001@stranger.qboosh.pl>
References: <200707151045.01413.deejay1@srem.org>
	<20070715114531.GA6001@stranger.qboosh.pl>
Message-ID: <3853AB8B-EA46-451F-9006-25EA04C87B5B@mac.com>


On Jul 15, 2007, at 7:45 AM, Jakub Bogusz wrote:

> On Sun, Jul 15, 2007 at 10:44:59AM +0200, ?ukasz Jerna? wrote:
>> Hello.
>>
>> I just want to drop a note here that current mono-find-requires  
>> doesn't find
>> libraries p-invoked from mono assemblies. They can be partially  
>> get from
>> monodis --moduleref <assembly> but some sort of mechanism for  
>> pulling the
>> complete soname would be needed, because just the name of the lib  
>> is included
>> in the output from the previous command. Any hints?
>
> We can read ${dllname}.config and determine dll->soname aliases.
> But there is a problem with translating sonames to rpm Requires - they
> are arch-dependent (because of "()(64-bit)" suffix on most 64-bit
> systems with 64-bit mono).
>

If you send me a test case, I'll get you a patch to rpm.

73 de Jeff



From qboosh at pld-linux.org  Sun Jul 15 18:39:27 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 15 Jul 2007 18:39:27 +0200
Subject: rpm and mono
In-Reply-To: <3853AB8B-EA46-451F-9006-25EA04C87B5B@mac.com>
References: <200707151045.01413.deejay1@srem.org>
	<20070715114531.GA6001@stranger.qboosh.pl>
	<3853AB8B-EA46-451F-9006-25EA04C87B5B@mac.com>
Message-ID: <20070715163927.GB11442@stranger.qboosh.pl>

On Sun, Jul 15, 2007 at 11:24:19AM -0400, Jeff Johnson wrote:
> On Jul 15, 2007, at 7:45 AM, Jakub Bogusz wrote:
> > On Sun, Jul 15, 2007 at 10:44:59AM +0200, ?ukasz Jerna? wrote:
> >> Hello.
> >>
> >> I just want to drop a note here that current mono-find-requires  
> >> doesn't find
> >> libraries p-invoked from mono assemblies. They can be partially  
> >> get from
> >> monodis --moduleref <assembly> but some sort of mechanism for  
> >> pulling the
> >> complete soname would be needed, because just the name of the lib  
> >> is included
> >> in the output from the previous command. Any hints?
> >
> > We can read ${dllname}.config and determine dll->soname aliases.
> > But there is a problem with translating sonames to rpm Requires - they
> > are arch-dependent (because of "()(64-bit)" suffix on most 64-bit
> > systems with 64-bit mono).
> >
> 
> If you send me a test case, I'll get you a patch to rpm.

Well, it's not (directly) rpm problem.
And mono dependency generators are part of mono, not rpm.

Actually:
1. We can safely generate (arch-dependent) soname dependencies for
arch-dependent dotnet* packages (those with glue ELF libraries, like
gtk-sharp, or gnome-sharp, which started this discussion).
mono-find-requires script can detect mono version basing on monodis
(or libmono.so) ELF type.

2. if we decide to generate soname dependencies for some noarch
dotnet* package, it won't by noarch any longer.


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


From n3npq at mac.com  Sun Jul 15 18:53:17 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 15 Jul 2007 12:53:17 -0400
Subject: rpm and mono
In-Reply-To: <20070715163927.GB11442@stranger.qboosh.pl>
References: <200707151045.01413.deejay1@srem.org>
	<20070715114531.GA6001@stranger.qboosh.pl>
	<3853AB8B-EA46-451F-9006-25EA04C87B5B@mac.com>
	<20070715163927.GB11442@stranger.qboosh.pl>
Message-ID: <32A03AE5-95B6-44A3-A518-36939CBDE6E6@mac.com>


On Jul 15, 2007, at 12:39 PM, Jakub Bogusz wrote:

> On Sun, Jul 15, 2007 at 11:24:19AM -0400, Jeff Johnson wrote:
>> On Jul 15, 2007, at 7:45 AM, Jakub Bogusz wrote:
>>> On Sun, Jul 15, 2007 at 10:44:59AM +0200, ?ukasz Jerna? wrote:
>>>> Hello.
>>>>
>>>> I just want to drop a note here that current mono-find-requires
>>>> doesn't find
>>>> libraries p-invoked from mono assemblies. They can be partially
>>>> get from
>>>> monodis --moduleref <assembly> but some sort of mechanism for
>>>> pulling the
>>>> complete soname would be needed, because just the name of the lib
>>>> is included
>>>> in the output from the previous command. Any hints?
>>>
>>> We can read ${dllname}.config and determine dll->soname aliases.
>>> But there is a problem with translating sonames to rpm Requires -  
>>> they
>>> are arch-dependent (because of "()(64-bit)" suffix on most 64-bit
>>> systems with 64-bit mono).
>>>
>>
>> If you send me a test case, I'll get you a patch to rpm.
>
> Well, it's not (directly) rpm problem.

It is an rpm problem: find-provides and find-requires for ELF  
dependencies
are being phased out. There is rpm functionality with attaching
dependencies to files, classifying files using libmagic, determining
sonames at install, not build, time, and whether rpmbuild invokes  
external
helpers per-file or per-package  that are intimately tied to how mono  
soname
dependencies are implemented (if at all).

> And mono dependency generators are part of mono, not rpm.
>

Well, I'll remove the mono scripts (added 2 days ago) from rpm  
sources. ;-)

> Actually:
> 1. We can safely generate (arch-dependent) soname dependencies for
> arch-dependent dotnet* packages (those with glue ELF libraries, like
> gtk-sharp, or gnome-sharp, which started this discussion).
> mono-find-requires script can detect mono version basing on monodis
> (or libmono.so) ELF type.
>
> 2. if we decide to generate soname dependencies for some noarch
> dotnet* package, it won't by noarch any longer.
>

If there are soname dependencies, the package is not "noarch", is it?

73 de Jeff

From qboosh at pld-linux.org  Sun Jul 15 18:59:38 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 15 Jul 2007 18:59:38 +0200
Subject: rpm and mono
In-Reply-To: <32A03AE5-95B6-44A3-A518-36939CBDE6E6@mac.com>
References: <200707151045.01413.deejay1@srem.org>
	<20070715114531.GA6001@stranger.qboosh.pl>
	<3853AB8B-EA46-451F-9006-25EA04C87B5B@mac.com>
	<20070715163927.GB11442@stranger.qboosh.pl>
	<32A03AE5-95B6-44A3-A518-36939CBDE6E6@mac.com>
Message-ID: <20070715165938.GC11442@stranger.qboosh.pl>

On Sun, Jul 15, 2007 at 12:53:17PM -0400, Jeff Johnson wrote:
> On Jul 15, 2007, at 12:39 PM, Jakub Bogusz wrote:
> > On Sun, Jul 15, 2007 at 11:24:19AM -0400, Jeff Johnson wrote:
> >> On Jul 15, 2007, at 7:45 AM, Jakub Bogusz wrote:
> >>> On Sun, Jul 15, 2007 at 10:44:59AM +0200, ?ukasz Jerna? wrote:
> >>>> Hello.
> >>>>
> >>>> I just want to drop a note here that current mono-find-requires
> >>>> doesn't find
> >>>> libraries p-invoked from mono assemblies. They can be partially
> >>>> get from
> >>>> monodis --moduleref <assembly> but some sort of mechanism for
> >>>> pulling the
> >>>> complete soname would be needed, because just the name of the lib
> >>>> is included
> >>>> in the output from the previous command. Any hints?
> >>>
> >>> We can read ${dllname}.config and determine dll->soname aliases.
> >>> But there is a problem with translating sonames to rpm Requires -  
> >>> they
> >>> are arch-dependent (because of "()(64-bit)" suffix on most 64-bit
> >>> systems with 64-bit mono).
> >>>
> >>
> >> If you send me a test case, I'll get you a patch to rpm.
> >
> > Well, it's not (directly) rpm problem.
> 
> It is an rpm problem: find-provides and find-requires for ELF  
> dependencies
> are being phased out. There is rpm functionality with attaching
> dependencies to files, classifying files using libmagic, determining
> sonames at install, not build, time, and whether rpmbuild invokes  
> external
> helpers per-file or per-package  that are intimately tied to how mono  
> soname
> dependencies are implemented (if at all).
> 
> > And mono dependency generators are part of mono, not rpm.
> >
> 
> Well, I'll remove the mono scripts (added 2 days ago) from rpm  
> sources. ;-)

Oops, I didn't know that :)

> > Actually:
> > 1. We can safely generate (arch-dependent) soname dependencies for
> > arch-dependent dotnet* packages (those with glue ELF libraries, like
> > gtk-sharp, or gnome-sharp, which started this discussion).
> > mono-find-requires script can detect mono version basing on monodis
> > (or libmono.so) ELF type.
> >
> > 2. if we decide to generate soname dependencies for some noarch
> > dotnet* package, it won't by noarch any longer.
> >
> 
> If there are soname dependencies, the package is not "noarch", is it?

In case of mono/dotnet assemblies (*.dll) without native glue code
library sonames are specified in text/xml file (*.dll.config), and
libraries themselves are dlopened by mono - so assembly packages don't
contain anything arch-dependent.


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


From n3npq at mac.com  Sun Jul 15 19:08:51 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 15 Jul 2007 13:08:51 -0400
Subject: rpm and mono
In-Reply-To: <20070715165938.GC11442@stranger.qboosh.pl>
References: <200707151045.01413.deejay1@srem.org>
	<20070715114531.GA6001@stranger.qboosh.pl>
	<3853AB8B-EA46-451F-9006-25EA04C87B5B@mac.com>
	<20070715163927.GB11442@stranger.qboosh.pl>
	<32A03AE5-95B6-44A3-A518-36939CBDE6E6@mac.com>
	<20070715165938.GC11442@stranger.qboosh.pl>
Message-ID: <7B3E294E-783B-4893-AB60-FE69721F05FD@mac.com>


On Jul 15, 2007, at 12:59 PM, Jakub Bogusz wrote:

>>
>> Well, I'll remove the mono scripts (added 2 days ago) from rpm
>> sources. ;-)
>
> Oops, I didn't know that :)
>

;-) Actually external per-interpreter rpm helpers is preferred, PLD just
got there first, as always ;-)

>>> Actually:
>>> 1. We can safely generate (arch-dependent) soname dependencies for
>>> arch-dependent dotnet* packages (those with glue ELF libraries, like
>>> gtk-sharp, or gnome-sharp, which started this discussion).
>>> mono-find-requires script can detect mono version basing on monodis
>>> (or libmono.so) ELF type.
>>>
>>> 2. if we decide to generate soname dependencies for some noarch
>>> dotnet* package, it won't by noarch any longer.
>>>
>>
>> If there are soname dependencies, the package is not "noarch", is it?
>
> In case of mono/dotnet assemblies (*.dll) without native glue code
> library sonames are specified in text/xml file (*.dll.config), and
> libraries themselves are dlopened by mono - so assembly packages don't
> contain anything arch-dependent.

Oops, I dinna know that. Lots I don't know about mono, I've never  
knowingly
needed or used.

Ah, so two-level linkage through some dlopen() mechanism to maintain
a "noarch" fiction.

The offer to send a patch if you send me a test case remains. It sounds
like the dependencies can be handled externally to rpm, the "soname"
is what I reacted to.

Note that the mono-helpers are invoked per-file, necessary iff the  
traditional
model is continued:
      cat monofileslist | mono-helper > monodepslist

73 de Jeff


From radek at pld-linux.org  Sun Jul 15 19:11:31 2007
From: radek at pld-linux.org (Radoslaw Zielinski)
Date: Sun, 15 Jul 2007 19:11:31 +0200
Subject: rpm and mono
In-Reply-To: <32A03AE5-95B6-44A3-A518-36939CBDE6E6@mac.com>
References: <200707151045.01413.deejay1@srem.org>
	<20070715114531.GA6001@stranger.qboosh.pl>
	<3853AB8B-EA46-451F-9006-25EA04C87B5B@mac.com>
	<20070715163927.GB11442@stranger.qboosh.pl>
	<32A03AE5-95B6-44A3-A518-36939CBDE6E6@mac.com>
Message-ID: <20070715171130.GA4772@bzium>

Jeff Johnson <n3npq at mac.com> [15-07-2007 18:53]: [...] [...]
[...]
> and whether rpmbuild invokes external helpers per-file or per-package
> that are intimately tied to
[...]

Would be nice if RPM could invoke perl.prov / perl.req per-package,
instead of per-file, as it currently does.

-- 
Rados?aw Zieli?ski <radek at pld-linux.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </mailman/pipermail/pld-devel-en/attachments/20070715/592a278d/attachment.sig>

From n3npq at mac.com  Sun Jul 15 19:18:03 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 15 Jul 2007 13:18:03 -0400
Subject: rpm and mono
In-Reply-To: <20070715171130.GA4772@bzium>
References: <200707151045.01413.deejay1@srem.org>
	<20070715114531.GA6001@stranger.qboosh.pl>
	<3853AB8B-EA46-451F-9006-25EA04C87B5B@mac.com>
	<20070715163927.GB11442@stranger.qboosh.pl>
	<32A03AE5-95B6-44A3-A518-36939CBDE6E6@mac.com>
	<20070715171130.GA4772@bzium>
Message-ID: <B8B19F6D-524C-4D29-BEC5-5AC5EBD0E097@mac.com>


On Jul 15, 2007, at 1:11 PM, Radoslaw Zielinski wrote:

> Jeff Johnson <n3npq at mac.com> [15-07-2007 18:53]: [...] [...]
> [...]
>> and whether rpmbuild invokes external helpers per-file or per-package
>> that are intimately tied to
> [...]
>
> Would be nice if RPM could invoke perl.prov / perl.req per-package,
> instead of per-file, as it currently does.
>

Can't be done without a massively complicated scripting effort changing
all external dependency helpers used by rpmbuild. Well, it *could* be
handled by massively rewriting rpmfc.c, but there as yet no reason
to undertake the added complexity.

See the functionality at
     rpm -qp --filerequire foo*.rpm

The constraints on the storage in Headers are quite annoying because
rpm does not vave a variable length array data type. Dependencies
and file lists are also sorted within headers.

I thought about doing throug scripts, but decided on "reliable" C  
instead. ;-)

73 de Jeff
> -- 
> Rados?aw Zieli?ski <radek at pld-linux.org>
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



From qboosh at pld-linux.org  Sun Jul 15 20:58:09 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Sun, 15 Jul 2007 20:58:09 +0200
Subject: rpm and mono
In-Reply-To: <7B3E294E-783B-4893-AB60-FE69721F05FD@mac.com>
References: <200707151045.01413.deejay1@srem.org>
	<20070715114531.GA6001@stranger.qboosh.pl>
	<3853AB8B-EA46-451F-9006-25EA04C87B5B@mac.com>
	<20070715163927.GB11442@stranger.qboosh.pl>
	<32A03AE5-95B6-44A3-A518-36939CBDE6E6@mac.com>
	<20070715165938.GC11442@stranger.qboosh.pl>
	<7B3E294E-783B-4893-AB60-FE69721F05FD@mac.com>
Message-ID: <20070715185809.GA1864@stranger.qboosh.pl>

On Sun, Jul 15, 2007 at 01:08:51PM -0400, Jeff Johnson wrote:
[...]
> >>> Actually:
> >>> 1. We can safely generate (arch-dependent) soname dependencies for
> >>> arch-dependent dotnet* packages (those with glue ELF libraries, like
> >>> gtk-sharp, or gnome-sharp, which started this discussion).
> >>> mono-find-requires script can detect mono version basing on monodis
> >>> (or libmono.so) ELF type.
> >>>
> >>> 2. if we decide to generate soname dependencies for some noarch
> >>> dotnet* package, it won't by noarch any longer.
> >>>
> >>
> >> If there are soname dependencies, the package is not "noarch", is it?
> >
> > In case of mono/dotnet assemblies (*.dll) without native glue code
> > library sonames are specified in text/xml file (*.dll.config), and
> > libraries themselves are dlopened by mono - so assembly packages don't
> > contain anything arch-dependent.

Or even sonames can be hardcoded directly in *.dll, still dlopened by
mono.

Here is some ugly update to mono-find-requires script (from mono
package), which tries to generate soname deps.
But:
1. not all entries from `monodis --moduleref` are always required, see:

$ monodis --moduleref /usr/lib/mono/gac/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
ModuleRef Table (1..21)
1: librsvg-2.so.2
2: libgdk_pixbuf-2.0.so.0
3: libglib-2.0.so.0
4: libgdk-x11-2.0.so.0
5: libgobject-2.0.so.0
6: libgnomeui-2.so.0
7: libgtk-x11-2.0.so.0
8: user32
9: gdi32
10: libgdk-x11-2.0.so
11: libgtk-x11-2.0.so
12: ole32.dll
13: shell32.dll
14: libX11
15: /System/Library/Frameworks/Carbon.framework/Versions/Current/Carbon
16: kernel32.dll
17: user32.dll
18: gdi32.dll
19: winmm.dll
20: uxtheme
21: X11

I suppose libgnomeui is only optional, Carbon.framework used on OSX only
etc.

2. sometimes .dll refers to soname directly, sometimes without ".so"
suffix... (when module doesn't refer to dll entry in config file)

3. not all dll .config entries end with ".dll", so this is messy;
and I don't know what "i:" prefix means.

Global file (/etc/mono/config) looks like this:
<configuration>
        <dllmap dll="i:cygwin1.dll" target="libc.so.6" os="!windows" />
        <dllmap dll="libc" target="libc.so.6" os="!windows"/>
        <dllmap dll="intl" target="libc.so.6" os="!windows"/>
        <dllmap dll="libintl" target="libc.so.6" os="!windows"/>
        <dllmap dll="i:libxslt.dll" target="libxslt.so.1" os="!windows"/>
        <dllmap dll="i:odbc32.dll" target="libodbc.so.1" os="!windows"/>
        <dllmap dll="i:odbc32.dll" target="libiodbc.dylib" os="osx"/>
        <dllmap dll="oci" target="libclntsh.so" os="!windows"/>
        <dllmap dll="db2cli" target="libdb2_36.so" os="!windows"/>
        <dllmap dll="MonoPosixHelper" target="libMonoPosixHelper.so" os="!windows" />
        <dllmap dll="i:msvcrt" target="libc.so.6" os="!windows"/>
        <dllmap dll="i:msvcrt.dll" target="libc.so.6" os="!windows"/>
        <dllmap dll="sqlite" target="libsqlite.so.0" os="!windows"/>
        <dllmap dll="sqlite3" target="libsqlite3.so.0" os="!windows"/>
        <dllmap dll="libX11" target="libX11.so.6" os="!windows" />
        <dllmap dll="libcairo-2.dll" target="libcairo.so.2" os="!windows"/>
</configuration>

And per-dll config files:
$ cat /usr/lib/mono/gac/gtk-sharp/2.10.0.0__35e10195dab3c99f/gtk-sharp.dll.config
<configuration>
  <dllmap dll="libglib-2.0-0.dll" target="libglib-2.0.so.0"/>
  <dllmap dll="libgobject-2.0-0.dll" target="libgobject-2.0.so.0"/>
  <dllmap dll="libatk-1.0-0.dll" target="libatk-1.0.so.0"/>
  <dllmap dll="libgtk-win32-2.0-0.dll" target="libgtk-x11-2.0.so.0"/>
</configuration>


-- 
Jakub Bogusz    http://qboosh.pl/
-------------- next part --------------
--- /usr/lib/rpm/mono-find-requires	2007-05-16 19:17:33.000000000 +0200
+++ /home/qboosh/mono-find-requires	2007-07-15 20:46:36.387271119 +0200
@@ -57,6 +57,35 @@
 	done
 )
 
+if file $bindir/monodis 2>/dev/null | grep 64-bit ; then 
+	ELFTYPE="()(64bit)"
+else
+	ELFTYPE=
+fi
+SOREQUIRES=$(
+	for i in "${monolist[@]}"; do
+		DLLCONF=
+		if [ -f ${i}.config ]; then
+			DLLCONF="${i}.config"
+		fi
+		for r in `($bindir/monodis --moduleref $i | awk '
+			/^[0-9]+: / { print $2 }' ) 2>/dev/null` ; do
+			if echo "$r" | grep 'lib.*\.so\.' ; then
+				echo "$r"
+			else
+				r=$(echo "$r" | sed -e 's,[./],\\&,g')
+				awk "
+					/<dllmap .* os=\"(windows|osx)\"/ { next }
+					/<dllmap dll=\"(i:)?$r\"/ {
+						sub(/.*target=\"/,\"\")
+						sub(/\".*/,\"\")
+						print \$0 \"$ELFTYPE\"
+					}" /etc/mono/config $DLLCONF
+			fi
+		done
+	done
+)
+
 PROVIDES=$(
 	for i in "${monolist[@]}"; do
 		($bindir/monodis --assembly $i | awk '
@@ -91,3 +120,7 @@
 #
 echo "$UNIQ
 $REQUIRES" | sort | uniq -d
+# and add SONAME requires
+if [ -n "$SOREQUIRES" ]; then
+	echo "$SOREQUIRES" | sort -u
+fi

From n3npq at mac.com  Sun Jul 15 21:05:38 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 15 Jul 2007 15:05:38 -0400
Subject: rpm and mono
In-Reply-To: <20070715185809.GA1864@stranger.qboosh.pl>
References: <200707151045.01413.deejay1@srem.org>
	<20070715114531.GA6001@stranger.qboosh.pl>
	<3853AB8B-EA46-451F-9006-25EA04C87B5B@mac.com>
	<20070715163927.GB11442@stranger.qboosh.pl>
	<32A03AE5-95B6-44A3-A518-36939CBDE6E6@mac.com>
	<20070715165938.GC11442@stranger.qboosh.pl>
	<7B3E294E-783B-4893-AB60-FE69721F05FD@mac.com>
	<20070715185809.GA1864@stranger.qboosh.pl>
Message-ID: <16731B2E-FAA0-4EA8-A7D3-006F365282BF@mac.com>


On Jul 15, 2007, at 2:58 PM, Jakub Bogusz wrote:

>
> Here is some ugly update to mono-find-requires script (from mono
> package), which tries to generate soname deps.

Poke a final mono patch onto <rpm-devel at rpm5.org> (or send to  
arekm ;-) please.

73 de Jeff


From arekm at maven.pl  Mon Jul 16 14:45:14 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Mon, 16 Jul 2007 14:45:14 +0200
Subject: libstdc++ concept checks
Message-ID: <200707161445.14514.arekm@maven.pl>


Is it possible to make these warnings not fatal errors? I'm inclined to 
disable concept checks in gcc for now (due to lack of developers fixing the 
problems found by concept checks).

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


From glen at delfi.ee  Mon Jul 16 20:03:07 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Mon, 16 Jul 2007 21:03:07 +0300
Subject: Fwd: [talk] PHP 4 end of life announcement
Message-ID: <200707162103.08284.glen@delfi.ee>

 Today it is exactly three years ago since PHP 5 has been released. In
those three years it has seen many improvements over PHP 4. PHP 5 is
fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will
be discontinued.

The PHP development team hereby announces that support for PHP 4 will
continue until the end of this year only. After 2007-12-31 there will
be no more releases of PHP 4.4. We will continue to make critical
security fixes available on a case-by-case basis until 2008-08-08.
Please use the rest of this year to make your application suitable to
run on PHP 5.

http://www.php.net/

-- 
glen


From blues at pld-linux.org  Tue Jul 17 16:29:26 2007
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Tue, 17 Jul 2007 16:29:26 +0200 (CEST)
Subject: [BUG] exclude confuses /usr/lib/rpm/check-files
Message-ID: <Pine.LNX.4.64N.0707171626580.7414@fgnss.gnfx.tqn.cy>

Hello,

It seems that /usr/lib/rpm/check-files is confused when in spec is used 
"%exclude". Files excluded aren't shown as unpackaged.

-- 
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 pluto at agmk.net  Wed Jul 18 00:25:51 2007
From: pluto at agmk.net (=?iso-8859-2?q?Pawe=B3_Sikora?=)
Date: Wed, 18 Jul 2007 00:25:51 +0200
Subject: libstdc++ concept checks
In-Reply-To: <200707161445.14514.arekm@maven.pl>
References: <200707161445.14514.arekm@maven.pl>
Message-ID: <200707180025.51756.pluto@agmk.net>

On Monday 16 of July 2007 14:45:14 Arkadiusz Miskiewicz wrote:
> Is it possible to make these warnings not fatal errors?

nope. the whole idea of concept checks is to bailing out compilation
asap instead of producing tons of long non-intuitive stl warnings
or non-deterministic flow control.

> I'm inclined to disable concept checks in gcc for now (due to lack
> of developers fixing the problems found by concept checks).

you're rm, you must choice between build failures and random flow control :>

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


From arekm at maven.pl  Wed Jul 18 07:48:17 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Wed, 18 Jul 2007 07:48:17 +0200
Subject: libstdc++ concept checks
In-Reply-To: <200707180025.51756.pluto@agmk.net>
References: <200707161445.14514.arekm@maven.pl>
	<200707180025.51756.pluto@agmk.net>
Message-ID: <200707180748.18078.arekm@maven.pl>

On Wednesday 18 of July 2007, Pawe? Sikora wrote:
> On Monday 16 of July 2007 14:45:14 Arkadiusz Miskiewicz wrote:
> > Is it possible to make these warnings not fatal errors?
>
> nope. the whole idea of concept checks is to bailing out compilation
> asap instead of producing tons of long non-intuitive stl warnings
> or non-deterministic flow control.

Bad. I was hoping that there is a way to make these become warnings. Now I 
disabled the whole thing :/

>
> > I'm inclined to disable concept checks in gcc for now (due to lack
> > of developers fixing the problems found by concept checks).
>
> you're rm, you must choice between build failures and random flow control
> :>

The lack of manpower makes a rule itself. Concept checks are disabled in gcc 
rel 9.

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


From hawk at limanowa.net  Thu Jul 19 09:50:33 2007
From: hawk at limanowa.net (=?ISO-8859-2?Q?Marcin_Kr=F3l?=)
Date: Thu, 19 Jul 2007 09:50:33 +0200
Subject: rpm bug?
Message-ID: <469F17C9.2040903@limanowa.net>

Hello.

I'm not good in uderstanding how rpm internally works so don't blam me if I'm
writing obvious things :)

I think I've found bug in .spec processing. I'll show that on example. Our
builder script is using following command to get package name and version for
auto- CVS tag:

rpmbuild --macros
/usr/lib/rpm/macros:/usr/lib/rpm/i686-linux/macros:/etc/rpm/macros.*:/etc/rpm/macros:/etc/rpm/i686-linux/macros:~/etc/.rpmmacros:~/.rpmmacros:/home/users/krol/.builder-rpmmacros
--nodigest --nosignature --nobuild --define 'prep %{echo:dummy: PACKAGE_NAME
%{name} }%dump' --nodeps mozilla-firefox.spec

Main package in mozilla-firefox.spec has version 2.0.0.5 however above command
returns PACKAGE_VERSION = 0.8.4.0 which is version of mozilla-firefox-tidy
subpackage. Since it is last subpackage defined in spec it seems like rpm just
take last "Version: something" as package version instead of using version of
main package.

Maybe this is feature required for something else to work, I don't know. For me
its a bug which should be nailed :)

M.


From glen at delfi.ee  Thu Jul 19 10:34:54 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 19 Jul 2007 11:34:54 +0300
Subject: rpm bug?
In-Reply-To: <469F17C9.2040903@limanowa.net>
References: <469F17C9.2040903@limanowa.net>
Message-ID: <200707191134.54819.glen@delfi.ee>

On Thursday 19 July 2007 10:50, Marcin Kr?l wrote:
> Maybe this is feature required for something else to work, I don't know.
> For me its a bug which should be nailed :)

not sure how to put this in proper words, but querying binheader results this, 
one should query srcheaders.

see how this script works:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/test/specinfo.pl

glen at builder-ac pld/test $ ./specinfo.pl ~/rpm/pld/SPECS/mozilla-firefox.spec
PACKAGE_NAME mozilla-firefox
PACKAGE_VERSION 2.0.0.4
PACKAGE_RELEASE 1.1
mozilla-firefox-2.0.0.4-1.1
/home/glen/rpm/pld/SRPMS/mozilla-firefox-2.0.0.4-1.1.src.rpm
/home/glen/rpm/pld/RPMS/mozilla-firefox-2.0.0.4-1.1.i686.rpm
/home/glen/rpm/pld/RPMS/mozilla-firefox-libs-2.0.0.4-1.1.i686.rpm
/home/glen/rpm/pld/RPMS/mozilla-firefox-lang-en-2.0.0.4-1.1.i686.rpm
/home/glen/rpm/pld/RPMS/mozilla-firefox-addon-tidy-0.8.3.9-1.1.i686.rpm

just using %dump you'll get last binpkg.


-- 
glen


From hawk at limanowa.net  Thu Jul 19 10:44:14 2007
From: hawk at limanowa.net (=?ISO-8859-1?Q?Marcin_Kr=F3l?=)
Date: Thu, 19 Jul 2007 10:44:14 +0200
Subject: rpm bug?
In-Reply-To: <200707191134.54819.glen@delfi.ee>
References: <469F17C9.2040903@limanowa.net> <200707191134.54819.glen@delfi.ee>
Message-ID: <469F245E.40700@limanowa.net>

> not sure how to put this in proper words, but querying binheader results this, 
> one should query srcheaders.

Anyone brave enough to make requried changes into builder script? :)

M.


From glen at delfi.ee  Thu Jul 19 16:04:20 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Thu, 19 Jul 2007 17:04:20 +0300
Subject: rpm bug?
In-Reply-To: <469F245E.40700@limanowa.net>
References: <469F17C9.2040903@limanowa.net> <200707191134.54819.glen@delfi.ee>
	<469F245E.40700@limanowa.net>
Message-ID: <200707191704.20300.glen@delfi.ee>

On Thursday 19 July 2007 11:44:14 Marcin Kr?l wrote:
> > not sure how to put this in proper words, but querying binheader results
> > this, one should query srcheaders.
>
> Anyone brave enough to make requried changes into builder script? :)
well. somebody mentioned that builder script should not depend on any higher 
language liker perl.... so...

-- 
glen


From mmazur at kernel.pl  Thu Jul 19 16:21:43 2007
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Thu, 19 Jul 2007 16:21:43 +0200
Subject: http://hardware4linux.info/
Message-ID: <200707191621.43972.mmazur@kernel.pl>

We don't have anything for storing and browsing through hardware profiles and 
the website in the subject looks all webish2.0 and colorfull and has round 
edges. If someone could get through the software, package it and maybe send 
it to both ac and th, that'd be neat (/me -enotime). Oh, you can mail the 
author afterwards -- he's responsive, from mandriva and actually knows what 
pld is and took the effort of bugging us on irc about his solution. If it 
takes off, both users and developers could probably benefit from it (e.g. I'd 
know beforehand what laptops are supported by pld out of the box or 
something).

-- 
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 dhubleizh at o2.pl  Thu Jul 19 17:10:55 2007
From: dhubleizh at o2.pl (Cezary Krzyzanowski)
Date: Thu, 19 Jul 2007 17:10:55 +0200
Subject: http://hardware4linux.info/
In-Reply-To: <200707191621.43972.mmazur@kernel.pl>
References: <200707191621.43972.mmazur@kernel.pl>
Message-ID: <1184857855.9547.0.camel@ipv6-localnet>

Dnia 19-07-2007, Cz o godzinie 16:21 +0200, Mariusz Mazur napisa?(a):
> We don't have anything for storing and browsing through hardware profiles and 
> the website in the subject looks all webish2.0 and colorfull and has round 
> edges. If someone could get through the software, package it and maybe send 
> it to both ac and th, that'd be neat (/me -enotime). Oh, you can mail the 
> author afterwards -- he's responsive, from mandriva and actually knows what 
> pld is and took the effort of bugging us on irc about his solution. If it 
> takes off, both users and developers could probably benefit from it (e.g. I'd 
> know beforehand what laptops are supported by pld out of the box or 
> something).
> 

http://cvs.pld-linux.org/cgi-bin/cvsweb/SPECS/hwreport.spec

Cz at rny



From mike at osdn.org.ua  Thu Jul 19 18:41:05 2007
From: mike at osdn.org.ua (Michael Shigorin)
Date: Thu, 19 Jul 2007 19:41:05 +0300
Subject: http://hardware4linux.info/
In-Reply-To: <1184857855.9547.0.camel@ipv6-localnet>
References: <200707191621.43972.mmazur@kernel.pl>
	<1184857855.9547.0.camel@ipv6-localnet>
Message-ID: <20070719164105.GL19752@osdn.org.ua>

On Thu, Jul 19, 2007 at 05:10:55PM +0200, Cezary Krzyzanowski wrote:
> > Oh, you can mail the author afterwards -- he's responsive,
> > from mandriva and actually knows what pld is and took the
> > effort of bugging us on irc about his solution.

Hm, someone from Fedora told it's dead:
http://lwn.net/Comments/242055/

> http://cvs.pld-linux.org/cgi-bin/cvsweb/SPECS/hwreport.spec

-- 
 ---- WBR, Michael Shigorin <mike at altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/


From tomasz.wittner at gmail.com  Fri Jul 20 11:24:49 2007
From: tomasz.wittner at gmail.com (Tomasz Wittner)
Date: Fri, 20 Jul 2007 11:24:49 +0200
Subject: rpm bug?
In-Reply-To: <200707191704.20300.glen@delfi.ee>
References: <469F17C9.2040903@limanowa.net> <469F245E.40700@limanowa.net>
	<200707191704.20300.glen@delfi.ee>
Message-ID: <200707201124.49508.tomasz.wittner@gmail.com>

On Thu 19. of July 2007, 16:04, Elan Ruusam?e wrote:
> On Thursday 19 July 2007 11:44:14 Marcin Kr?l wrote:
> > > not sure how to put this in proper words, but querying binheader
> > > results this, one should query srcheaders.
> >
> > Anyone brave enough to make requried changes into builder script? :)
>
> well. somebody mentioned that builder script should not depend on any
> higher language liker perl.... so...
But why? Better have broken tool than use suitable language?

-- 
Tomasz Wittner


From adamg at biomerieux.pl  Sun Jul 22 14:02:54 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Sun, 22 Jul 2007 14:02:54 +0200
Subject: [BUG] exclude confuses /usr/lib/rpm/check-files
In-Reply-To: <Pine.LNX.4.64N.0707171626580.7414@fgnss.gnfx.tqn.cy>
References: <Pine.LNX.4.64N.0707171626580.7414@fgnss.gnfx.tqn.cy>
Message-ID: <20070722120254.GC6211@mysza.eu.org>

On Tue, Jul 17, 2007 at 04:29:26PM +0200, Pawel Golaszewski wrote:
> Hello,
> 
> It seems that /usr/lib/rpm/check-files is confused when in spec is used 
> "%exclude". Files excluded aren't shown as unpackaged.

Should they? I allways thought of unpackaged files as of those which you
may have missed - %exclude means you know the file exists but just don't
want to package it.

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


From blues at pld-linux.org  Sun Jul 22 19:31:34 2007
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Sun, 22 Jul 2007 19:31:34 +0200 (CEST)
Subject: [BUG] exclude confuses /usr/lib/rpm/check-files
In-Reply-To: <20070722120254.GC6211@mysza.eu.org>
References: <Pine.LNX.4.64N.0707171626580.7414@fgnss.gnfx.tqn.cy>
	<20070722120254.GC6211@mysza.eu.org>
Message-ID: <Pine.LNX.4.64N.0707221925050.24877@fgnss.gnfx.tqn.cy>

On Sun, 22 Jul 2007, Adam Go??biowski wrote:
> > It seems that /usr/lib/rpm/check-files is confused when in spec is 
> > used "%exclude". Files excluded aren't shown as unpackaged.
> Should they? I allways thought of unpackaged files as of those which you 
> may have missed - %exclude means you know the file exists but just don't 
> want to package it.

You don't want it in _that_ package where %exclude is specified.  It 
doesn't mean that you don't want to package it at all.

Maybe there should be another tag "%ignore" when you don't want something 
at all? Now we are deleting files while installing... but I don't think 
it's good solution. Not clean, for sure.

Jeff?

-- 
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 n3npq at mac.com  Sun Jul 22 20:09:54 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Sun, 22 Jul 2007 14:09:54 -0400
Subject: [BUG] exclude confuses /usr/lib/rpm/check-files
In-Reply-To: <Pine.LNX.4.64N.0707221925050.24877@fgnss.gnfx.tqn.cy>
References: <Pine.LNX.4.64N.0707171626580.7414@fgnss.gnfx.tqn.cy>
	<20070722120254.GC6211@mysza.eu.org>
	<Pine.LNX.4.64N.0707221925050.24877@fgnss.gnfx.tqn.cy>
Message-ID: <DCFBC77C-A68B-46CA-820E-EEF217FE6569@mac.com>


On Jul 22, 2007, at 1:31 PM, Pawel Golaszewski wrote:

> On Sun, 22 Jul 2007, Adam Go??biowski wrote:
>>> It seems that /usr/lib/rpm/check-files is confused when in spec is
>>> used "%exclude". Files excluded aren't shown as unpackaged.
>> Should they? I allways thought of unpackaged files as of those  
>> which you
>> may have missed - %exclude means you know the file exists but just  
>> don't
>> want to package it.
>
> You don't want it in _that_ package where %exclude is specified.  It
> doesn't mean that you don't want to package it at all.
>
> Maybe there should be another tag "%ignore" when you don't want  
> something
> at all? Now we are deleting files while installing... but I don't  
> think
> it's good solution. Not clean, for sure.
>
> Jeff?
>

I'm not sure I see the usage case for explicit %ignore. One
can certainly enumerate files/directories explicitly in %files,
and just delete undesired elements.

And if ease of packaging is the issue, then pattern rule
based content, like, say,
    *.h
    *.a
    *.la
    *.so
from %{buildroot}, to send files that match pattern always into *-devel
subpackage.

Replacing external check-files script using a %{buildroot}
Fts(3) walk internal to rpm is achievable. The functionality of
detecting files that have been overlooked in %files manifests is
too important to leave to a script, and an Fts(3) implementation
is likely the same order of magnitude of effort as arranging
for %{_tmppath} (or %{_tmpdir} ;-) lists to be used by a script,
with results sucked and parsed from stdout for display purposes.

Likely not the answers you wanted to hear ;-)

But %ignore can be added to rpmbuild if you wish.

73 de Jeff

From blues at pld-linux.org  Sun Jul 22 21:26:40 2007
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Sun, 22 Jul 2007 21:26:40 +0200 (CEST)
Subject: [BUG] exclude confuses /usr/lib/rpm/check-files
In-Reply-To: <DCFBC77C-A68B-46CA-820E-EEF217FE6569@mac.com>
References: <Pine.LNX.4.64N.0707171626580.7414@fgnss.gnfx.tqn.cy>
	<20070722120254.GC6211@mysza.eu.org>
	<Pine.LNX.4.64N.0707221925050.24877@fgnss.gnfx.tqn.cy>
	<DCFBC77C-A68B-46CA-820E-EEF217FE6569@mac.com>
Message-ID: <Pine.LNX.4.64N.0707222047190.24877@fgnss.gnfx.tqn.cy>

On Sun, 22 Jul 2007, Jeff Johnson wrote:
> >>> It seems that /usr/lib/rpm/check-files is confused when in spec is 
> >>> used "%exclude". Files excluded aren't shown as unpackaged.
> >> Should they? I allways thought of unpackaged files as of those which 
> >> you may have missed - %exclude means you know the file exists but 
> >> just don't want to package it.
> > You don't want it in _that_ package where %exclude is specified.  It 
> > doesn't mean that you don't want to package it at all. Maybe there 
> > should be another tag "%ignore" when you don't want something at all? 
> > Now we are deleting files while installing... but I don't think it's 
> > good solution. Not clean, for sure. Jeff?
> I'm not sure I see the usage case for explicit %ignore. One can 
> certainly enumerate files/directories explicitly in %files, and just 
> delete undesired elements.

We are doing that right now.
But it makes things like "--short-circuit" difficult to use. And is not 
nice.

> And if ease of packaging is the issue, then pattern rule based content, 
> like, say,
>     *.h
>     *.a
>     *.la
>     *.so
> from %{buildroot}, to send files that match pattern always into *-devel
> subpackage.
> 
> Replacing external check-files script using a %{buildroot} Fts(3) walk 
> internal to rpm is achievable. The functionality of detecting files that 
> have been overlooked in %files manifests is too important to leave to a 
> script, and an Fts(3) implementation is likely the same order of 
> magnitude of effort as arranging for %{_tmppath} (or %{_tmpdir} ;-) 
> lists to be used by a script, with results sucked and parsed from stdout 
> for display purposes. Likely not the answers you wanted to hear ;-)

The answer like many others. ;)
That one is good too ;)

> But %ignore can be added to rpmbuild if you wish.

Can be very useful.

-- 
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 arekm at maven.pl  Mon Jul 23 11:08:09 2007
From: arekm at maven.pl (Arkadiusz Miskiewicz)
Date: Mon, 23 Jul 2007 11:08:09 +0200
Subject: ANN: carme downtime at 25/07/2007
Message-ID: <200707231108.09902.arekm@maven.pl>

Hello

Somewhere between 9:00-18:00 25/07/2007 carme will be down for maitenance.

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


From qboosh at pld-linux.org  Tue Jul 24 19:46:57 2007
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 24 Jul 2007 19:46:57 +0200
Subject: rpm bug?
In-Reply-To: <200707201124.49508.tomasz.wittner@gmail.com>
References: <469F17C9.2040903@limanowa.net> <469F245E.40700@limanowa.net>
	<200707191704.20300.glen@delfi.ee>
	<200707201124.49508.tomasz.wittner@gmail.com>
Message-ID: <20070724174657.GA12666@stranger.qboosh.pl>

On Fri, Jul 20, 2007 at 11:24:49AM +0200, Tomasz Wittner wrote:
> On Thu 19. of July 2007, 16:04, Elan Ruusam?e wrote:
> > On Thursday 19 July 2007 11:44:14 Marcin Kr?l wrote:
> > > > not sure how to put this in proper words, but querying binheader
> > > > results this, one should query srcheaders.
> > >
> > > Anyone brave enough to make requried changes into builder script? :)
> >
> > well. somebody mentioned that builder script should not depend on any
> > higher language liker perl.... so...
> But why? Better have broken tool than use suitable language?

Better broken in some corner cases than unusable for bootstrap...
(anyway, redefining Version in middle of .spec is tricky, as you can see
from %{version} behaviour)


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


From n3npq at mac.com  Tue Jul 24 20:02:36 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Tue, 24 Jul 2007 14:02:36 -0400
Subject: rpm bug?
In-Reply-To: <20070724174657.GA12666@stranger.qboosh.pl>
References: <469F17C9.2040903@limanowa.net> <469F245E.40700@limanowa.net>
	<200707191704.20300.glen@delfi.ee>
	<200707201124.49508.tomasz.wittner@gmail.com>
	<20070724174657.GA12666@stranger.qboosh.pl>
Message-ID: <0C2943D4-FC72-475D-804B-F0DE59333F3D@mac.com>


On Jul 24, 2007, at 1:46 PM, Jakub Bogusz wrote:

> On Fri, Jul 20, 2007 at 11:24:49AM +0200, Tomasz Wittner wrote:
>> On Thu 19. of July 2007, 16:04, Elan Ruusam?e wrote:
>>> On Thursday 19 July 2007 11:44:14 Marcin Kr?l wrote:
>>>>> not sure how to put this in proper words, but querying binheader
>>>>> results this, one should query srcheaders.
>>>>
>>>> Anyone brave enough to make requried changes into builder  
>>>> script? :)
>>>
>>> well. somebody mentioned that builder script should not depend on  
>>> any
>>> higher language liker perl.... so...
>> But why? Better have broken tool than use suitable language?
>
> Better broken in some corner cases than unusable for bootstrap...
> (anyway, redefining Version in middle of .spec is tricky, as you  
> can see
> from %{version} behaviour)
>

Tricky only because noone has asked.

I can certainly permit
     Version: %%{version}
     %define version whatever-you-want
to delay the expansion, and add an additional macro expansion
before adding RPMTAG_VERSION to *.rpm package headers, if that is  
desirable.

A delayed expansion is most definiitely desirable for Release: fields
because of the pesky %{?dist} that has been injected everywhere by
Fedora, and will take years to phase out, sigh.

73 de Jeff



From wrobell at pld-linux.org  Wed Jul 25 12:00:58 2007
From: wrobell at pld-linux.org (wrobell)
Date: Wed, 25 Jul 2007 11:00:58 +0100
Subject: SPECS: vim.spec - with python,
In-Reply-To: <200706181441.l5IEfSJo018697@green.mif.pg.gda.pl>
References: <200706181420.27425.mmazur@kernel.pl>
	<200706181441.l5IEfSJo018697@green.mif.pg.gda.pl>
Message-ID: <20070725100058.GB3605@borg>

On Mon, Jun 18, 2007 at 04:41:28PM +0200, Andrzej Krzysztofowicz wrote:
> Mariusz Mazur wrote:
> > 
> > Dnia poniedzia?ek, 18 czerwca 2007, Andrzej Krzysztofowicz napisa?:
> > > > OO. For all the minimum requirements there's always vim-static and e3.
> > >
> > > -static is in contradiction with minimum.
> > 
> > Yup. We should have full vim with everything (X, python, perl, ruby, 
> > brainfuck, you name it) and a vim-minimal for those, that want to have the 
> > lightest version possible.
> 
> Agreed.

what's the current conclusion? 

regards,

    wrobell <wrobell at pld-linux.org>


From glen at delfi.ee  Wed Jul 25 16:05:45 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 25 Jul 2007 17:05:45 +0300
Subject: rpm bug?
In-Reply-To: <0C2943D4-FC72-475D-804B-F0DE59333F3D@mac.com>
References: <469F17C9.2040903@limanowa.net>
	<20070724174657.GA12666@stranger.qboosh.pl>
	<0C2943D4-FC72-475D-804B-F0DE59333F3D@mac.com>
Message-ID: <200707251705.45818.glen@delfi.ee>

On Tuesday 24 July 2007 21:02:36 Jeff Johnson wrote:
> On Jul 24, 2007, at 1:46 PM, Jakub Bogusz wrote:
> > On Fri, Jul 20, 2007 at 11:24:49AM +0200, Tomasz Wittner wrote:
> >> On Thu 19. of July 2007, 16:04, Elan Ruusam?e wrote:
> >>> On Thursday 19 July 2007 11:44:14 Marcin Kr?l wrote:
> >>>>> not sure how to put this in proper words, but querying binheader
> >>>>> results this, one should query srcheaders.
> >>>>
> >>>> Anyone brave enough to make requried changes into builder
> >>>> script? :)
> >>>
> >>> well. somebody mentioned that builder script should not depend on
> >>> any
> >>> higher language liker perl.... so...
> >>
> >> But why? Better have broken tool than use suitable language?
> >
> > Better broken in some corner cases than unusable for bootstrap...
> > (anyway, redefining Version in middle of .spec is tricky, as you
> > can see
> > from %{version} behaviour)
>
> Tricky only because noone has asked.
>
> I can certainly permit
>      Version: %%{version}
>      %define version whatever-you-want
> to delay the expansion, and add an additional macro expansion
> before adding RPMTAG_VERSION to *.rpm package headers, if that is
> desirable.
>
> A delayed expansion is most definiitely desirable for Release: fields
> because of the pesky %{?dist} that has been injected everywhere by
> Fedora, and will take years to phase out, sigh.
perhaps add possibility to query srcheaders to rpm?

> 73 de Jeff


-- 
glen


From glen at delfi.ee  Wed Jul 25 16:14:26 2007
From: glen at delfi.ee (Elan =?iso-8859-1?q?Ruusam=E4e?=)
Date: Wed, 25 Jul 2007 17:14:26 +0300
Subject: pld-builder.new: client/make-request.sh - -C/--config-file
	command...
In-Reply-To: <pld_builder.new_client_make_request.sh.1.28@pld-linux.org>
References: <pld_builder.new_client_make_request.sh.1.27@pld-linux.org>
	<pld_builder.new_client_make_request.sh.1.28@pld-linux.org>
Message-ID: <200707251714.26956.glen@delfi.ee>

On Tuesday 24 July 2007 20:41:12 adamg wrote:
> Author: adamg                        Date: Tue Jul 24 17:41:12 2007 GMT
> Module: pld-builder.new               Tag: HEAD
> ---- Log message:
> - -C/--config-file command line option
>
> ---- Files affected:
> pld-builder.new/client:
>    make-request.sh (1.27 -> 1.28)
[...]
>    echo "Mandatory arguments to long options are mandatory for short options too."
> +  echo "  -C  --config-file /path/to/config/file"
> +  echo "       Source additional config file (after $USER_CFG), useful when"
> +  echo "       when sending build requests to Ac/Th from the same account"
>    echo "  -b 'BUILDER BUILDER ...'  --builder='BUILDER BUILDER ...'"
>    echo "       Sends request to given builders"
>    echo "  --with VALUE --without VALUE"

btw, i use
./make-request -d th -r pkg
./make-request -d ac -r pkg (default)
and have:

$ cat ~/.requestrc
# vim:syn=sh
priority=3
requester=glen at pld-linux.org
default_key=glen at delfi.ee
mailer="/usr/sbin/sendmail -t"

distro=ac

# defaults:
build_mode=test
f_upgrade=yes

however i use code from WORKING branch.

-- 
glen


From n3npq at mac.com  Wed Jul 25 16:20:59 2007
From: n3npq at mac.com (Jeff Johnson)
Date: Wed, 25 Jul 2007 10:20:59 -0400
Subject: rpm bug?
In-Reply-To: <200707251705.45818.glen@delfi.ee>
References: <469F17C9.2040903@limanowa.net>
	<20070724174657.GA12666@stranger.qboosh.pl>
	<0C2943D4-FC72-475D-804B-F0DE59333F3D@mac.com>
	<200707251705.45818.glen@delfi.ee>
Message-ID: <A6BC60D0-CB6C-4090-AD09-3D471A2D16A7@mac.com>


On Jul 25, 2007, at 10:05 AM, Elan Ruusam?e wrote:

>
> perhaps add possibility to query srcheaders to rpm?
>

Already there
    rpm -qp foo*.src.rpm

What you really want is some means to choose amongst
src and multiple binary headers when querying a specfile.

Immediately after the request for querying only the srpm header
is the request to query only a single subpkg header. The implementation
issue is the same even if the usage case is different.

The hack to choose 1-of-N headers is at (linenum wrto wrto rpm5.org  
cvs HEAD)
build/spec.c:782

     case RPMQV_SPECFILE:
         for (pkg = spec->packages; pkg != NULL; pkg = pkg->next) {
             /* If no target was specified, display all packages.
              * Packages with empty file lists are not produced.
              */
             /* XXX DIEDIEDIE: this logic looks flawed. */
             if (target == NULL || pkg->fileList != NULL)
                 xx = qva->qva_showPackage(qva, ts, pkg->header);
         }
         break;

The srpm header is in spec->sourceHeader.

The real design issue is how to pass the 1of-N to the routine
from the CLI.

hth

73 de Jeff

From adamg at biomerieux.pl  Wed Jul 25 18:21:23 2007
From: adamg at biomerieux.pl (Adam =?iso-8859-2?Q?Go=B3=EAbiowski?=)
Date: Wed, 25 Jul 2007 18:21:23 +0200
Subject: pld-builder.new: client/make-request.sh - -C/--config-file
	command...
In-Reply-To: <200707251714.26956.glen@delfi.ee>
References: <pld_builder.new_client_make_request.sh.1.27@pld-linux.org>
	<pld_builder.new_client_make_request.sh.1.28@pld-linux.org>
	<200707251714.26956.glen@delfi.ee>
Message-ID: <20070725162123.GA3613@mysza.eu.org>

On Wed, Jul 25, 2007 at 05:14:26PM +0300, Elan Ruusam?e wrote:
> however i use code from WORKING branch.

And which do we prefer - HEAD or WORKING? Sources from which branch are
used with Ac/Th builders?

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


From mmazur at kernel.pl  Wed Jul 25 20:59:41 2007
From: mmazur at kernel.pl (Mariusz Mazur)
Date: Wed, 25 Jul 2007 20:59:41 +0200
Subject: pld-builder.new: client/make-request.sh - -C/--config-file
	command...
In-Reply-To: <20070725162123.GA3613@mysza.eu.org>
References: <pld_builder.new_client_make_request.sh.1.27@pld-linux.org>
	<200707251714.26956.glen@delfi.ee>
	<20070725162123.GA3613@mysza.eu.org>
Message-ID: <200707252059.41729.mmazur@kernel.pl>

Dnia ?roda, 25 lipca 2007, Adam Go??biowski napisa?:
> On Wed, Jul 25, 2007 at 05:14:26PM +0300, Elan Ruusam?e wrote:
> > however i use code from WORKING branch.
>
> And which do we prefer - HEAD or WORKING? Sources from which branch are
> used with Ac/Th builders?

WORKING stopped being used in ac a long time ago. Unless something has 
changed, both ac and th use head.


-- 
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 blues at pld-linux.org  Thu Jul 26 09:38:01 2007
From: blues at pld-linux.org (Pawel Golaszewski)
Date: Thu, 26 Jul 2007 09:38:01 +0200 (CEST)
Subject: SPECS: spamassassin-plugin-fuzzyocr.spec - propper poppler-progs
	s...
In-Reply-To: <SPECS_spamassassin_plugin_fuzzyocr.spec.1.19@pld-linux.org>
References: <SPECS_spamassassin_plugin_fuzzyocr.spec.1.18@pld-linux.org>
	<SPECS_spamassassin_plugin_fuzzyocr.spec.1.19@pld-linux.org>
Message-ID: <Pine.LNX.4.64N.0707260936100.28769@fgnss.gnfx.tqn.cy>

On Thu, 26 Jul 2007, dzeus wrote:
> Author: dzeus                        Date: Thu Jul 26 06:21:09 2007 GMT
> Module: SPECS                         Tag: HEAD
> ---- Log message:
> - propper poppler-progs suggests
[...]
>  # For pdf-processing:
> -Suggests:	poppler-progs
> +Suggests:	poppler-progs <= 0.5.4

hhmmm... does it works that way?
I think that there should be Conflicts for newer versions.

Just guessing.

-- 
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.