From glen at pld-linux.org  Mon Mar  4 14:55:15 2013
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Mon, 04 Mar 2013 15:55:15 +0200
Subject: [packages/xulrunner] - updated required versions of nspr, glib2
 (gio), libpng, sqlite3
In-Reply-To: <f8c08c35b6b6c38bf8039f78fd921f9d067dda1d_refs_heads_master@pld-linux.org>
References: <f6d0e87629ffcb7f41ccb73029154a4fad986ffa_refs_heads_master@pld-linux.org>
 <f8c08c35b6b6c38bf8039f78fd921f9d067dda1d_refs_heads_master@pld-linux.org>
Message-ID: <5134A7C3.3030008@pld-linux.org>

On 22.02.2013 23:28, qboosh wrote:
> commit f8c08c35b6b6c38bf8039f78fd921f9d067dda1d
> Author: Jakub Bogusz <qboosh at pld-linux.org>
> Date:   Fri Feb 22 22:29:01 2013 +0100
>
>      - updated required versions of nspr, glib2 (gio), libpng, sqlite3
>

what's your workflow here, could it be added to cleanbuild [1] to automate?

[1] http://svn.pld-linux.org/cgi-bin/viewvc.cgi/svn/toys/tools/cleanbuild

-- 
glen



From glen at delfi.ee  Thu Mar  7 12:10:39 2013
From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 07 Mar 2013 13:10:39 +0200
Subject: libXt crashes?
Message-ID: <513875AF.7030404@delfi.ee>


https://bugs.launchpad.net/pld-linux/+bug/1145326

anyone? reproducible on at least two hosts with recent th packages

-- 
glen



From ed at yen.ipipan.waw.pl  Thu Mar  7 12:15:55 2013
From: ed at yen.ipipan.waw.pl (=?utf-8?B?xYF1a2FzeiBNYcWba28=?=)
Date: Thu, 07 Mar 2013 12:15:55 +0100
Subject: libXt crashes?
In-Reply-To: <513875AF.7030404@delfi.ee>
References: <513875AF.7030404@delfi.ee>
Message-ID: <1515271.hZfFGkxVdM@laptok>

Dnia czwartek, 7 marca 2013 13:10:39 Elan Ruusam?e pisze:
> https://bugs.launchpad.net/pld-linux/+bug/1145326
> 
> anyone? reproducible on at least two hosts with recent th packages

Not in my case (but I have i686)
:
$ rpm -q xorg-lib-libXt xorg-app-xconsole
xorg-lib-libXt-1.1.3-2.i686
xorg-app-xconsole-1.0.5-1.i686

-- 
?ukasz Ma?ko                                                            _o)
Lukasz.Masko(at)ipipan.waw.pl                                           /\\
Registered Linux User #61028                                           _\_V
Ubuntu: staroafryka?skie s?owo oznaczaj?ce "Nie umiem zainstalowa? Debiana"



From glen at pld-linux.org  Thu Mar  7 15:33:37 2013
From: glen at pld-linux.org (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=)
Date: Thu, 07 Mar 2013 16:33:37 +0200
Subject: libXt crashes?
In-Reply-To: <1515271.hZfFGkxVdM@laptok>
References: <513875AF.7030404@delfi.ee> <1515271.hZfFGkxVdM@laptok>
Message-ID: <5138A541.3000009@pld-linux.org>

On 07.03.2013 13:15, ?ukasz Ma?ko wrote:
> Dnia czwartek, 7 marca 2013 13:10:39 Elan Ruusam?e pisze:
>> https://bugs.launchpad.net/pld-linux/+bug/1145326
>>
>> anyone? reproducible on at least two hosts with recent th packages
> Not in my case (but I have i686)
> :
> $ rpm -q xorg-lib-libXt xorg-app-xconsole
> xorg-lib-libXt-1.1.3-2.i686
> xorg-app-xconsole-1.0.5-1.i686
but i'm not even sure what libraries are related...

-- 
glen



From qboosh at pld-linux.org  Thu Mar  7 19:26:59 2013
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Thu, 7 Mar 2013 19:26:59 +0100
Subject: [packages/xorg-util-util-macros] remove man3x from from
 xorg-macros.m4
In-Reply-To: <eb3559ebc2822a2aca0f4916c80956aeaa4359ef_refs_heads_master@pld-linux.org>
References: <380a393a3021e1003bd122c95aedaf4fae55c409_refs_heads_master@pld-linux.org>
 <eb3559ebc2822a2aca0f4916c80956aeaa4359ef_refs_heads_master@pld-linux.org>
Message-ID: <20130307182659.GA27827@mail>

On Tue, Mar 05, 2013 at 12:04:25AM +0100, glen wrote:
> commit eb3559ebc2822a2aca0f4916c80956aeaa4359ef
> Author: Elan Ruusam?e <glen at delfi.ee>
> Date:   Tue Mar 5 01:02:46 2013 +0200
> 
>     remove man3x from from xorg-macros.m4
>     
>     man3x dir does not exist, and if man pages refer to man3x via man links,
>     the manual pages can't be retrieved
>     
>     see:
>     http://git.pld-linux.org/?p=packages/xorg-lib-libXt.git;a=commitdiff;h=56aa5d5d5b17dd3b891ef00678eff52c9490ec1d
> 
>  xorg-util-util-macros-x.patch | 91 -------------------------------------------

Removal of this patches will cause build of all xorg-* packages
containing "%{_mandir}/...x*" to fail (because of missing "x").


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


From glen at pld-linux.org  Thu Mar  7 20:27:11 2013
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Thu, 07 Mar 2013 21:27:11 +0200
Subject: [packages/xorg-util-util-macros] remove man3x from from
 xorg-macros.m4
In-Reply-To: <20130307182659.GA27827@mail>
References: <380a393a3021e1003bd122c95aedaf4fae55c409_refs_heads_master@pld-linux.org>
 <eb3559ebc2822a2aca0f4916c80956aeaa4359ef_refs_heads_master@pld-linux.org>
 <20130307182659.GA27827@mail>
Message-ID: <5138EA0F.9000904@pld-linux.org>

On 03/07/2013 08:26 PM, Jakub Bogusz wrote:
> On Tue, Mar 05, 2013 at 12:04:25AM +0100, glen wrote:
>> commit eb3559ebc2822a2aca0f4916c80956aeaa4359ef
>> Author: Elan Ruusam?e <glen at delfi.ee>
>> Date:   Tue Mar 5 01:02:46 2013 +0200
>>
>>      remove man3x from from xorg-macros.m4
>>      
>>      man3x dir does not exist, and if man pages refer to man3x via man links,
>>      the manual pages can't be retrieved
>>      
>>      see:
>>      http://git.pld-linux.org/?p=packages/xorg-lib-libXt.git;a=commitdiff;h=56aa5d5d5b17dd3b891ef00678eff52c9490ec1d
>>
>>   xorg-util-util-macros-x.patch | 91 -------------------------------------------
> Removal of this patches will cause build of all xorg-* packages
> containing "%{_mandir}/...x*" to fail (because of missing "x").
>
>
you mean the %files section?

