From pluto at agmk.net Tue Jan 1 13:54:42 2013 From: pluto at agmk.net (=?utf-8?B?UGF3ZcWC?= Sikora) Date: Tue, 01 Jan 2013 13:54:42 +0100 Subject: glibc.spec / configure --with-pkgversion Message-ID: <2529445.D7JAWXxS0v@localhost> this change brokes 3rd party packages (like activestate-tcl) that parsing /lib*/libc-x.y.so result. testcase: $ echo 'package require platform; set p [platform::identify]; puts $p' | tclsh linux-glibc6.-x86_64 ^^^ should be linux-glibc2.17-x86_64 do we really need this breaking change? From glen at pld-linux.org Tue Jan 1 17:24:03 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Tue, 01 Jan 2013 18:24:03 +0200 Subject: nacl and large inodes Message-ID: <50E30DA3.30707@pld-linux.org> hi does somebody home with gcc internals want to take look is it pld problem, is it fixable, that x86_64-nacl-gcc on i686 fails if files, dirs are with inode > 2GiB? glen at carme-pld-i686 src/native_client $ touch a.c glen at carme-pld-i686 src/native_client $ x86_64-nacl-gcc -c a.c glen at carme-pld-i686 src/native_client $ x86_64-nacl-gcc -c a.c -I ../ppapi cc1: error: ../ppapi: Value too large for defined data type glen at carme-pld-i686 src/native_client $ ls -l -d -i ../ppapi 4316876546 drwxr-xr-x 14 glen users 4.0K jaan 1 17:46 ../ppapi/ glen at carme-pld-i686 src/native_client $ gcc -c a.c -I ../ppapi glen at carme-pld-i686 src/native_client $ rpm -q crossnacl-gcc crossnacl-gcc-4.4.3-8.git455063d.i686 -- glen From pluto at agmk.net Tue Jan 1 17:38:59 2013 From: pluto at agmk.net (=?utf-8?B?UGF3ZcWC?= Sikora) Date: Tue, 01 Jan 2013 17:38:59 +0100 Subject: nacl and large inodes In-Reply-To: <50E30DA3.30707@pld-linux.org> References: <50E30DA3.30707@pld-linux.org> Message-ID: <1892413.bNf470s7Cv@localhost> On Tuesday 01 of January 2013 18:24:03 Elan Ruusam?e wrote: > hi > > does somebody home with gcc internals want to take look is it pld > problem, is it fixable, that x86_64-nacl-gcc on i686 fails if files, > dirs are with inode > 2GiB? works for me for dir/file with inode > 2G. [pluto at carme-pld-i686 ~]$ stat ~/GNUstep/ File: '/home/users/pluto/GNUstep/' Size: 6 Blocks: 0 IO Block: 4096 directory Device: fd00h/64768d Inode: 3274325947 Links: 2 Access: (0755/drwxr-xr-x) Uid: ( 1028/ pluto) Gid: ( 1000/ users) Access: 2013-01-01 07:34:25.430322690 +0100 Modify: 2012-08-26 08:18:20.014377108 +0200 Change: 2012-08-26 08:18:20.067712942 +0200 Birth: - [pluto at carme-pld-i686 ~]$ stat ~/GNUstep/a.c File: '/home/users/pluto/GNUstep/a.c' Size: 0 Blocks: 0 IO Block: 4096 regular empty file Device: fd00h/64768d Inode: 3274325924 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1028/ pluto) Gid: ( 1000/ users) Access: 2013-01-01 17:36:13.909641613 +0100 Modify: 2013-01-01 17:36:13.909641613 +0100 Change: 2013-01-01 17:36:13.909641613 +0100 Birth: - [pluto at carme-pld-i686 ~]$ x86_64-nacl-gcc -c ~/GNUstep/a.c -I ~/GNUstep && echo ok ok From glen at pld-linux.org Tue Jan 1 17:46:57 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 01 Jan 2013 18:46:57 +0200 Subject: nacl and large inodes In-Reply-To: <1892413.bNf470s7Cv@localhost> References: <50E30DA3.30707@pld-linux.org> <1892413.bNf470s7Cv@localhost> Message-ID: <50E31301.4010901@pld-linux.org> On 01/01/13 18:38, Pawe? Sikora wrote: > On Tuesday 01 of January 2013 18:24:03 Elan Ruusam?e wrote: >> hi >> >> does somebody home with gcc internals want to take look is it pld >> problem, is it fixable, that x86_64-nacl-gcc on i686 fails if files, >> dirs are with inode > 2GiB? > works for me for dir/file with inode > 2G. yeah, apparently you used "fixed" gcc, as i already figured out file offset bits helps here http://git.pld-linux.org/?p=packages/crossnacl-gcc.git;a=commitdiff;h=fb2c96aee82a5e62c7301c23d2eb0b9a28e198ea $ l -i /usr/x86_64-nacl/include/sys/config.h 4295227912 -rw-r--r-- 1 root root 6.1K nov 11 20:35 /usr/x86_64-nacl/include/sys/config.h $ x86_64-nacl-gcc -include /usr/x86_64-nacl/include/sys/config.h -c a.c cc1: error: /usr/x86_64-nacl/include/sys/config.h: Value too large for defined data type $ LC_ALL=C q crossnacl-gcc -qi crossnacl-gcc-4.4.3-8.git455063d.i686 Name : crossnacl-gcc Relocations: (not relocatable) Version : 4.4.3 Vendor: pld Release : 8.git455063d Build Date: Tue Jan 1 18:35:22 2013 $ x86_64-nacl-gcc -include /usr/x86_64-nacl/include/sys/config.h -c a.c > [pluto at carme-pld-i686 ~]$ x86_64-nacl-gcc -c ~/GNUstep/a.c -I ~/GNUstep && echo ok > ok > -- glen From qboosh at pld-linux.org Wed Jan 2 15:45:36 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 2 Jan 2013 15:45:36 +0100 Subject: [packages/ccache] enable large file access for ccache In-Reply-To: <085404655893d3073875ddd295357647f71aca6a_refs_heads_master@pld-linux.org> References: <9ad23f95e3a72aaf49e653bd888a938770dbd089_refs_heads_master@pld-linux.org> <085404655893d3073875ddd295357647f71aca6a_refs_heads_master@pld-linux.org> Message-ID: <20130102144536.GA3486@mail> On Wed, Jan 02, 2013 at 03:30:28PM +0100, glen wrote: > commit 085404655893d3073875ddd295357647f71aca6a > Author: Elan Ruusam?e > Date: Wed Jan 2 16:26:55 2013 +0200 > > enable large file access for ccache > > seems ccache also suffering from big inode errors > http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2013-January/023380.html > > ccache.spec | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) [...] > @@ -14,6 +14,7 @@ BuildRequires: automake > BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n) > > %define _libdir %{_prefix}/%{_lib}/%{name} > +%define specflags -D_FILE_OFFSET_BITS=64 > > %description > ccache is a compiler cache. It acts as a caching pre-processor to IIRC %specflags are used only for optimized (non-debug) builds. Then debug builds are less featured. Is it still the case? -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Wed Jan 2 15:40:23 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 02 Jan 2013 16:40:23 +0200 Subject: [packages/ccache] enable large file access for ccache In-Reply-To: <20130102144536.GA3486@mail> References: <9ad23f95e3a72aaf49e653bd888a938770dbd089_refs_heads_master@pld-linux.org> <085404655893d3073875ddd295357647f71aca6a_refs_heads_master@pld-linux.org> <20130102144536.GA3486@mail> Message-ID: <50E446D7.9060505@pld-linux.org> On 02.01.2013 16:45, Jakub Bogusz wrote: > @@ -14,6 +14,7 @@ BuildRequires: automake > BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n) > > %define _libdir %{_prefix}/%{_lib}/%{name} > +%define specflags -D_FILE_OFFSET_BITS=64 > > %description > ccache is a compiler cache. It acts as a caching pre-processor to > IIRC %specflags are used only for optimized (non-debug) builds. > Then debug builds are less featured. > > Is it still the case? indeed it is. what's the proper way to add extra CPPFLAG? glen at carme-pld packages/ccache $ ./builder -bb ccache.spec -debug builder: SMP make flags are set to -j8 From git://git.pld-linux.org/packages/ccache * [new tag] auto/th/ccache-3.1.8-2 -> auto/th/ccache-3.1.8-2 085404655893d3073875ddd295357647f71aca6a Already on 'master' Already up-to-date. Available branches: AC-branch RA-branch master ccache-3.1.8.tar.bz2 having proper md5sum already exists Building target platforms: x86_64-linux Executing(%prep): /bin/sh -e /home/users/glen/tmp/rpm-tmp.89179 + umask 022 + cd /home/users/glen/rpm/packages/BUILD.x86_64-linux + cd /home/users/glen/rpm/packages/BUILD.x86_64-linux + rm -rf ccache-3.1.8 + /usr/bin/bzip2 -dc /home/users/glen/rpm/packages/ccache/ccache-3.1.8.tar.bz2 + /bin/tar -xf - + STATUS=0 + [ 0 -ne 0 ] + cd ccache-3.1.8 + /bin/id -u + [ 1009 = 0 ] + /bin/id -u + [ 1009 = 0 ] + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + echo Patch #0 (ccache-nohash_size_mtime.patch): Patch #0 (ccache-nohash_size_mtime.patch): + [ -f /home/users/glen/rpm/packages/ccache/ccache-nohash_size_mtime.patch ] + /bin/cat /home/users/glen/rpm/packages/ccache/ccache-nohash_size_mtime.patch + /usr/bin/patch -s -p1 + exit 0 Executing(%build): /bin/sh -e /home/users/glen/tmp/rpm-tmp.89179 + umask 022 + cd /home/users/glen/rpm/packages/BUILD.x86_64-linux + cd ccache-3.1.8 + cp -f /usr/share/automake/config.guess /usr/share/automake/config.sub . + ./configure LDFLAGS=-Wl,--as-needed -Wl,--no-copy-dt-needed-entries -Wl,-z,relro -Wl,-z,combreloc CFLAGS=-O0 -g -Wall -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 CXXFLAGS=-O0 -g -Wall -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 FFLAGS=-O0 -g -Wall -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 FCFLAGS=-O0 -g -Wall -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 CPPFLAGS= CC=ccache x86_64-pld-linux-gcc CXX=ccache x86_64-pld-linux-g++ --host=x86_64-pld-linux --build=x86_64-pld-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64/ccache --libexecdir=/usr/lib64 --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --x-libraries=/usr/lib64/ccache --cache-file=/home/users/glen/tmp/ccache-3.1.8-root-glen.th.x86_64.ccache.debug.configure.cache configure: creating cache /home/users/glen/tmp/ccache-3.1.8-root-glen.th.x86_64.ccache.debug.configure.cache configure: Configuring ccache checking for x86_64-pld-linux-gcc... ccache x86_64-pld-linux-gcc checking whether the C compiler works... yes ... -- glen From arekm at maven.pl Wed Jan 2 15:50:06 2013 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Wed, 2 Jan 2013 15:50:06 +0100 Subject: [packages/ccache] enable large file access for ccache In-Reply-To: <50E446D7.9060505@pld-linux.org> References: <9ad23f95e3a72aaf49e653bd888a938770dbd089_refs_heads_master@pld-linux.org> <20130102144536.GA3486@mail> <50E446D7.9060505@pld-linux.org> Message-ID: <201301021550.06182.arekm@maven.pl> On Wednesday 02 of January 2013, Elan Ruusam?e wrote: > On 02.01.2013 16:45, Jakub Bogusz wrote: > > @@ -14,6 +14,7 @@ BuildRequires: automake > > > > BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n) > > > > %define _libdir %{_prefix}/%{_lib}/%{name} > > > > +%define specflags -D_FILE_OFFSET_BITS=64 Put AC_SYS_LARGEFILE into configure.{in,ac} where possible instead of doing _FILE_OFFSET_BITS hacks. -- Arkadiusz Mi?kiewicz, arekm / maven.pl From glen at pld-linux.org Wed Jan 2 16:09:28 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Wed, 02 Jan 2013 17:09:28 +0200 Subject: [packages/ccache] enable large file access for ccache In-Reply-To: <201301021550.06182.arekm@maven.pl> References: <9ad23f95e3a72aaf49e653bd888a938770dbd089_refs_heads_master@pld-linux.org> <20130102144536.GA3486@mail> <50E446D7.9060505@pld-linux.org> <201301021550.06182.arekm@maven.pl> Message-ID: <50E44DA8.2010107@pld-linux.org> On 02.01.2013 16:50, Arkadiusz Mi?kiewicz wrote: > On Wednesday 02 of January 2013, Elan Ruusam?e wrote: >> On 02.01.2013 16:45, Jakub Bogusz wrote: >>> @@ -14,6 +14,7 @@ BuildRequires: automake >>> >>> BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n) >>> >>> %define _libdir %{_prefix}/%{_lib}/%{name} >>> >>> +%define specflags -D_FILE_OFFSET_BITS=64 > Put AC_SYS_LARGEFILE into configure.{in,ac} where possible instead of doing > _FILE_OFFSET_BITS hacks. ok, added note: http://cvs.pld-linux.org/cgi-bin/viewvc.cgi/cvs/PLD-doc/LFS-todo.txt?r1=1.16&r2=1.17 -- glen From glen at pld-linux.org Wed Jan 2 16:11:34 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Wed, 02 Jan 2013 17:11:34 +0200 Subject: [packages/ccache] enable large file access for ccache In-Reply-To: <201301021550.06182.arekm@maven.pl> References: <9ad23f95e3a72aaf49e653bd888a938770dbd089_refs_heads_master@pld-linux.org> <20130102144536.GA3486@mail> <50E446D7.9060505@pld-linux.org> <201301021550.06182.arekm@maven.pl> Message-ID: <50E44E26.9020105@pld-linux.org> On 02.01.2013 16:50, Arkadiusz Mi?kiewicz wrote: > On Wednesday 02 of January 2013, Elan Ruusam?e wrote: >> On 02.01.2013 16:45, Jakub Bogusz wrote: >>> @@ -14,6 +14,7 @@ BuildRequires: automake >>> >>> BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n) >>> >>> %define _libdir %{_prefix}/%{_lib}/%{name} >>> >>> +%define specflags -D_FILE_OFFSET_BITS=64 > Put AC_SYS_LARGEFILE into configure.{in,ac} where possible instead of doing > _FILE_OFFSET_BITS hacks. all fun, but ccache distribution does not include configure source configure.{in,ac} until then, it is safe to keep -D_FILE_OFFSET_BITS=64 for all current th architectures? -- glen From qboosh at pld-linux.org Wed Jan 2 20:12:32 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Wed, 2 Jan 2013 20:12:32 +0100 Subject: [packages/ccache] enable large file access for ccache In-Reply-To: <50E44E26.9020105@pld-linux.org> References: <9ad23f95e3a72aaf49e653bd888a938770dbd089_refs_heads_master@pld-linux.org> <20130102144536.GA3486@mail> <50E446D7.9060505@pld-linux.org> <201301021550.06182.arekm@maven.pl> <50E44E26.9020105@pld-linux.org> Message-ID: <20130102191232.GA3937@mail> On Wed, Jan 02, 2013 at 05:11:34PM +0200, Elan Ruusam?e wrote: > On 02.01.2013 16:50, Arkadiusz Mi?kiewicz wrote: > >On Wednesday 02 of January 2013, Elan Ruusam?e wrote: > >>On 02.01.2013 16:45, Jakub Bogusz wrote: > >>>@@ -14,6 +14,7 @@ BuildRequires: automake > >>> > >>> BuildRoot: %{tmpdir}/%{name}-%{version}-root-%(id -u -n) > >>> > >>> %define _libdir %{_prefix}/%{_lib}/%{name} > >>> > >>>+%define specflags -D_FILE_OFFSET_BITS=64 > >Put AC_SYS_LARGEFILE into configure.{in,ac} where possible instead of doing > >_FILE_OFFSET_BITS hacks. > all fun, but ccache distribution does not include configure source > configure.{in,ac} Maybe it's available in some public repository? > until then, it is safe to keep -D_FILE_OFFSET_BITS=64 for all current th > architectures? In single package - nothing worse should happen than when using it just on ix86. In ccache you can add CPPFLAGS="%{rpmcppflags} -D_FILE_OFFSET_BITS=64" just before %configure. -- Jakub Bogusz http://qboosh.pl/ From pluto at agmk.net Thu Jan 3 11:16:31 2013 From: pluto at agmk.net (=?utf-8?B?UGF3ZcWC?= Sikora) Date: Thu, 03 Jan 2013 11:16:31 +0100 Subject: [packages/uClibc] - rel 5; turn verbose on; filterout stack protector options (we didn't use that earlier, appared in In-Reply-To: References: <0382bc01002b6ad1ca50dd9ff3c7df8b58c8af8a_refs_heads_master@pld-linux.org> Message-ID: <6021699.Sa4vhZoBEY@pawels> On Thursday 03 of January 2013 11:09:40 arekm wrote: > +%define filterout -fstack-protector --param=ssp-buffer-size=4 i think that '%define _ssp_cflags %{nil}' looks better. From glen at pld-linux.org Thu Jan 3 11:28:38 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Thu, 03 Jan 2013 12:28:38 +0200 Subject: [packages/uClibc] - rel 5; turn verbose on; filterout stack protector options (we didn't use that earlier, appared in In-Reply-To: <6021699.Sa4vhZoBEY@pawels> References: <0382bc01002b6ad1ca50dd9ff3c7df8b58c8af8a_refs_heads_master@pld-linux.org> <6021699.Sa4vhZoBEY@pawels> Message-ID: <50E55D56.7040106@pld-linux.org> On 03.01.2013 12:16, Pawe? Sikora wrote: > On Thursday 03 of January 2013 11:09:40 arekm wrote: > >> +%define filterout -fstack-protector --param=ssp-buffer-size=4 > i think that '%define _ssp_cflags %{nil}' looks better. > i think filterout is better because it's more stright-forward. to know which _foo_cflags you need to undefine, is extra overhead to personal memory cells -- glen From baggins at pld-linux.org Thu Jan 3 11:36:57 2013 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Thu, 3 Jan 2013 11:36:57 +0100 Subject: [packages/uClibc] - rel 5; turn verbose on; filterout stack protector options (we didn't use that earlier, appared in In-Reply-To: <50E55D56.7040106@pld-linux.org> References: <0382bc01002b6ad1ca50dd9ff3c7df8b58c8af8a_refs_heads_master@pld-linux.org> <6021699.Sa4vhZoBEY@pawels> <50E55D56.7040106@pld-linux.org> Message-ID: <20130103103657.GA10793@sith.mimuw.edu.pl> On Thu, 03 Jan 2013, Elan Ruusam?e wrote: > On 03.01.2013 12:16, Pawe? Sikora wrote: > > On Thursday 03 of January 2013 11:09:40 arekm wrote: > > > >> +%define filterout -fstack-protector --param=ssp-buffer-size=4 > > i think that '%define _ssp_cflags %{nil}' looks better. > > > i think filterout is better because it's more stright-forward. to know > which _foo_cflags you need to undefine, is extra overhead to personal > memory cells Defining _ssp_cflags to nil is better and safer. If those flags ever change you'll end up filtering out wrong options. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From qboosh at pld-linux.org Thu Jan 3 19:39:53 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Thu, 3 Jan 2013 19:39:53 +0100 Subject: ERRORS: pcl.spec In-Reply-To: References: <1a37d9e4-780e-4594-95d5-bf4327bb88ea@pld.src.builder> Message-ID: <20130103183953.GA7298@mail> On Thu, Jan 03, 2013 at 06:25:13PM +0000, PLD th-x86_64 builder wrote: > pcl.spec (auto/th/pcl-1.6.0-1): FAILED cc1plus gets killed here. This package builds fine on carme (x86_64). Any ideas? Some resource limit? OOM? -- Jakub Bogusz http://qboosh.pl/ From arekm at maven.pl Thu Jan 3 19:34:14 2013 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Thu, 3 Jan 2013 19:34:14 +0100 Subject: ERRORS: pcl.spec In-Reply-To: <20130103183953.GA7298@mail> References: <1a37d9e4-780e-4594-95d5-bf4327bb88ea@pld.src.builder> <20130103183953.GA7298@mail> Message-ID: <201301031934.14981.arekm@maven.pl> On Thursday 03 of January 2013, Jakub Bogusz wrote: > On Thu, Jan 03, 2013 at 06:25:13PM +0000, PLD th-x86_64 builder wrote: > > pcl.spec (auto/th/pcl-1.6.0-1): FAILED > > cc1plus gets killed here. > This package builds fine on carme (x86_64). > > Any ideas? Some resource limit? OOM? [7443951.840566] Out of memory: Kill process 18200:#100 (cc1plus) score 205 or sacrifice child [7443951.840567] Killed process 18200:#100 (cc1plus) total-vm:1621080kB, anon- rss:232712kB, file-rss:64kB # free (long time after) total used free shared buffers cached Mem: 4046772 360796 3685976 0 68 124996 -/+ buffers/cache: 235732 3811040 Swap: 3502012 941308 2560704 Try building with -j 1 -- Arkadiusz Mi?kiewicz, arekm / maven.pl From glen at pld-linux.org Tue Jan 15 16:22:21 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Tue, 15 Jan 2013 17:22:21 +0200 Subject: [packages/hwdata] use oui.txt from ieee-oui package In-Reply-To: <0fdf1ddca9bfbcd1aa251e470e09d461faebce99_refs_heads_master@pld-linux.org> References: <5743531da0dfd1cf2566e853a945c80de821842b_refs_heads_master@pld-linux.org> <0fdf1ddca9bfbcd1aa251e470e09d461faebce99_refs_heads_master@pld-linux.org> Message-ID: <50F5742D.3080405@pld-linux.org> On 15.01.2013 16:40, glen wrote: > commit 0fdf1ddca9bfbcd1aa251e470e09d461faebce99 > Author: Elan Ruusam?e > Date: Tue Jan 15 16:40:03 2013 +0200 > > use oui.txt from ieee-oui package > > hwdata.spec | 12 +++++++----- > 1 file changed, 7 insertions(+), 5 deletions(-) > --- > diff --git a/hwdata.spec b/hwdata.spec > index 2d5d8d9..68a70a6 100644 > --- a/hwdata.spec > +++ b/hwdata.spec > @@ -7,14 +7,15 @@ Summary(pl.UTF-8): Dane do identyfikacji i konfiguracji sprz?tu > Name: hwdata > # see hwdata.spec inside of tarball > Version: 0.241 > -Release: 0.1 > +Release: 1 > License: GPL v2+ > Group: Applications/System > Source0: https://fedorahosted.org/releases/h/w/hwdata/%{name}-%{version}.tar.bz2 > # Source0-md5: 32dd541d778cfe0dd6100f88433bbc90 > +Requires: ieee-oui > Requires: pciutils > -Requires: usbutils > Requires: pnputils > +Requires: usbutils > +ln -sf %{_sysconfdir}/pci.ids $RPM_BUILD_ROOT%{_datadir}/hwdata/pci.ids > +ln -sf %{_sysconfdir}/usb.ids $RPM_BUILD_ROOT%{_datadir}/hwdata/usb.ids > +ln -sf %{_datadir}/misc/pnp.ids $RPM_BUILD_ROOT%{_datadir}/hwdata/pnp.ids > +ln -sf %{_datadir}/oui.txt $RPM_BUILD_ROOT%{_datadir}/hwdata/oui.txt > should we use different direction here? i.e hwdata containing datafiles, and various *utils packages depend on data provided by hwdata project? as the various ids update more regularily than code releases of *utils packages similar packages: - gentoo https://github.com/gentoo/hwids also contains also udev .hwdb pulled from systemd git - fedora https://fedorahosted.org/hwdata/ - ubuntu https://launchpad.net/ubuntu/+source/hwdata (seems to use fedora as source) - debian http://packages.debian.org/search?keywords=hwdata (does not open at this moment) -- glen From glen at pld-linux.org Tue Jan 15 20:24:18 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Tue, 15 Jan 2013 21:24:18 +0200 Subject: introspection dtd Message-ID: <50F5ACE2.1030303@pld-linux.org> as we have network access disabled (via resolv.conf not accessible by builders), then xslt processing which points to network resources fail any ideas in what package is "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" packaged? and if it's not packaged, then what should the package be that contains it? or what's the proper fix here? full log available here: http://buildlogs.pld-linux.org//index.php?dist=th&arch=x86_64&ok=0&ns=&cnt=50&off=0&name=mate-session-manager&id=4340171d-1759-49c8-8105-412e4110a4f1&action=text make[3]: Entering directory `/tmp/B.449aec39-a02f-41ba-a49f-920491d933f8/BUILD/mate-session-manager-1.5.0/doc/dbus' /usr/bin/xsltproc ../../doc/dbus/spec-to-docbook.xsl ../../mate-session/org.mate.SessionManager.xml | tail -n +2 > org.mate.SessionManager.ref.xml /usr/bin/xsltproc ../../doc/dbus/spec-to-docbook.xsl ../../mate-session/org.mate.SessionManager.Client.xml | tail -n +2 > org.mate.SessionManager.Client.ref.xml /usr/bin/xsltproc ../../doc/dbus/spec-to-docbook.xsl ../../mate-session/org.mate.SessionManager.ClientPrivate.xml | tail -n +2 > org.mate.SessionManager.ClientPrivate.ref.xml /usr/bin/xsltproc ../../doc/dbus/spec-to-docbook.xsl ../../mate-session/org.mate.SessionManager.Inhibitor.xml | tail -n +2 > org.mate.SessionManager.Inhibitor.ref.xml /usr/bin/xsltproc ../../doc/dbus/spec-to-docbook.xsl ../../mate-session/org.mate.SessionManager.Presence.xml | tail -n +2 > org.mate.SessionManager.Presence.ref.xml error : Resource temporarily unavailable ../../mate-session/org.mate.SessionManager.xml:2: warning: failed to load external entity "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" spection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" ^ error : Resource temporarily unavailable ../../mate-session/org.mate.SessionManager.ClientPrivate.xml:2: warning: failed to load external entity "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" spection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" ^ error : Resource temporarily unavailable error : Resource temporarily unavailable ../../mate-session/org.mate.SessionManager.Inhibitor.xml:2: ../../mate-session/org.mate.SessionManager.Presence.xml:2: warning: warning: failed to load external entity "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" failed to load external entity "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" spection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" spection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" ^ ^ error : Resource temporarily unavailable ../../mate-session/org.mate.SessionManager.Client.xml:2: warning: failed to load external entity "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" spection 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd" ^ /usr/bin/make all-am make[4]: Entering directory `/tmp/B.449aec39-a02f-41ba-a49f-920491d933f8/BUILD/mate-session-manager-1.5.0/doc/dbus' -- glen From baggins at pld-linux.org Thu Jan 17 10:18:35 2013 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Thu, 17 Jan 2013 10:18:35 +0100 Subject: [packages/hwdata] use oui.txt from ieee-oui package In-Reply-To: <50F5742D.3080405@pld-linux.org> References: <5743531da0dfd1cf2566e853a945c80de821842b_refs_heads_master@pld-linux.org> <0fdf1ddca9bfbcd1aa251e470e09d461faebce99_refs_heads_master@pld-linux.org> <50F5742D.3080405@pld-linux.org> Message-ID: <20130117091835.GB11202@sith.mimuw.edu.pl> On Tue, 15 Jan 2013, Elan Ruusam?e wrote: > On 15.01.2013 16:40, glen wrote: > > commit 0fdf1ddca9bfbcd1aa251e470e09d461faebce99 > > Author: Elan Ruusam?e > > Date: Tue Jan 15 16:40:03 2013 +0200 > > > > use oui.txt from ieee-oui package > > > > hwdata.spec | 12 +++++++----- > > 1 file changed, 7 insertions(+), 5 deletions(-) > > --- > > diff --git a/hwdata.spec b/hwdata.spec > > index 2d5d8d9..68a70a6 100644 > > --- a/hwdata.spec > > +++ b/hwdata.spec > > @@ -7,14 +7,15 @@ Summary(pl.UTF-8): Dane do identyfikacji i konfiguracji sprz?tu > > Name: hwdata > > # see hwdata.spec inside of tarball > > Version: 0.241 > > -Release: 0.1 > > +Release: 1 > > License: GPL v2+ > > Group: Applications/System > > Source0: https://fedorahosted.org/releases/h/w/hwdata/%{name}-%{version}.tar.bz2 > > # Source0-md5: 32dd541d778cfe0dd6100f88433bbc90 > > +Requires: ieee-oui > > Requires: pciutils > > -Requires: usbutils > > Requires: pnputils > > +Requires: usbutils > > > +ln -sf %{_sysconfdir}/pci.ids $RPM_BUILD_ROOT%{_datadir}/hwdata/pci.ids > > +ln -sf %{_sysconfdir}/usb.ids $RPM_BUILD_ROOT%{_datadir}/hwdata/usb.ids > > +ln -sf %{_datadir}/misc/pnp.ids $RPM_BUILD_ROOT%{_datadir}/hwdata/pnp.ids > > +ln -sf %{_datadir}/oui.txt $RPM_BUILD_ROOT%{_datadir}/hwdata/oui.txt > > > should we use different direction here? i.e hwdata containing datafiles, > and various *utils packages depend on data provided by hwdata project? > > as the various ids update more regularily than code releases of *utils > packages If hwdata is updated regularily then IMO it'll be better to use it and make *utils packages depend on it (udev should be an exception as it is the main source of .hwdb). -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From qboosh at pld-linux.org Fri Jan 18 15:55:55 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 18 Jan 2013 15:55:55 +0100 Subject: IJG libjpeg vs libjpeg-turbo Message-ID: <20130118145555.GA27429@mail> Looking for information about libjpeg-turbo API update wrt. libjpeg 9 I found this: http://sourceforge.net/mailarchive/forum.php?thread_name=50E29F02.9060804%40users.sourceforge.net&forum_name=libjpeg-turbo-devel It looks that libjpeg-turbo fully implements libjpeg features up to 6b, with partial API/ABI emulation (not full implementation) up to 8b (not even 8c as stated by Provides in libjpeg-turbo), unlikely to really support API 9 or fully support libjpeg 7+ additions. What to do now? One solution could be to ship libjpeg-turbo as libjpeg.so.6 (or even libjpeg.so.8, doesn't matter much) with development libjpeg.so symlink (so by default we get SIMD-accelerated basic JPEG support) and ship libjpeg 9 (as libjpeg.so.9) with different development symlink (libjpeg9.so or maybe libjpeg-ijg.so). Disadvantages: - it needs identification of packages relying on libjpeg 7+ functionality and patching them to link with -ljpeg9 - symbol clashes when libraries using libjpeg-turbo and libjpeg9 meet in common code space Second solution: use IJG libjpeg 9 by default and libjpeg-turbo only where needed (mostly mozilla products). Disadvantage: no SIMD accelaration outside few applications Other ideas? -- Jakub Bogusz http://qboosh.pl/ From gotar at polanet.pl Fri Jan 18 16:39:11 2013 From: gotar at polanet.pl (Tomasz Pala) Date: Fri, 18 Jan 2013 16:39:11 +0100 Subject: IJG libjpeg vs libjpeg-turbo In-Reply-To: <20130118145555.GA27429@mail> References: <20130118145555.GA27429@mail> Message-ID: <20130118153911.GA22163@polanet.pl> On Fri, Jan 18, 2013 at 15:55:55 +0100, Jakub Bogusz wrote: > One solution could be to ship libjpeg-turbo as libjpeg.so.6 (or even > libjpeg.so.8, doesn't matter much) with development libjpeg.so symlink > (so by default we get SIMD-accelerated basic JPEG support) and ship > libjpeg 9 (as libjpeg.so.9) with different development symlink > (libjpeg9.so or maybe libjpeg-ijg.so). +1 (turbo as libjpeg.so.8) Assuming linked rationale is valid, libjpeg8c+ might be not widely required: "Most of the recent IJG changes (post jpeg-8b) have been related to lossless JPEG encoding or SmartScale. Best case, SmartScale is a new format that has not been adopted as a standard yet and is not widely used, and worst case, it may be a mostly useless extension. The IJG's method for generating lossless JPEG files using SmartScale is interesting, but I struggle to think of a reason why one would want to use SmartScale for any other purpose" > Disadvantages: > - it needs identification of packages relying on libjpeg 7+ > functionality and patching them to link with -ljpeg9 - why 7+? - are there any apps like this? -- Tomasz Pala From qboosh at pld-linux.org Fri Jan 18 17:41:29 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Fri, 18 Jan 2013 17:41:29 +0100 Subject: IJG libjpeg vs libjpeg-turbo In-Reply-To: <20130118153911.GA22163@polanet.pl> References: <20130118145555.GA27429@mail> <20130118153911.GA22163@polanet.pl> Message-ID: <20130118164129.GA28750@mail> On Fri, Jan 18, 2013 at 04:39:11PM +0100, Tomasz Pala wrote: > On Fri, Jan 18, 2013 at 15:55:55 +0100, Jakub Bogusz wrote: > > > One solution could be to ship libjpeg-turbo as libjpeg.so.6 (or even > > libjpeg.so.8, doesn't matter much) with development libjpeg.so symlink > > (so by default we get SIMD-accelerated basic JPEG support) and ship > > libjpeg 9 (as libjpeg.so.9) with different development symlink > > (libjpeg9.so or maybe libjpeg-ijg.so). > > +1 (turbo as libjpeg.so.8) > > Assuming linked rationale is valid, libjpeg8c+ might be not widely required: > > "Most of the recent IJG changes (post > jpeg-8b) have been related to lossless JPEG encoding or SmartScale. > Best case, SmartScale is a new format that has not been adopted as a > standard yet and is not widely used, and worst case, it may be a mostly > useless extension. The IJG's method for generating lossless JPEG files > using SmartScale is interesting, but I struggle to think of a reason why > one would want to use SmartScale for any other purpose" > > > Disadvantages: > > - it needs identification of packages relying on libjpeg 7+ > > functionality and patching them to link with -ljpeg9 > > - why 7+? Quoting original post: "Anyhow, until/unless there is community support behind SmartScale, it is unlikely that it will ever be adopted in libjpeg-turbo (I don't have any need for it in my own work, so it would pretty much have to be a funded development sort of deal.) Thus, the implementation of the libjpeg v7+ API and ABI would remain just that: an emulation and not a feature-complete implementation of jpeg-7 or jpeg-8." > - are there any apps like this? I'm not sure, it needs checking. Also, I don't know if libjpeg-turbo supports compilation as 12-bit. libtiff can use both 8- and 12-bit variants of libjpeg (both formats can be embedded in TIFF). Should we use 8-bit libjpeg-turbo and 12-bit IJG libjpeg? -- Jakub Bogusz http://qboosh.pl/ From gotar at polanet.pl Sat Jan 19 11:26:52 2013 From: gotar at polanet.pl (Tomasz Pala) Date: Sat, 19 Jan 2013 11:26:52 +0100 Subject: IJG libjpeg vs libjpeg-turbo In-Reply-To: <20130118164129.GA28750@mail> References: <20130118145555.GA27429@mail> <20130118153911.GA22163@polanet.pl> <20130118164129.GA28750@mail> Message-ID: <20130119102651.GA26147@polanet.pl> On Fri, Jan 18, 2013 at 17:41:29 +0100, Jakub Bogusz wrote: >> - why 7+? > > Quoting original post: [...] > the implementation of the libjpeg v7+ API and ABI would remain just > that: an emulation and not a feature-complete implementation of jpeg-7 > or jpeg-8." - I recall no reports of missing features in turbo (shipped and used as so.8), so maybe they are so rarely used (if any at all) that we shouldn't care, - ABI is emulated, so in case of such report (3rd party app?) user should simply switch to IJG's .so.8 (that we shall provide as well). >> - are there any apps like this? > > I'm not sure, it needs checking. > > Also, I don't know if libjpeg-turbo supports compilation as 12-bit. http://sourceforge.net/p/libjpeg-turbo/discussion/1086868/thread/f4639c19/ http://sourceforge.net/p/libjpeg-turbo/discussion/1086868/thread/701941fc/ libjpeg-turbo doesn't provide any performance advantage over libjpeg for 12-bit data, and it isn't possible to use libjpeg-turbo for both 8-bit and 12-bit data at the same time. Thus, either way, you're going to end up having to call two different libraries if you want to support both 8-bit and 12-bit JPEGs in the same application. At the moment, you're better off using the upstream libjpeg code for 12-bit, since they actually test 12-bit data. > libtiff can use both 8- and 12-bit variants of libjpeg (both formats > can be embedded in TIFF). > Should we use 8-bit libjpeg-turbo and 12-bit IJG libjpeg? As far as I understand it properly, 12-bit libs can't handle 8-bit JPEGs, so we shouldn't replace any lib with 12-bit version. IMHO we should have: libjpeg-turbo with 8-bit jpeg.so.8 libjpeg with 8-bit jpeg.so.8 (for people that found missing/not emulated features, or use hardware without SIMD) libjpeg9 for some new apps, that might arise libjpeg[89] in 12-bit variant as low-priority option (not used anyway). -- Tomasz Pala From qboosh at pld-linux.org Tue Jan 22 17:53:47 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Tue, 22 Jan 2013 17:53:47 +0100 Subject: [packages/usbutils] update hwdata path In-Reply-To: References: <0ccdd7689199bc05e87e867ec19b3c42c4e7266d_refs_heads_master@pld-linux.org> Message-ID: <20130122165347.GA10177@mail> On Tue, Jan 22, 2013 at 05:38:11PM +0100, glen wrote: > commit ef10530fa82cdcf11af234f7f073eff25bcde52e > Author: Elan Ruusam?e > Date: Tue Jan 22 18:38:00 2013 +0200 > > update hwdata path But now {pci,usb}.ids are inaccessible without /usr mounted. That was the reason of moving them from /usr/share/misc to /etc... Maybe /lib/hwdata now? -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Tue Jan 22 17:53:45 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Tue, 22 Jan 2013 18:53:45 +0200 Subject: [packages/usbutils] update hwdata path In-Reply-To: <20130122165347.GA10177@mail> References: <0ccdd7689199bc05e87e867ec19b3c42c4e7266d_refs_heads_master@pld-linux.org> <20130122165347.GA10177@mail> Message-ID: <50FEC419.7020604@pld-linux.org> On 22.01.2013 18:53, Jakub Bogusz wrote: > On Tue, Jan 22, 2013 at 05:38:11PM +0100, glen wrote: >> commit ef10530fa82cdcf11af234f7f073eff25bcde52e >> Author: Elan Ruusam?e >> Date: Tue Jan 22 18:38:00 2013 +0200 >> >> update hwdata path > But now {pci,usb}.ids are inaccessible without /usr mounted. > That was the reason of moving them from /usr/share/misc to /etc... seems that was only true for pciutils, usbutils has different reason in commit https://github.com/pld-linux/pciutils/commit/5d206b802d827811d3ca63318235043814aae8f0 https://github.com/pld-linux/usbutils/commit/aac6f346272d0f54f946ed723d813ec9ee720967 so, move just pci.ids? also, when we are on this topic, the pnp.ids what we have in pnputils and what is in hwdata package are completely different probably the pnputils what we have, is not compatible with anything nowadays, is that package even needed? -- glen From qboosh at pld-linux.org Sun Jan 27 16:38:25 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Sun, 27 Jan 2013 16:38:25 +0100 Subject: capi4k-utils vs isdn4k-utils Message-ID: <20130127153825.GA20859@stranger.qboosh.pl> It seems that current isdn4k-utils repo/tarball contains also recent version of capi4k utils (currently built from old snapshot in capi4k-utils.spec). CAPI package names in isdn4k-utils.spec are quite messy - IMO we can rename CAPI parts from this spec to capi4k-utils{,-libs,-devel,-static}, thus replacing packages built from capi4k-utils.spec. Is it OK? -- Jakub Bogusz http://qboosh.pl/ From glen at pld-linux.org Sun Jan 27 19:29:16 2013 From: glen at pld-linux.org (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=) Date: Sun, 27 Jan 2013 20:29:16 +0200 Subject: pythonegg deps handling in rpm versions Message-ID: <70203d6846dfcade3f863e27d3554d35@delfi.ee> how to handle generated pythonegg versioned deps with aX and bX suffixes? glen at carme-pld-i686 packages/python-pyramid $ rpm -Uhv --test /home/users/glen/rpm/packages/RPMS/python-pyramid-1.4-0.1.noarch.rpm error: Failed dependencies: pythonegg(chameleon) >= 1.2.3 is needed by python-pyramid-1.4-0.1.noarch pythonegg(webob) >= 1.2b3 is needed by python-pyramid-1.4-0.1.noarch so considering webob being Library and and python-pyramid as Application: a) transform a into -0.a in rpm dependency generator? b) make those Provides: manually in Library? c) patch .egg in the Application not to be a7 but foo-0.a7? d) put dep into _noautoFOO in Application and handle dependency version manually? -- glen From glen at delfi.ee Sun Jan 27 20:18:32 2013 From: glen at delfi.ee (=?UTF-8?Q?Elan_Ruusam=C3=A4e?=) Date: Sun, 27 Jan 2013 21:18:32 +0200 Subject: pythonegg deps handling in rpm versions In-Reply-To: <70203d6846dfcade3f863e27d3554d35@delfi.ee> References: <70203d6846dfcade3f863e27d3554d35@delfi.ee> Message-ID: On 2013-01-27 20:29, Elan Ruusam?e wrote: > how to handle generated pythonegg versioned deps with aX and bX > suffixes? > > > glen at carme-pld-i686 packages/python-pyramid $ rpm -Uhv --test > /home/users/glen/rpm/packages/RPMS/python-pyramid-1.4-0.1.noarch.rpm > error: Failed dependencies: > pythonegg(chameleon) >= 1.2.3 is needed by > python-pyramid-1.4-0.1.noarch > pythonegg(webob) >= 1.2b3 is needed by > python-pyramid-1.4-0.1.noarch > > so considering webob being Library and and python-pyramid as > Application: > > a) transform a into -0.a in rpm > dependency generator? > b) make those Provides: manually in Library? > c) patch .egg in the Application not to be a7 but foo-0.a7? > d) put dep into _noautoFOO in Application and handle dependency > version manually? or even e) rename Library to contain aX in it's %{version} i'm not sure how python version's "grow", is 1.1a1 followed by 1.1 or 1.2? -- glen From qboosh at pld-linux.org Mon Jan 28 06:40:55 2013 From: qboosh at pld-linux.org (Jakub Bogusz) Date: Mon, 28 Jan 2013 06:40:55 +0100 Subject: pythonegg deps handling in rpm versions In-Reply-To: References: <70203d6846dfcade3f863e27d3554d35@delfi.ee> Message-ID: <20130128054055.GA30902@mail> On Sun, Jan 27, 2013 at 09:18:32PM +0200, Elan Ruusam?e wrote: > On 2013-01-27 20:29, Elan Ruusam?e wrote: > >how to handle generated pythonegg versioned deps with aX and bX > >suffixes? > > > > > >glen at carme-pld-i686 packages/python-pyramid $ rpm -Uhv --test > >/home/users/glen/rpm/packages/RPMS/python-pyramid-1.4-0.1.noarch.rpm > >error: Failed dependencies: > > pythonegg(chameleon) >= 1.2.3 is needed by > >python-pyramid-1.4-0.1.noarch > > pythonegg(webob) >= 1.2b3 is needed by > >python-pyramid-1.4-0.1.noarch > > > >so considering webob being Library and and python-pyramid as > >Application: > > > >a) transform a into -0.a in rpm > >dependency generator? > >b) make those Provides: manually in Library? > >c) patch .egg in the Application not to be a7 but foo-0.a7? > >d) put dep into _noautoFOO in Application and handle dependency > >version manually? > > or even > e) rename Library to contain aX in it's %{version} > > i'm not sure how python version's "grow", is 1.1a1 followed by 1.1 or > 1.2? It may be package/developer-specific. IIRC python itself used N.Ma -> N.Mb -> N.Mc -> N.M -- Jakub Bogusz http://qboosh.pl/ From n3npq at me.com Mon Jan 28 07:52:14 2013 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 28 Jan 2013 01:52:14 -0500 Subject: pythonegg deps handling in rpm versions In-Reply-To: <20130128054055.GA30902@mail> References: <70203d6846dfcade3f863e27d3554d35@delfi.ee> <20130128054055.GA30902@mail> Message-ID: <2B7C8097-6D28-4786-AD15-FF7735AD7F8C@me.com> On Jan 28, 2013, at 12:40 AM, Jakub Bogusz wrote: > > It may be package/developer-specific. > IIRC python itself used N.Ma -> N.Mb -> N.Mc -> N.M > And RPM uses N.M -> N.M[abc] so that Mandrake "N-V-Rmdk" is/was "newer" than Red Hat "N-V-R" packages, artificially breaking ASCII ordering and not meetting anyone's (except Mandrake's) expectations of RPM version comparison. (aside) There's a simple boolean in rpmdb/rpmevr.c: /* XXX Force digits to beat alphas. See bugzilla #50977. */ /*@unchecked@*/ #if defined(RPM_VENDOR_MANDRIVA) || defined(RPMVERCMP_DIGITS_BEAT_ALPHA) /* old-comparision-behaviour */ static int _invert_digits_alphas_comparison = -1; #else static int _invert_digits_alphas_comparison = 1; #endif that has been flipped in @rpm5.org code to partially restore ASCII ordering (where digits compare as less than alpha's). Flipping the bit isn't sufficient because digit and alpha strings are never directly compared: digits are compared with digits, alphas with alphas, in a segmented string comparison. When digits SHOULD naturally be compared to alphas, they are actually compared to NUL (i.e. '\0'). Changing this behavior in RPM is quite difficult since instant incompatibilities will be introduced. So the "best" (i.e. minimum necessary change) answer for RPM to accommodate expectations of Python eggs versioning is to attempt a transform (like adding "0." prefix) to ensure that RPM and Python eggs compare versions identically. hth 73 de Jeff > > -- > Jakub Bogusz http://qboosh.pl/ > _______________________________________________ > 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 Jan 29 11:51:58 2013 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Tue, 29 Jan 2013 11:51:58 +0100 Subject: IJG libjpeg vs libjpeg-turbo In-Reply-To: <20130119102651.GA26147@polanet.pl> References: <20130118145555.GA27429@mail> <20130118153911.GA22163@polanet.pl> <20130118164129.GA28750@mail> <20130119102651.GA26147@polanet.pl> Message-ID: <20130129105158.GI11202@sith.mimuw.edu.pl> On Sat, 19 Jan 2013, Tomasz Pala wrote: > On Fri, Jan 18, 2013 at 17:41:29 +0100, Jakub Bogusz wrote: > > >> - why 7+? > > > > Quoting original post: > [...] > > the implementation of the libjpeg v7+ API and ABI would remain just > > that: an emulation and not a feature-complete implementation of jpeg-7 > > or jpeg-8." > > - I recall no reports of missing features in turbo (shipped and used as so.8), > so maybe they are so rarely used (if any at all) that we shouldn't care, > - ABI is emulated, so in case of such report (3rd party app?) user > should simply switch to IJG's .so.8 (that we shall provide as well). > > >> - are there any apps like this? > > > > I'm not sure, it needs checking. > > > > Also, I don't know if libjpeg-turbo supports compilation as 12-bit. > > http://sourceforge.net/p/libjpeg-turbo/discussion/1086868/thread/f4639c19/ > http://sourceforge.net/p/libjpeg-turbo/discussion/1086868/thread/701941fc/ > > libjpeg-turbo doesn't provide any performance advantage over libjpeg for > 12-bit data, and it isn't possible to use libjpeg-turbo for both 8-bit and > 12-bit data at the same time. Thus, either way, you're going to end up having > to call two different libraries if you want to support both 8-bit and 12-bit > JPEGs in the same application. At the moment, you're better off using the > upstream libjpeg code for 12-bit, since they actually test 12-bit data. > > > libtiff can use both 8- and 12-bit variants of libjpeg (both formats > > can be embedded in TIFF). > > Should we use 8-bit libjpeg-turbo and 12-bit IJG libjpeg? > > As far as I understand it properly, 12-bit libs can't handle 8-bit > JPEGs, so we shouldn't replace any lib with 12-bit version. IMHO we > should have: > > libjpeg-turbo with 8-bit jpeg.so.8 > libjpeg with 8-bit jpeg.so.8 (for people that found missing/not emulated features, > or use hardware without SIMD) > libjpeg9 for some new apps, that might arise > libjpeg[89] in 12-bit variant as low-priority option (not used anyway). I second that, it looks to be the best solution. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From blues at pld-linux.org Tue Jan 29 17:02:19 2013 From: blues at pld-linux.org (=?ISO-8859-2?Q?Pawe=B3_Go=B3aszewski?=) Date: Tue, 29 Jan 2013 17:02:19 +0100 (CET) Subject: [packages/tmpwatch/merge-cronjobs-cron.d-dir] depend on crondaemon In-Reply-To: <52685776b35dbe842401e4004ec11c3a49b6d733_refs_heads_merge-cronjobs-cron.d-dir@pld-linux.org> References: <52685776b35dbe842401e4004ec11c3a49b6d733_refs_heads_merge-cronjobs-cron.d-dir@pld-linux.org> Message-ID: On Tue, 29 Jan 2013, glen wrote: > commit 52685776b35dbe842401e4004ec11c3a49b6d733 > Author: Elan Ruusam?e > Date: Tue Jan 29 17:01:04 2013 +0200 > > depend on crondaemon > > without it, none of this automatic cleanup would be possible :) > > BuildRequires: automake > +Requires: crondaemon Wrong. Without cron daemon you can still run tmpwatch manually. crondaemon should be suggested and advised but not required. -- pozdr. Pawe? Go?aszewski jid:bluesjabbergdapl -------------------------------------------------------------------------- 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 glen at pld-linux.org Wed Jan 30 11:47:14 2013 From: glen at pld-linux.org (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Wed, 30 Jan 2013 12:47:14 +0200 Subject: [packages/python-WsgiService] rebuild with pythonegg version change In-Reply-To: <29d1582f0dd546dd39a859cf5b10e909320615e9_refs_heads_master@pld-linux.org> References: <3e4ba575b5e2c79dd4d8ff0b77a58e644f807a4f_refs_heads_master@pld-linux.org> <29d1582f0dd546dd39a859cf5b10e909320615e9_refs_heads_master@pld-linux.org> Message-ID: <5108FA32.7070402@pld-linux.org> On 29.01.2013 16:52, glen wrote: > --- a/python-WsgiService.spec > +++ b/python-WsgiService.spec > @@ -1,3 +1,5 @@ > +# TODO > +# - rename to python-wscgiservice to conform pld py package naming > # imho it's rather confusing what should our naming convention to be as some (quite some) have "MyModuleName.egg" name but importable module name is "mymodule" most of the packages are created from name of the egg, not dir that module itself resides. should the "policy" [1] be adjusted/corrected? [1] http://git.pld-linux.org/?p=projects/template-specs.git;a=blob;f=python.spec;h=3fff0aac05ae749032f778fabd30a9a09db24e83;hb=6177d21724e6f0935a39aab7a70527f267321ac8#l8 -- glen From draenog at pld-linux.org Wed Jan 30 14:08:52 2013 From: draenog at pld-linux.org (Kacper Kornet) Date: Wed, 30 Jan 2013 14:08:52 +0100 Subject: How to fork a package In-Reply-To: <20121005141459.GB26291@camk.edu.pl> References: <20120908200836.GA1790@mail> <20120910174512.GA7192@mail> <506069D8.7010304@pld-linux.org> <20120928154652.GA8391@camk.edu.pl> <20121005134951.GA1306@stranger.qboosh.pl> <20121005141459.GB26291@camk.edu.pl> Message-ID: <20130130130852.GB30079@camk.edu.pl> On Fri, Oct 05, 2012 at 04:15:04PM +0200, Kacper Kornet wrote: > On Fri, Oct 05, 2012 at 03:49:51PM +0200, Jakub Bogusz wrote: > > Is there a way to just copy a repo (without setting the old one r/o)? > It can be done by creating a new repository and pushing to it. The only > thing which cannot be copied this way are auto- tags and RA- branches. > But if there is a demand for full copy I can add such a functionality. > I just didn't expect that it would be needed. Resurrecting the old thread. There is a new command - copy: $ ssh git at git.pld-linux.org copy It enables to fork an existing package without flood of messages on pld-cvs. But there some open questions which branches and tags it should copy into the new repo (right now it copies everything): a) ordinary branches and tags - I think there is no doubt that all should be copied b) auto tags auto//* - not sure c) distribution branches and tags e.g. AC-branch - I would prefer to have them copied as it is a little more tricky to exclude them as there is a lack on consistency in categories (tag vs. branch) and naming Any opinions? -- Kacper From glen at pld-linux.org Wed Jan 30 14:26:29 2013 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 30 Jan 2013 15:26:29 +0200 Subject: How to fork a package In-Reply-To: <20130130130852.GB30079@camk.edu.pl> References: <20120908200836.GA1790@mail> <20120910174512.GA7192@mail> <506069D8.7010304@pld-linux.org> <20120928154652.GA8391@camk.edu.pl> <20121005134951.GA1306@stranger.qboosh.pl> <20121005141459.GB26291@camk.edu.pl> <20130130130852.GB30079@camk.edu.pl> Message-ID: <51091F85.9060805@pld-linux.org> On 30.01.2013 15:08, Kacper Kornet wrote: > On Fri, Oct 05, 2012 at 04:15:04PM +0200, Kacper Kornet wrote: >> On Fri, Oct 05, 2012 at 03:49:51PM +0200, Jakub Bogusz wrote: >>> Is there a way to just copy a repo (without setting the old one r/o)? >> It can be done by creating a new repository and pushing to it. The only >> thing which cannot be copied this way are auto- tags and RA- branches. >> But if there is a demand for full copy I can add such a functionality. >> I just didn't expect that it would be needed. > Resurrecting the old thread. There is a new command - copy: > > $ ssh git at git.pld-linux.org copy > > It enables to fork an existing package without flood of messages on > pld-cvs. But there some open questions which branches and tags it should > copy into the new repo (right now it copies everything): > > a) ordinary branches and tags - I think there is no doubt that all > should be copied > > b) auto tags auto//* - not sure > > c) distribution branches and tags e.g. AC-branch - I would prefer to > have them copied as it is a little more tricky to exclude them as there > is a lack on consistency in categories (tag vs. branch) and naming > > Any opinions? i think, omit auto-tags when copying as these can't be cleaned up by ordinary user and also perhaps omit RA* branches, as these are not allowed to be edited also by ordinary user for AC-branch - keep it as it's possible to drop them by regular user -- glen