imho it's okay, our devs should handle mismatches in %files section 
nicely and update it to matching files

-- 
glen



From glen at pld-linux.org  Tue Mar 12 17:22:54 2013
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Tue, 12 Mar 2013 18:22:54 +0200
Subject: bug #1104474
Message-ID: <513F565E.9030806@pld-linux.org>

https://bugs.launchpad.net/pld-linux/+bug/1104474

so, altlinux fixed that problem already in 2009?

-- 
glen



From mike at osdn.org.ua  Tue Mar 12 17:27:23 2013
From: mike at osdn.org.ua (Michael Shigorin)
Date: Tue, 12 Mar 2013 18:27:23 +0200
Subject: bug #1104474
In-Reply-To: <513F565E.9030806@pld-linux.org>
References: <513F565E.9030806@pld-linux.org>
Message-ID: <20130312162722.GA21992@osdn.org.ua>

On Tue, Mar 12, 2013 at 06:22:54PM +0200, Elan Ruusam?e wrote:
> https://bugs.launchpad.net/pld-linux/+bug/1104474
> so, altlinux fixed that problem already in 2009?

Erm, let's ask Dmitry Levin.

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


From baggins at pld-linux.org  Tue Mar 12 18:57:31 2013
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 12 Mar 2013 18:57:31 +0100
Subject: bug #1104474
In-Reply-To: <20130312162722.GA21992@osdn.org.ua>
References: <513F565E.9030806@pld-linux.org>
 <20130312162722.GA21992@osdn.org.ua>
Message-ID: <20130312175731.GA24728@sith.mimuw.edu.pl>

On Tue, 12 Mar 2013, Michael Shigorin wrote:

> On Tue, Mar 12, 2013 at 06:22:54PM +0200, Elan Ruusam?e wrote:
> > https://bugs.launchpad.net/pld-linux/+bug/1104474
> > so, altlinux fixed that problem already in 2009?
> 
> Erm, let's ask Dmitry Levin.

That fix was for cpio, rpm has its own cpio writer.
BTW, fix for rpm commited :)

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org


From n3npq at me.com  Tue Mar 12 20:58:36 2013
From: n3npq at me.com (Jeffrey Johnson)
Date: Tue, 12 Mar 2013 15:58:36 -0400
Subject: bug #1104474
In-Reply-To: <20130312175731.GA24728@sith.mimuw.edu.pl>
References: <513F565E.9030806@pld-linux.org>
 <20130312162722.GA21992@osdn.org.ua>
 <20130312175731.GA24728@sith.mimuw.edu.pl>
Message-ID: <815F3C00-AB56-4E96-86A3-D12F39E6CCB5@me.com>


On Mar 12, 2013, at 1:57 PM, Jan R?korajski wrote:

> On Tue, 12 Mar 2013, Michael Shigorin wrote:
> 
>> On Tue, Mar 12, 2013 at 06:22:54PM +0200, Elan Ruusam?e wrote:
>>> https://bugs.launchpad.net/pld-linux/+bug/1104474
>>> so, altlinux fixed that problem already in 2009?
>> 
>> Erm, let's ask Dmitry Levin.
> 
> That fix was for cpio, rpm has its own cpio writer.
> BTW, fix for rpm commited :)
> 

Fix was what: undoing the transaction id suffix'd temp files?

Tricky to get right on a segfault because of limitations on signal handlers ...

73 de Jeff


> -- 
> Jan R?korajski                                 | PLD/Linux
> SysAdm                                         | http://www.pld-linux.org/
> baggins<at>mimuw.edu.pl
> baggins<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 n3npq at me.com  Tue Mar 12 21:03:56 2013
From: n3npq at me.com (Jeffrey Johnson)
Date: Tue, 12 Mar 2013 16:03:56 -0400
Subject: bug #1104474
In-Reply-To: <815F3C00-AB56-4E96-86A3-D12F39E6CCB5@me.com>
References: <513F565E.9030806@pld-linux.org>
 <20130312162722.GA21992@osdn.org.ua>
 <20130312175731.GA24728@sith.mimuw.edu.pl>
 <815F3C00-AB56-4E96-86A3-D12F39E6CCB5@me.com>
Message-ID: <56E40804-BD39-40E4-A85A-70CFD86D4078@me.com>


On Mar 12, 2013, at 3:58 PM, Jeffrey Johnson wrote:

> 
> On Mar 12, 2013, at 1:57 PM, Jan R?korajski wrote:
> 
>> On Tue, 12 Mar 2013, Michael Shigorin wrote:
>> 
>>> On Tue, Mar 12, 2013 at 06:22:54PM +0200, Elan Ruusam?e wrote:
>>>> https://bugs.launchpad.net/pld-linux/+bug/1104474
>>>> so, altlinux fixed that problem already in 2009?
>>> 
>>> Erm, let's ask Dmitry Levin.
>> 
>> That fix was for cpio, rpm has its own cpio writer.
>> BTW, fix for rpm commited :)
>> 
> 
> Fix was what: undoing the transaction id suffix'd temp files?
> 
> Tricky to get right on a segfault because of limitations on signal handlers ...
> 

If you mean that the patch here was applied to @rpm5.org code
	http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=7a9a5505667c681044bacb21c9b84ac66c062fe7
note that the information leakage was fixed a different way, during rpmbuild, by anonymizing
all ino_t that end up in a *.rpm metadata as a int32_t.

Its just a hash truncated to 32 bits, all that is needed is that all hardlinks have
identical ino_t marker, all the fuss about aliasing on a build system ino_t
accidental collision is just fuss-o-bout.

73 de Jeff
> 73 de Jeff
> 
> 
>> -- 
>> Jan R?korajski                                 | PLD/Linux
>> SysAdm                                         | http://www.pld-linux.org/
>> baggins<at>mimuw.edu.pl
>> baggins<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
> 
> _______________________________________________
> pld-devel-en mailing list
> pld-devel-en at lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-devel-en



From baggins at pld-linux.org  Tue Mar 12 21:34:53 2013
From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=)
Date: Tue, 12 Mar 2013 21:34:53 +0100
Subject: bug #1104474
In-Reply-To: <56E40804-BD39-40E4-A85A-70CFD86D4078@me.com>
References: <513F565E.9030806@pld-linux.org>
 <20130312162722.GA21992@osdn.org.ua>
 <20130312175731.GA24728@sith.mimuw.edu.pl>
 <815F3C00-AB56-4E96-86A3-D12F39E6CCB5@me.com>
 <56E40804-BD39-40E4-A85A-70CFD86D4078@me.com>
Message-ID: <20130312203453.GA23522@sith.mimuw.edu.pl>

On Tue, 12 Mar 2013, Jeffrey Johnson wrote:

> 
> On Mar 12, 2013, at 3:58 PM, Jeffrey Johnson wrote:
> 
> > 
> > On Mar 12, 2013, at 1:57 PM, Jan R?korajski wrote:
> > 
> >> On Tue, 12 Mar 2013, Michael Shigorin wrote:
> >> 
> >>> On Tue, Mar 12, 2013 at 06:22:54PM +0200, Elan Ruusam?e wrote:
> >>>> https://bugs.launchpad.net/pld-linux/+bug/1104474
> >>>> so, altlinux fixed that problem already in 2009?
> >>> 
> >>> Erm, let's ask Dmitry Levin.
> >> 
> >> That fix was for cpio, rpm has its own cpio writer.
> >> BTW, fix for rpm commited :)
> >> 
> > 
> > Fix was what: undoing the transaction id suffix'd temp files?
> > 
> > Tricky to get right on a segfault because of limitations on signal handlers ...
> > 
> 
> If you mean that the patch here was applied to @rpm5.org code
> 	http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=7a9a5505667c681044bacb21c9b84ac66c062fe7
> note that the information leakage was fixed a different way, during rpmbuild, by anonymizing
> all ino_t that end up in a *.rpm metadata as a int32_t.
> 
> Its just a hash truncated to 32 bits, all that is needed is that all hardlinks have
> identical ino_t marker, all the fuss about aliasing on a build system ino_t
> accidental collision is just fuss-o-bout.

I applied only the lib/fsm.c part, I saw that inode numbers were already
hashed in rpm5, they just weren't propagated I think.

-- 
Jan R?korajski                                 | PLD/Linux
SysAdm                                         | http://www.pld-linux.org/
baggins<at>mimuw.edu.pl
baggins<at>pld-linux.org


From n3npq at me.com  Tue Mar 12 21:42:27 2013
From: n3npq at me.com (Jeffrey Johnson)
Date: Tue, 12 Mar 2013 16:42:27 -0400
Subject: bug #1104474
In-Reply-To: <20130312203453.GA23522@sith.mimuw.edu.pl>
References: <513F565E.9030806@pld-linux.org>
 <20130312162722.GA21992@osdn.org.ua>
 <20130312175731.GA24728@sith.mimuw.edu.pl>
 <815F3C00-AB56-4E96-86A3-D12F39E6CCB5@me.com>
 <56E40804-BD39-40E4-A85A-70CFD86D4078@me.com>
 <20130312203453.GA23522@sith.mimuw.edu.pl>
Message-ID: <2D5CFCAD-2674-48B7-A5F4-49256EA9FBA1@me.com>


On Mar 12, 2013, at 4:34 PM, Jan R?korajski wrote:
.
> 
> I applied only the lib/fsm.c part, I saw that inode numbers were already
> hashed in rpm5, they just weren't propagated I think.
> 

If not propagated (by replacing the int32_t in the metadata with the truncated hash
of the ino64_t), then something else is wrong (I doubt it, but I have no idea what patches
are applied).

Yes you need to build the rpm with the truncated hash. Using the index instead of
the value (and the hack when xdev filesystem boundary is crossed) is less general
because it implicitly assumes that all hard links are contained in the same package ...
... which is a pretty safe assumption because of hoary practice but someone
is sure to complain.

*shrug* its all pretty much a fuss about nothing that eventually occurs. In most
cases a a later rebuild is gud enuf to repair the accidental collision.

73 de Jeff


> -- 
> Jan R?korajski                                 | PLD/Linux
> SysAdm                                         | http://www.pld-linux.org/
> baggins<at>mimuw.edu.pl
> baggins<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 glen at pld-linux.org  Wed Mar 13 10:18:49 2013
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Wed, 13 Mar 2013 11:18:49 +0200
Subject: bug #1104474
In-Reply-To: <2D5CFCAD-2674-48B7-A5F4-49256EA9FBA1@me.com>
References: <513F565E.9030806@pld-linux.org>
 <20130312162722.GA21992@osdn.org.ua>
 <20130312175731.GA24728@sith.mimuw.edu.pl>
 <815F3C00-AB56-4E96-86A3-D12F39E6CCB5@me.com>
 <56E40804-BD39-40E4-A85A-70CFD86D4078@me.com>
 <20130312203453.GA23522@sith.mimuw.edu.pl>
 <2D5CFCAD-2674-48B7-A5F4-49256EA9FBA1@me.com>
Message-ID: <51404479.7030900@pld-linux.org>

On 12.03.2013 22:42, Jeffrey Johnson wrote:
> (I doubt it, but I have no idea what patches
> are applied).
bug tracker has sample rpm files that segfault, you can use your vanilla 
rpm binary to test and confirm/exclude.

-- 
glen



From gotar at polanet.pl  Wed Mar 13 18:38:17 2013
From: gotar at polanet.pl (Tomasz Pala)
Date: Wed, 13 Mar 2013 18:38:17 +0100
Subject: [packages/chromium-browser] requires _XGetRequest
In-Reply-To: <511CA88A.5020601@pld-linux.org>
References: <f6284fe2fd4f1f38380685bd81e7fc561841b4f8_refs_heads_master@pld-linux.org>
 <2cbfc1a4ea176c3c6430f45613d3fb707a447294_refs_heads_master@pld-linux.org>
 <511BB221.2030700@pld-linux.org> <20130213160705.GA23369@mail>
 <511BBDEE.10302@pld-linux.org> <20130213171717.GC23369@mail>
 <511CA88A.5020601@pld-linux.org>
Message-ID: <20130313173817.GA19317@polanet.pl>

On Thu, Feb 14, 2013 at 11:04:10 +0200, Elan Ruusam?e wrote:

> but if it's just pairs of such detections, so if you find 
> incompatibility, you register it once, and all packages being built with 
> affected library exceeding specific version at build time, gets version 
>  >= dependency at runtime
[...]
> benefit of this approach is that once incompatibility is found, any 
> other rebuild will get the fix automatically, without need to update 
> .spec files with a versioned dependency.

Another example catched, (some?) packages build with Qt 4.8 use
_ZNK7QLocale18nativeLanguageNameEv which doesn't exist in 4.7. I've just
pushed librecad with manual R: QtCore >= 4.8.0...

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


From kiesiu at pld-linux.org  Tue Mar 19 09:26:51 2013
From: kiesiu at pld-linux.org (Lukasz Kies)
Date: Tue, 19 Mar 2013 09:26:51 +0100
Subject: [packages/grilo] - pl, completed dependencies
In-Reply-To: <b389ca4e05ef829aab497e36b221882987a9f66c_refs_heads_master@pld-linux.org>
References: <54b344eebea947d6603e94307d6a9391c5bfd49e_refs_heads_master@pld-linux.org>
 <b389ca4e05ef829aab497e36b221882987a9f66c_refs_heads_master@pld-linux.org>
Message-ID: <CADDE8wOpRs3HytDnuW_02kOh42++SNyJYNxWfJEsWt_Hg30H9w@mail.gmail.com>

2012/11/29 qboosh <qboosh at pld-linux.org>

> commit b389ca4e05ef829aab497e36b221882987a9f66c
> Author: Jakub Bogusz <qboosh at pld-linux.org>
> Date:   Thu Nov 29 21:10:02 2012 +0100
>
>     - pl, completed dependencies
>
>  grilo.spec | 51 +++++++++++++++++++++++++++++++--------------------
>  1 file changed, 31 insertions(+), 20 deletions(-)

[...]

> @@ -12,8 +13,9 @@ License:      LGPL v2.1+
>  Group:         Libraries
>  Source0:
> http://ftp.gnome.org/pub/GNOME/sources/grilo/0.2/%{name}-%{version}.tar.xz
>  # Source0-md5: 968ab6349839392d2d497674cd768529
> +Patch0:                %{name}-sh.patch
>  URL:           http://live.gnome.org/Grilo
> -BuildRequires: autoconf
> +BuildRequires: autoconf >= 2.50
>  BuildRequires: automake
>
[...]

> +API j?zyka Vala do bibliotek grilo.
>
>  %prep
>  %setup -q
> +%patch0 -p1
>
>  %build
>  %{__libtoolize}
> -%{__aclocal}
>
Hi,

grilo-sh.patch mentioned in Patch0 is not available in the repo. Could you
please push that commit also?


Regards,
?ukasz


From qboosh at pld-linux.org  Tue Mar 19 15:35:32 2013
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 19 Mar 2013 15:35:32 +0100
Subject: [packages/grilo] - pl, completed dependencies
In-Reply-To: <CADDE8wOpRs3HytDnuW_02kOh42++SNyJYNxWfJEsWt_Hg30H9w@mail.gmail.com>
References: <54b344eebea947d6603e94307d6a9391c5bfd49e_refs_heads_master@pld-linux.org>
 <b389ca4e05ef829aab497e36b221882987a9f66c_refs_heads_master@pld-linux.org>
 <CADDE8wOpRs3HytDnuW_02kOh42++SNyJYNxWfJEsWt_Hg30H9w@mail.gmail.com>
Message-ID: <20130319143532.GA11978@mail>

On Tue, Mar 19, 2013 at 09:26:51AM +0100, Lukasz Kies wrote:
> 2012/11/29 qboosh <qboosh at pld-linux.org>
> 
> > commit b389ca4e05ef829aab497e36b221882987a9f66c
> > Author: Jakub Bogusz <qboosh at pld-linux.org>
> > Date:   Thu Nov 29 21:10:02 2012 +0100
> >
> >     - pl, completed dependencies
> >
> >  grilo.spec | 51 +++++++++++++++++++++++++++++++--------------------
> >  1 file changed, 31 insertions(+), 20 deletions(-)
> 
> [...]
> 
> > @@ -12,8 +13,9 @@ License:      LGPL v2.1+
> >  Group:         Libraries
> >  Source0:
> > http://ftp.gnome.org/pub/GNOME/sources/grilo/0.2/%{name}-%{version}.tar.xz
> >  # Source0-md5: 968ab6349839392d2d497674cd768529
> > +Patch0:                %{name}-sh.patch
> >  URL:           http://live.gnome.org/Grilo
> > -BuildRequires: autoconf
> > +BuildRequires: autoconf >= 2.50
> >  BuildRequires: automake
> >
[...]
> Hi,
> 
> grilo-sh.patch mentioned in Patch0 is not available in the repo. Could you
> please push that commit also?

Added.


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


From glen at pld-linux.org  Tue Mar 19 17:36:49 2013
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Tue, 19 Mar 2013 18:36:49 +0200
Subject: [packages/hfsplus-tools] - pl, pass CFLAGS and LDFLAGS (no CC,
 as it must be clang because of Blocks extension)
In-Reply-To: <970d32e7c57960cb833cc80d1d6699ab5a821cfd_refs_heads_master@pld-linux.org>
References: <ffe0008969c4b2aacd3f40ffc7e07cc980b53f96_refs_heads_master@pld-linux.org>
 <970d32e7c57960cb833cc80d1d6699ab5a821cfd_refs_heads_master@pld-linux.org>
Message-ID: <51489421.2040901@pld-linux.org>

On 17.03.2013 09:10, qboosh wrote:
>   %build
> -export CFLAGS="%{rpmcflags}"
> -%{__make}
> +# note: keep CC=clang, not %{__cc}
> +%{__make} \
> +	CFLAGS="%{rpmcflags} -fblocks -Wall -I$(pwd)/BlocksRunTime -I$(pwd)/include -DDEBUG_BUILD=0 -D_FILE_OFFSET_BITS=64 -DLINUX=1 -DBSD=1 -DVERSION=\\\"%{version}\\\"" \
> +	LDFLAGS="%{rpmldflags} -L$(pwd)/BlocksRunTime"
wouldn't in such cases when you overwrite make variable, do a patch and 
write it into new variable (say OPTFLAGS), because copying existing 
CFLAGS contents to spec is source of mistakes with next code release. 
pld developers are lazy and check if CFLAGS has changed in Makefile only 
if there's some obvious error (compile fails).

make OPTPFAGS="%{rpmcflags}"

also if you ass CFLAGS as env, not make parameter, makefiles can 
CFLAGS+=something, and not needing to copy that contents to .spec

CFLAGS="%{rpmcflags}" make

-- 
glen



From glen at pld-linux.org  Tue Mar 19 17:40:38 2013
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Tue, 19 Mar 2013 18:40:38 +0200
Subject: rpmvercmp
Message-ID: <51489506.4070602@pld-linux.org>

is here a mistake?

rpm-5.4.10-44.x86_64:
$ rpmvercmp 5.5.0-0.4.alpha3 5.5.0-0.3.alpha6
5.5.0-0.4.alpha3 == 5.5.0-0.3.alpha6
why!?

rpm 4.5 has different opinion (one that i expect):

rpm-4.5-69.i686:
$ rpmvercmp 5.5.0-0.4.alpha3 5.5.0-0.3.alpha6
5.5.0-0.4.alpha3 > 5.5.0-0.3.alpha6

-- 
glen



From glen at pld-linux.org  Tue Mar 19 17:43:27 2013
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Tue, 19 Mar 2013 18:43:27 +0200
Subject: rpmvercmp
In-Reply-To: <51489506.4070602@pld-linux.org>
References: <51489506.4070602@pld-linux.org>
Message-ID: <514895AF.60505@pld-linux.org>

On 19.03.2013 18:40, Elan Ruusam?e wrote:
> is here a mistake?
>
> rpm-5.4.10-44.x86_64:
> $ rpmvercmp 5.5.0-0.4.alpha3 5.5.0-0.3.alpha6
> 5.5.0-0.4.alpha3 == 5.5.0-0.3.alpha6
> why!? 
some more:

$ rpmvercmp 5.5.0-0.5.0 5.5.0-0.3.0
5.5.0-0.5.0 == 5.5.0-0.3.0

$ rpmvercmp 5.5.0-0.5 5.5.0-0.3
5.5.0-0.5 == 5.5.0-0.3

$ rpmvercmp 5.5.0-0 5.5.0-0
5.5.0-0 == 5.5.0-0

$ rpmvercmp 5.5.0-0 5.5.0-1
5.5.0-0 == 5.5.0-1

$ rpmvercmp 5.5.0-10 5.5.0-1
5.5.0-10 == 5.5.0-1

$ rpmvercmp 5.5.0-0.11 5.5.0-0.1
5.5.0-0.11 == 5.5.0-0.1

$ rpmvercmp 5.5.0-0.111 5.5.0-0.1
5.5.0-0.111 == 5.5.0-0.1

$ rpmvercmp 5.5.0-0.111 5.5.0-0.10
5.5.0-0.111 == 5.5.0-0.10

what's the joke here? easter egg?

-- 
glen



From lukaszgl at post.pl  Tue Mar 19 23:10:02 2013
From: lukaszgl at post.pl (Lukasz Glebicki)
Date: Tue, 19 Mar 2013 23:10:02 +0100
Subject: rpmvercmp
In-Reply-To: <514895AF.60505@pld-linux.org>
References: <51489506.4070602@pld-linux.org> <514895AF.60505@pld-linux.org>
Message-ID: <2417540.kVC4eXBW18@inhell>

On Tuesday 19 of March 2013 18:43:27 Elan Ruusam?e wrote:

> what's the joke here? easter egg?

Joke, watch this:

rpmvercmp 1.0-glen 1.0-glen
1.0-glen == 1.0-glen

rpmvercmp 1.0-glen 1.0--glen 
1.0-glen > 1.0--glen


Regards,
-- 
?ukasz G??bicki  mail/rot13:yhxnfmty at cbfg.cy  PLD/Linux Team
gg:246267    Linux Registered User #318551   blekot:{irc,skype}


From gotar at polanet.pl  Wed Mar 20 03:10:26 2013
From: gotar at polanet.pl (Tomasz Pala)
Date: Wed, 20 Mar 2013 03:10:26 +0100
Subject: [packages/hfsplus-tools] - pl, pass CFLAGS and LDFLAGS (no CC,
 as it must be clang because of Blocks extension)
In-Reply-To: <51489421.2040901@pld-linux.org>
References: <ffe0008969c4b2aacd3f40ffc7e07cc980b53f96_refs_heads_master@pld-linux.org>
 <970d32e7c57960cb833cc80d1d6699ab5a821cfd_refs_heads_master@pld-linux.org>
 <51489421.2040901@pld-linux.org>
Message-ID: <20130320021026.GA26005@polanet.pl>

On Tue, Mar 19, 2013 at 18:36:49 +0200, Elan Ruusam?e wrote:

>> +%{__make} \
>> +	CFLAGS="%{rpmcflags} -fblocks -Wall -I$(pwd)/BlocksRunTime -I$(pwd)/include -DDEBUG_BUILD=0 -D_FILE_OFFSET_BITS=64 -DLINUX=1 -DBSD=1 -DVERSION=\\\"%{version}\\\"" \
>> +	LDFLAGS="%{rpmldflags} -L$(pwd)/BlocksRunTime"
> wouldn't in such cases when you overwrite make variable, do a patch and 
> write it into new variable (say OPTFLAGS),

I prefer sed -i on appropriate file, which:
- is easier to maintain than patch,
- introduces only flags we explicitly set,
- doesn't always need update (when something next to the place changes),
  but would fail when the flags we put in regexp are altered.

> make OPTPFAGS="%{rpmcflags}"
> 
> also if you ass CFLAGS as env, not make parameter, makefiles can 
> CFLAGS+=something, and not needing to copy that contents to .spec
> 
> CFLAGS="%{rpmcflags}" make

Sometimes you need to export env, depends on build system chaining.

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


From n3npq at me.com  Wed Mar 20 03:47:01 2013
From: n3npq at me.com (Jeffrey Johnson)
Date: Tue, 19 Mar 2013 22:47:01 -0400
Subject: rpmvercmp
In-Reply-To: <2417540.kVC4eXBW18@inhell>
References: <51489506.4070602@pld-linux.org> <514895AF.60505@pld-linux.org>
 <2417540.kVC4eXBW18@inhell>
Message-ID: <6572A6B8-C61C-42BE-A088-C6D985BD13B5@me.com>



On Mar 19, 2013, at 6:10 PM, Lukasz Glebicki <lukaszgl at post.pl> wrote:

> On Tuesday 19 of March 2013 18:43:27 Elan Ruusam?e wrote:
> 
>> what's the joke here? easter egg?
> 
> Joke, watch this:
> 
> rpmvercmp 1.0-glen 1.0-glen
> 1.0-glen == 1.0-glen
> 
> rpmvercmp 1.0-glen 1.0--glen 
> 1.0-glen > 1.0--glen
> 
> 

Is this something that needs fixing?

I pay attention to rpmvercmp only occasionally. It's likely a very easy fix.

73 de Jeff

> Regards,
> -- 
> ?ukasz G??bicki  mail/rot13:yhxnfmty at cbfg.cy  PLD/Linux Team
> gg:246267    Linux Registered User #318551   blekot:{irc,skype}
> _______________________________________________
> 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  Wed Mar 20 07:00:46 2013
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Wed, 20 Mar 2013 07:00:46 +0100
Subject: [packages/hfsplus-tools] - pl, pass CFLAGS and LDFLAGS (no CC,
 as it must be clang because of Blocks extension)
In-Reply-To: <20130320021026.GA26005@polanet.pl>
References: <ffe0008969c4b2aacd3f40ffc7e07cc980b53f96_refs_heads_master@pld-linux.org>
 <970d32e7c57960cb833cc80d1d6699ab5a821cfd_refs_heads_master@pld-linux.org>
 <51489421.2040901@pld-linux.org> <20130320021026.GA26005@polanet.pl>
Message-ID: <20130320060046.GA14981@mail>

On Wed, Mar 20, 2013 at 03:10:26AM +0100, Tomasz Pala wrote:
> On Tue, Mar 19, 2013 at 18:36:49 +0200, Elan Ruusam?e wrote:
> 
> >> +%{__make} \
> >> +	CFLAGS="%{rpmcflags} -fblocks -Wall -I$(pwd)/BlocksRunTime -I$(pwd)/include -DDEBUG_BUILD=0 -D_FILE_OFFSET_BITS=64 -DLINUX=1 -DBSD=1 -DVERSION=\\\"%{version}\\\"" \
> >> +	LDFLAGS="%{rpmldflags} -L$(pwd)/BlocksRunTime"
> > wouldn't in such cases when you overwrite make variable, do a patch and 
> > write it into new variable (say OPTFLAGS),

SOD#1 if you want to.
Note that -I options needed to be overridden too, because $(PWD) used in
this makefile is shell-dependent.

> I prefer sed -i on appropriate file, which:
> - is easier to maintain than patch,
> - introduces only flags we explicitly set,
> - doesn't always need update (when something next to the place changes),
>   but would fail when the flags we put in regexp are altered.

Unfortunately there is no option to fail if regex is not matched, so
in many cases sed becomes a no-op for long time...

> > make OPTPFAGS="%{rpmcflags}"
> > 
> > also if you ass CFLAGS as env, not make parameter, makefiles can 
> > CFLAGS+=something, and not needing to copy that contents to .spec
> > 
> > CFLAGS="%{rpmcflags}" make

Makefiles most often use CFLAGS[:]=..., so passing by environent
has no effect.


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


From glen at pld-linux.org  Wed Mar 20 11:34:28 2013
From: glen at pld-linux.org (=?ISO-8859-2?Q?Elan_Ruusam=E4e?=)
Date: Wed, 20 Mar 2013 12:34:28 +0200
Subject: [packages/hfsplus-tools] - pl, pass CFLAGS and LDFLAGS (no CC,
 as it must be clang because of Blocks extension)
In-Reply-To: <20130320021026.GA26005@polanet.pl>
References: <ffe0008969c4b2aacd3f40ffc7e07cc980b53f96_refs_heads_master@pld-linux.org>
 <970d32e7c57960cb833cc80d1d6699ab5a821cfd_refs_heads_master@pld-linux.org>
 <51489421.2040901@pld-linux.org> <20130320021026.GA26005@polanet.pl>
Message-ID: <514990B4.80507@pld-linux.org>

On 20.03.2013 04:10, Tomasz Pala wrote:
>> >
>> >CFLAGS="%{rpmcflags}" make
> Sometimes you need to export env, depends on build system chaining.
that was the syntax that "exports" to make

-- 
glen



From glen at pld-linux.org  Wed Mar 20 20:45:50 2013
From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=)
Date: Wed, 20 Mar 2013 21:45:50 +0200
Subject: udev-198 warning
Message-ID: <514A11EE.9050204@pld-linux.org>

if you upgrade to udev-198 and have not generated initrd with geninitrd 
 >= 12635 then your /dev/null, /dev/*random are with wrong permission, 
which leads to random problems, like can't ssh out as regular user, 
desktop environments not starting up, etc

20:14:59  glen> arekm: that /dev/null problem got to my laptop too
20:15:07  glen> so there's /dev/null is 660
20:15:17  glen> and /dev/random /dev/urandom as well, so i couldn't ssh 
as user
20:15:37  glen> and /dev/null problem caused lxdm -> mate session not to 
startup at all. just x11 background
20:16:05  glen> arekm: what's the cause and a fix? and could you post 
warning to devel-en as well?
20:16:15  glen> because more people will be affected and random errors 
occour
20:16:55 +arekm> glen: new udev doesn't touch these permissions, so 
initrd sets these. In our case set these wrongly
20:17:05 +arekm> glen: solution: upgrade geninitrd, regenerate initrd
20:17:17  glen> kernel-3.7.9-1.x86_64 udev-198-1.x86_64 
geninitrd-12582-3.noarch
20:17:32 +arekm> geninitrd >= 12635
20:17:33  glen> arekm: what versions are the edges?
20:17:38  glen> and what is udev "new" ?
20:18:04 +arekm> 198 for sure but no idea in which ver this got changed
20:18:18  glen> rpm -q --blink shows udev-197-5.x86_64.rpm
20:18:30  glen> so, 198 is the problematic one.
20:18:38  glen> any Conflicts somewhere make sense?
20:18:59 +arekm> partially since generated initrds won't fix themselfs
20:19:04  glen> and what devices are affected, you mentioned /dev/null, 
but i saw /dev/urandom problem too?
20:19:08 +arekm> already generated
20:19:14  glen> any list of them?
20:19:27 +arekm> see geninitrd svn commit, I guess only these
20:19:46  glen> well, in that case new udev must conflict on old geninitrd
20:20:36  glen> will you add that C and post to devel-en?


-- 
glen



From glen at pld-linux.org  Fri Mar 22 15:56:42 2013
From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=)
Date: Fri, 22 Mar 2013 16:56:42 +0200
Subject: [packages/util-linux] - fix man links - rel 4
In-Reply-To: <a40f6deeb713696b3323935f2f6024a3a763246f_refs_heads_master@pld-linux.org>
References: <9ebc19a01037d3bfb3382cc3aa9f96628e1f316b_refs_heads_master@pld-linux.org>
 <a40f6deeb713696b3323935f2f6024a3a763246f_refs_heads_master@pld-linux.org>
Message-ID: <514C712A.6000204@pld-linux.org>

On 22.03.2013 16:02, baggins wrote:
>   ln -sf hwclock $RPM_BUILD_ROOT/sbin/clock
> -echo '.so hwclock.8' > $RPM_BUILD_ROOT%{_mandir}/man8/clock.8
> +echo '.so man8/hwclock.8' > $RPM_BUILD_ROOT%{_mandir}/man8/clock.8
>   
>   ln -s utmpdump $RPM_BUILD_ROOT%{_bindir}/utmpx-dump
>   
> @@ -816,6 +816,14 @@ for d in es ja ko ; do
>   		$RPM_BUILD_ROOT%{_mandir}/$d/man8/readprofile.8
>   	%{__sed} -i -e 's/READPROFILE 1/READPROFILE 8/' $RPM_BUILD_ROOT%{_mandir}/$d/man8/readprofile.8
>   done
> +# fix inconsistent man links
> +echo '.so man8/hwclock.8' > $RPM_BUILD_ROOT%{_mandir}/es/man8/clock.8
> +echo '.so man8/hwclock.8' > $RPM_BUILD_ROOT%{_mandir}/ja/man8/clock.8
imho you can just rm the localizations that link to manpage, the english 
one will be used anyway

-- 
glen



From qboosh at pld-linux.org  Mon Mar 25 19:54:14 2013
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Mon, 25 Mar 2013 19:54:14 +0100
Subject: [packages/xulrunner] - updated required versions of nspr,
 glib2 (gio), libpng, sqlite3
In-Reply-To: <5134A7C3.3030008@pld-linux.org>
References: <f6d0e87629ffcb7f41ccb73029154a4fad986ffa_refs_heads_master@pld-linux.org>
 <f8c08c35b6b6c38bf8039f78fd921f9d067dda1d_refs_heads_master@pld-linux.org>
 <5134A7C3.3030008@pld-linux.org>
Message-ID: <20130325185414.GA391@mail>

On Mon, Mar 04, 2013 at 03:55:15PM +0200, Elan Ruusam?e wrote:
> On 22.02.2013 23:28, qboosh wrote:
> >commit f8c08c35b6b6c38bf8039f78fd921f9d067dda1d
> >Author: Jakub Bogusz <qboosh at pld-linux.org>
> >Date:   Fri Feb 22 22:29:01 2013 +0100
> >
> >     - updated required versions of nspr, glib2 (gio), libpng, sqlite3
> >
> 
> what's your workflow here, could it be added to cleanbuild [1] to automate?

I'm looking for required versions in configure.{ac,in}, CMakeLists.txt
(or equivalent) checks.


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


From draenog at pld-linux.org  Tue Mar 26 15:40:43 2013
From: draenog at pld-linux.org (Kacper Kornet)
Date: Tue, 26 Mar 2013 15:40:43 +0100
Subject: [packages/rpm-build-macros] validate that man links point to
 something resolveable
In-Reply-To: <b012dc654b555d36b557416b2d78f3a98e5c22b9_refs_heads_master@pld-linux.org>
References: <2fb1b7ce51401aa70ffe61eba116bc083e5070f4_refs_heads_master@pld-linux.org>
 <b012dc654b555d36b557416b2d78f3a98e5c22b9_refs_heads_master@pld-linux.org>
Message-ID: <20130326144042.GA5019@camk.edu.pl>

On Tue, Mar 05, 2013 at 12:06:12AM +0100, glen wrote:
> commit b012dc654b555d36b557416b2d78f3a98e5c22b9
> Author: Elan Ruusam?e <glen at delfi.ee>
> Date:   Tue Mar 5 01:05:40 2013 +0200

>     validate that man links point to something resolveable

>     for now, links to "outside" current package are not allowed

>  rpm.macros | 8 ++++++++
>  1 file changed, 8 insertions(+)
> ---
> diff --git a/rpm.macros b/rpm.macros
> index d45501c..d7063b0 100644
> --- a/rpm.macros
> +++ b/rpm.macros
> @@ -534,6 +534,14 @@ Provides: %{1} = %{?epoch:%{epoch}:}%{?version:%{version}}%{?release:-%{release}
>  				echo ".so $l" > $a; \
>  				echo >&2 "Converted ${a#$RPM_BUILD_ROOT} from symlink to man link: $l"; \
>  			done; \
> +			# verify that .so links point to existing files (not allowed to point to "other package")
> +			err=$(grep -rl '^\.so ' "$RPM_BUILD_ROOT$i" | while read doc; do \
> +				l=$(cat "$doc"); \
> +				l=${l#.so }; \
> +				# TODO: iterate over all man dirs, but in Th there's only one true man dir \
> +				test -e $RPM_BUILD_ROOT$i/$l || echo "  ${doc#$RPM_BUILD_ROOT} points to inexistent manpage: $l"; \
> +			done); \
> +			test "$err" != "" && { echo >&2 "Man page link errors:"; echo >&2 "$err"; exit 1; }; \
>  			find "$RPM_BUILD_ROOT$i" -type f -size +%{_min_compress_bytes}c -print | xargs -r %{__gzip} -9nf; \
>  		fi; \
>  	done; \


Isn't this check too much restrictive? It breaks around 50 specs:

$ grep -lP "echo '\.so (?!man\d)" *spec | wc -l
50

And links without man\d seem to work. Is there any specification that
forbids them?

-- 
  Kacper


From qboosh at pld-linux.org  Tue Mar 26 15:55:35 2013
From: qboosh at pld-linux.org (Jakub Bogusz)
Date: Tue, 26 Mar 2013 15:55:35 +0100
Subject: [packages/rpm-build-macros] validate that man links point to
 something resolveable
In-Reply-To: <20130326144042.GA5019@camk.edu.pl>
References: <2fb1b7ce51401aa70ffe61eba116bc083e5070f4_refs_heads_master@pld-linux.org>
 <b012dc654b555d36b557416b2d78f3a98e5c22b9_refs_heads_master@pld-linux.org>
 <20130326144042.GA5019@camk.edu.pl>
Message-ID: <20130326145535.GA3985@mail>

On Tue, Mar 26, 2013 at 03:40:43PM +0100, Kacper Kornet wrote:
> On Tue, Mar 05, 2013 at 12:06:12AM +0100, glen wrote:
> > commit b012dc654b555d36b557416b2d78f3a98e5c22b9
> > Author: Elan Ruusam?e <glen at delfi.ee>
> > Date:   Tue Mar 5 01:05:40 2013 +0200
> 
> >     validate that man links point to something resolveable
> 
> >     for now, links to "outside" current package are not allowed
> 
> >  rpm.macros | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > ---
> > diff --git a/rpm.macros b/rpm.macros
> > index d45501c..d7063b0 100644
> > --- a/rpm.macros
> > +++ b/rpm.macros
> > @@ -534,6 +534,14 @@ Provides: %{1} = %{?epoch:%{epoch}:}%{?version:%{version}}%{?release:-%{release}
> >  				echo ".so $l" > $a; \
> >  				echo >&2 "Converted ${a#$RPM_BUILD_ROOT} from symlink to man link: $l"; \
> >  			done; \
> > +			# verify that .so links point to existing files (not allowed to point to "other package")
> > +			err=$(grep -rl '^\.so ' "$RPM_BUILD_ROOT$i" | while read doc; do \
> > +				l=$(cat "$doc"); \
> > +				l=${l#.so }; \
> > +				# TODO: iterate over all man dirs, but in Th there's only one true man dir \
> > +				test -e $RPM_BUILD_ROOT$i/$l || echo "  ${doc#$RPM_BUILD_ROOT} points to inexistent manpage: $l"; \
> > +			done); \
> > +			test "$err" != "" && { echo >&2 "Man page link errors:"; echo >&2 "$err"; exit 1; }; \
> >  			find "$RPM_BUILD_ROOT$i" -type f -size +%{_min_compress_bytes}c -print | xargs -r %{__gzip} -9nf; \
> >  		fi; \
> >  	done; \
> 
> 
> Isn't this check too much restrictive? It breaks around 50 specs:
> 
> $ grep -lP "echo '\.so (?!man\d)" *spec | wc -l
> 50
> 
> And links without man\d seem to work.

AFAIK they work with man program (which used to be in PLD) but don't
work with man-db.

>Is there any specification that forbids them?

Don't know. Any references?


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


From draenog at pld-linux.org  Tue Mar 26 16:08:56 2013
From: draenog at pld-linux.org (Kacper Kornet)
Date: Tue, 26 Mar 2013 16:08:56 +0100
Subject: [packages/rpm-build-macros] validate that man links point to
 something resolveable
In-Reply-To: <20130326145535.GA3985@mail>
References: <2fb1b7ce51401aa70ffe61eba116bc083e5070f4_refs_heads_master@pld-linux.org>
 <b012dc654b555d36b557416b2d78f3a98e5c22b9_refs_heads_master@pld-linux.org>
 <20130326144042.GA5019@camk.edu.pl> <20130326145535.GA3985@mail>
Message-ID: <20130326150854.GB5019@camk.edu.pl>

On Tue, Mar 26, 2013 at 03:55:35PM +0100, Jakub Bogusz wrote:
> On Tue, Mar 26, 2013 at 03:40:43PM +0100, Kacper Kornet wrote:
> > On Tue, Mar 05, 2013 at 12:06:12AM +0100, glen wrote:
> > > commit b012dc654b555d36b557416b2d78f3a98e5c22b9
> > > Author: Elan Ruusam?e <glen at delfi.ee>
> > > Date:   Tue Mar 5 01:05:40 2013 +0200

> > >     validate that man links point to something resolveable

> > >     for now, links to "outside" current package are not allowed

> > >  rpm.macros | 8 ++++++++
> > >  1 file changed, 8 insertions(+)
> > > ---
> > > diff --git a/rpm.macros b/rpm.macros
> > > index d45501c..d7063b0 100644
> > > --- a/rpm.macros
> > > +++ b/rpm.macros
> > > @@ -534,6 +534,14 @@ Provides: %{1} = %{?epoch:%{epoch}:}%{?version:%{version}}%{?release:-%{release}
> > >  				echo ".so $l" > $a; \
> > >  				echo >&2 "Converted ${a#$RPM_BUILD_ROOT} from symlink to man link: $l"; \
> > >  			done; \
> > > +			# verify that .so links point to existing files (not allowed to point to "other package")
> > > +			err=$(grep -rl '^\.so ' "$RPM_BUILD_ROOT$i" | while read doc; do \
> > > +				l=$(cat "$doc"); \
> > > +				l=${l#.so }; \
> > > +				# TODO: iterate over all man dirs, but in Th there's only one true man dir \
> > > +				test -e $RPM_BUILD_ROOT$i/$l || echo "  ${doc#$RPM_BUILD_ROOT} points to inexistent manpage: $l"; \
> > > +			done); \
> > > +			test "$err" != "" && { echo >&2 "Man page link errors:"; echo >&2 "$err"; exit 1; }; \
> > >  			find "$RPM_BUILD_ROOT$i" -type f -size +%{_min_compress_bytes}c -print | xargs -r %{__gzip} -9nf; \
> > >  		fi; \
> > >  	done; \


> > Isn't this check too much restrictive? It breaks around 50 specs:

> > $ grep -lP "echo '\.so (?!man\d)" *spec | wc -l
> > 50

By the way it is a lower limit. There are some more packages that
internally use the syntax in question. So for example tcl aand tk would
need to be patched.

> > And links without man\d seem to work.

> AFAIK they work with man program (which used to be in PLD) but don't
> work with man-db.

It seems to work for me:

$ rpm -qf `which man`                     
man-db-2.6.3-1.i686 
$ cat /usr/share/man/man1/urxvtd.1
.so urxvtc.1
$ man -w urxvtd
/usr/share/man/man1/urxvtc.1.gz

> >Is there any specification that forbids them?

> Don't know. Any references?

-- 
  Kacper


From draenog at pld-linux.org  Tue Mar 26 17:15:13 2013
From: draenog at pld-linux.org (Kacper Kornet)
Date: Tue, 26 Mar 2013 17:15:13 +0100
Subject: [packages/rpm-build-macros] validate that man links point to
 something resolveable
In-Reply-To: <20130326150854.GB5019@camk.edu.pl>
References: <2fb1b7ce51401aa70ffe61eba116bc083e5070f4_refs_heads_master@pld-linux.org>
 <b012dc654b555d36b557416b2d78f3a98e5c22b9_refs_heads_master@pld-linux.org>
 <20130326144042.GA5019@camk.edu.pl> <20130326145535.GA3985@mail>
 <20130326150854.GB5019@camk.edu.pl>
Message-ID: <20130326161512.GC5019@camk.edu.pl>

On Tue, Mar 26, 2013 at 04:08:56PM +0100, Kacper Kornet wrote:
> On Tue, Mar 26, 2013 at 03:55:35PM +0100, Jakub Bogusz wrote:
> > On Tue, Mar 26, 2013 at 03:40:43PM +0100, Kacper Kornet wrote:
> > > On Tue, Mar 05, 2013 at 12:06:12AM +0100, glen wrote:
> > > > commit b012dc654b555d36b557416b2d78f3a98e5c22b9
> > > > Author: Elan Ruusam?e <glen at delfi.ee>
> > > > Date:   Tue Mar 5 01:05:40 2013 +0200

> > > >     validate that man links point to something resolveable

> > > >     for now, links to "outside" current package are not allowed

> > > >  rpm.macros | 8 ++++++++
> > > >  1 file changed, 8 insertions(+)
> > > > ---
> > > > diff --git a/rpm.macros b/rpm.macros
> > > > index d45501c..d7063b0 100644
> > > > --- a/rpm.macros
> > > > +++ b/rpm.macros
> > > > @@ -534,6 +534,14 @@ Provides: %{1} = %{?epoch:%{epoch}:}%{?version:%{version}}%{?release:-%{release}
> > > >  				echo ".so $l" > $a; \
> > > >  				echo >&2 "Converted ${a#$RPM_BUILD_ROOT} from symlink to man link: $l"; \
> > > >  			done; \
> > > > +			# verify that .so links point to existing files (not allowed to point to "other package")
> > > > +			err=$(grep -rl '^\.so ' "$RPM_BUILD_ROOT$i" | while read doc; do \
> > > > +				l=$(cat "$doc"); \
> > > > +				l=${l#.so }; \
> > > > +				# TODO: iterate over all man dirs, but in Th there's only one true man dir \
> > > > +				test -e $RPM_BUILD_ROOT$i/$l || echo "  ${doc#$RPM_BUILD_ROOT} points to inexistent manpage: $l"; \
> > > > +			done); \
> > > > +			test "$err" != "" && { echo >&2 "Man page link errors:"; echo >&2 "$err"; exit 1; }; \
> > > >  			find "$RPM_BUILD_ROOT$i" -type f -size +%{_min_compress_bytes}c -print | xargs -r %{__gzip} -9nf; \
> > > >  		fi; \
> > > >  	done; \


> > > Isn't this check too much restrictive? It breaks around 50 specs:

> > > $ grep -lP "echo '\.so (?!man\d)" *spec | wc -l
> > > 50

> By the way it is a lower limit. There are some more packages that
> internally use the syntax in question. So for example tcl aand tk would
> need to be patched.

> > > And links without man\d seem to work.

> > AFAIK they work with man program (which used to be in PLD) but don't
> > work with man-db.

> It seems to work for me:

> $ rpm -qf `which man`                     
> man-db-2.6.3-1.i686 
> $ cat /usr/share/man/man1/urxvtd.1
> .so urxvtc.1
> $ man -w urxvtd
> /usr/share/man/man1/urxvtc.1.gz

And indeed the NEWS file says it was fixed in man-db 2.6.0

-- 
  Kacper