From lukasz at chrustek.net Fri Jun 6 14:48:55 2014 From: lukasz at chrustek.net (=?iso-8859-2?Q?=A3ukasz_Chrustek?=) Date: Fri, 6 Jun 2014 14:48:55 +0200 Subject: Cairo - undifened symbol Message-ID: <399918052.20140606144855@chrustek.net> Hi, I upgraded smokeing, with it cairo have upgraded too. I have now following error in /var/log/httpd/error_log: [Fri Jun 06 12:45:43.233169 2014] [cgi:error] [pid 32493] [client 10.1.0.6:58376] AH01215: /usr/bin/speedy_backend: symbol lookup error: /usr/lib/libcairo.so.2: undefined symbol: pixman_glyph_cache_create [Fri Jun 06 12:51:43.578944 2014] [cgi:error] [pid 32627] [client 10.1.0.6:58820] AH01215: /usr/bin/perl: symbol lookup error: /usr/lib/libcairo.so.2: undefined symbol: pixman_glyph_cache_create Sources from 2013 snapshot. cairo-1.12.16-7.i686 smokeping-2.4.2-12.noarch perl-CGI-SpeedyCGI-2.22-21.i686 As You can see there is no diffrence if perl or speedyCGI is used. What I need to upgrade/downgrade to solve this issue ? -- Regards, ?ukasz Chrustek From arekm at maven.pl Fri Jun 6 14:51:01 2014 From: arekm at maven.pl (Arkadiusz =?iso-8859-2?q?Mi=B6kiewicz?=) Date: Fri, 6 Jun 2014 14:51:01 +0200 Subject: Cairo - undifened symbol In-Reply-To: <399918052.20140606144855@chrustek.net> References: <399918052.20140606144855@chrustek.net> Message-ID: <201406061451.01944.arekm@maven.pl> On Friday 06 of June 2014, ?ukasz Chrustek wrote: > Hi, > > I upgraded smokeing, with it cairo have upgraded too. I have now > following error in /var/log/httpd/error_log: > > [Fri Jun 06 12:45:43.233169 2014] [cgi:error] [pid 32493] [client > 10.1.0.6:58376] AH01215: /usr/bin/speedy_backend: symbol lookup error: > /usr/lib/libcairo.so.2: undefined symbol: pixman_glyph_cache_create [Fri > Jun 06 12:51:43.578944 2014] [cgi:error] [pid 32627] [client > 10.1.0.6:58820] AH01215: /usr/bin/perl: symbol lookup error: > /usr/lib/libcairo.so.2: undefined symbol: pixman_glyph_cache_create upgrade pixman, too -- Arkadiusz Mi?kiewicz, arekm / maven.pl From lukasz at chrustek.net Fri Jun 6 15:09:37 2014 From: lukasz at chrustek.net (=?iso-8859-2?Q?=A3ukasz_Chrustek?=) Date: Fri, 6 Jun 2014 15:09:37 +0200 Subject: Cairo - undifened symbol In-Reply-To: <201406061451.01944.arekm@maven.pl> References: <399918052.20140606144855@chrustek.net> <201406061451.01944.arekm@maven.pl> Message-ID: <1993407342.20140606150937@chrustek.net> Hi, >> [Fri Jun 06 12:45:43.233169 2014] [cgi:error] [pid 32493] [client >> 10.1.0.6:58376] AH01215: /usr/bin/speedy_backend: symbol lookup error: >> /usr/lib/libcairo.so.2: undefined symbol: pixman_glyph_cache_create [Fri >> Jun 06 12:51:43.578944 2014] [cgi:error] [pid 32627] [client >> 10.1.0.6:58820] AH01215: /usr/bin/perl: symbol lookup error: >> /usr/lib/libcairo.so.2: undefined symbol: pixman_glyph_cache_create > upgrade pixman, too Thank You, that was the case. -- Regards, ?ukasz Chrustek From glen at pld-linux.org Mon Jun 9 22:53:51 2014 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Mon, 09 Jun 2014 23:53:51 +0300 Subject: src.rpm is not src.rpm Message-ID: <53961EDF.6060205@pld-linux.org> $ rpmbuild -bs alien Wrote: /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm $ file /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm: RPM v3.0 bin $ rpm --version rpm (RPM) 5.4.14 it used to work (rpm 4.5 on ac): $ rpmbuild -bs alien.spec Wrote: /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm $ file /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm: RPM v3 src alien-8.90-1 $ rpm --version RPM version 4.5 -- glen From glen at delfi.ee Tue Jun 10 10:43:20 2014 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Tue, 10 Jun 2014 11:43:20 +0300 Subject: blkid wrong Message-ID: <5396C528.5080509@delfi.ee> hi i have system where rootfs is on lvm with single pv, and rest of the system is on xfs on lvm on md rootfs is inited normally, but as systemd requires all fs to be mounted, the system does not boot up (recovery shell given after timeout) systemd fails to boot up such system because it does not "see" partitions where md stuff resides: # blkid /dev/sda: TYPE="isw_raid_member" /dev/sdb: TYPE="isw_raid_member" i can workaround this by adding to /lib/systemd/pld-storage-init: # systemd doesn't startup my mdadm blockdev --rereadpt /dev/sda blockdev --rereadpt /dev/sdb modprobe md mdadm --assemble --scan --auto=yes vgchange -ay after that blkid shows stuff (after rereadpt command), then udev creates /dev/sd[ab][13] and systemd sees rest of the stuff: # blkid /dev/sdb1: UUID="dcf25ea5-a302-24a4-9929-d90d71a9d1f9" TYPE="linux_raid_member" PARTUUID="afffafff-01" /dev/sdb3: UUID="4ed92802-d76e-f428-65a7-88d39a403e70" TYPE="linux_raid_member" PARTUUID="afffafff-03" /dev/sda1: UUID="dcf25ea5-a302-24a4-9929-d90d71a9d1f9" TYPE="linux_raid_member" PARTUUID="b1d2b1d2-01" /dev/sda3: UUID="4ed92802-d76e-f428-65a7-88d39a403e70" TYPE="linux_raid_member" PARTUUID="b1d2b1d2-03" /dev/md0: LABEL="/boot" UUID="4aad5633-a2b4-4106-b3ee-7f8820bcf2cb" TYPE="ext2" /dev/md2: UUID="8S0brw-Yh7S-dAe3-1ogV-e4SY-hZUs-CLaPQq" TYPE="LVM2_member" # cat /etc/mdadm.conf DEVICE /dev/sd[ab][123] ARRAY /dev/md0 UUID=dcf25ea5:a30224a4:9929d90d:71a9d1f9 ARRAY /dev/md2 UUID=4ed92802:d76ef428:65a788d3:9a403e70 packages: Mon Feb 17 15:10:59 2014 util-linux-2.24.1-1.x86_64 Sat Apr 5 15:48:03 2014 udev-208-11.x86_64 Sat Apr 5 15:48:03 2014 systemd-208-11.x86_64 Mon Feb 17 14:47:39 2014 mdadm-3.3-4.x86_64 -- glen From n3npq at me.com Tue Jun 10 12:41:42 2014 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 10 Jun 2014 06:41:42 -0400 Subject: src.rpm is not src.rpm In-Reply-To: <53961EDF.6060205@pld-linux.org> References: <53961EDF.6060205@pld-linux.org> Message-ID: Yes. Intended: the flag in the rpmlead structure is no longer set or used. Sent from my iPhone > On Jun 9, 2014, at 4:53 PM, Elan Ruusam?e wrote: > > > $ rpmbuild -bs alien > Wrote: /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm > $ file /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm > /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm: RPM v3.0 bin > $ rpm --version > rpm (RPM) 5.4.14 > > > it used to work (rpm 4.5 on ac): > $ rpmbuild -bs alien.spec > Wrote: /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm > $ file /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm > /home/users/glen/rpm/packages/SRPMS/alien-8.90-1.src.rpm: RPM v3 src alien-8.90-1 > $ rpm --version > RPM version 4.5 > > -- > glen > > _______________________________________________ > pld-devel-en mailing list > pld-devel-en at lists.pld-linux.org > http://lists.pld-linux.org/mailman/listinfo/pld-devel-en From jajcus at jajcus.net Tue Jun 10 14:15:45 2014 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 10 Jun 2014 14:15:45 +0200 Subject: blkid wrong In-Reply-To: <5396C528.5080509@delfi.ee> References: <5396C528.5080509@delfi.ee> Message-ID: <5396F6F1.7060308@jajcus.net> On 06/10/14 10:43, Elan Ruusam?e wrote: > i have system where rootfs is on lvm with single pv, > and rest of the system is on xfs on lvm on md > rootfs is inited normally, but as systemd requires all fs to be mounted, > the system does not boot up (recovery shell given after timeout) > > systemd fails to boot up such system because it does not "see" > partitions where md stuff resides: > # blkid > /dev/sda: TYPE="isw_raid_member" > /dev/sdb: TYPE="isw_raid_member" What initramfs do you use? geninitramfs or dracut? If geninitramfs, is udev in initramfs enabled? Is current udev included in the initramfs? Greets, Jacek From glen at pld-linux.org Tue Jun 10 14:45:09 2014 From: glen at pld-linux.org (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Tue, 10 Jun 2014 15:45:09 +0300 Subject: /etc/skel to filesystem Message-ID: <5396FDD5.5000501@pld-linux.org> $ rpm -qf /etc/skel/ pwdutils-3.2.19-2.x86_64 suggestion: move dir to filesystem package rationale: packages providing $HOME skeletons shouldn't depend on useradd tools in the future pwdutils could be replaced by shadow (again). background: stupid reason (initation for the change): bash Requires pwdutils for /etc/skel, but pwdutils is pointless dep in chroot intended to build packages -- glen From glen at delfi.ee Tue Jun 10 14:47:48 2014 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Tue, 10 Jun 2014 15:47:48 +0300 Subject: blkid wrong In-Reply-To: <5396F6F1.7060308@jajcus.net> References: <5396C528.5080509@delfi.ee> <5396F6F1.7060308@jajcus.net> Message-ID: <5396FE74.7030808@delfi.ee> On 10.06.2014 15:15, Jacek Konieczny wrote: > What initramfs do you use? geninitramfs or dracut? If geninitramfs, > is udev in initramfs enabled? Is current udev included in the initramfs? i used dracut. didn't test pld geninitrd (it had also problems with systemd, so i decided to try dracut) no idea what is geninitramfs, the debian initramfs? dracut i enabled hostonly config, and it does include systemd with udev on the initramfs.img and as i just built the dracut image, the udev on initrd and host should be identical version. -- glen From jajcus at jajcus.net Tue Jun 10 19:16:59 2014 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 10 Jun 2014 19:16:59 +0200 Subject: blkid wrong In-Reply-To: <5396FE74.7030808@delfi.ee> References: <5396C528.5080509@delfi.ee> <5396F6F1.7060308@jajcus.net> <5396FE74.7030808@delfi.ee> Message-ID: <53973D8B.5070201@jajcus.net> On 2014-06-10 14:47, Elan Ruusam?e wrote: > On 10.06.2014 15:15, Jacek Konieczny wrote: >> What initramfs do you use? geninitramfs or dracut? If geninitramfs, >> is udev in initramfs enabled? Is current udev included in the initramfs? > i used dracut. > didn't test pld geninitrd (it had also problems with systemd, so i > decided to try dracut) If that doesn't work with dracut I doubt geninitrd would help. > no idea what is geninitramfs, the debian initramfs? No, just a typo ;) > dracut i enabled hostonly config, and it does include systemd with udev > on the initramfs.img > and as i just built the dracut image, the udev on initrd and host should > be identical version. I guess bigger (not hostonly) dracut image could help (e.g. by making LVM tools available for udev device probing), but that would be rather a workaround than a fix. Or it doesn't help at all. Greets, Jacek From jajcus at jajcus.net Wed Jun 11 16:09:33 2014 From: jajcus at jajcus.net (Jacek Konieczny) Date: Wed, 11 Jun 2014 16:09:33 +0200 Subject: [packages/oracle-java8] - almost raw In-Reply-To: References: <20140611112709.18789.8425@pld-linux.org> Message-ID: <5398631D.3090304@jajcus.net> On 06/11/14 13:27, arekm wrote: > commit d3d5a6557a9d1b0c4a6d7be311eaea39c5f7f856 > Author: Arkadiusz Mi?kiewicz > Date: Wed Jun 11 13:27:02 2014 +0200 > > +License: restricted, distributable > +# http://www.oracle.com/technetwork/java/javase/terms/license/index.html > +# See "LICENSE TO DISTRIBUTE SOFTWARE" section, which states you can > +# redistribute in unmodified form. (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs, (ii) the Programs add significant and primary functionality to the Software, (iii) you do not distribute additional software intended to replace any component(s) of the Software, By distributing this within our distribution we break (i) and (iii). (i) ? it is not for only running 'our programs'. We want to provide JDK for people who need it for whatever purpose. (iii) ? we distribute IcedTea and may distribute other Oracle Java replacements. That is mostly the same crappy license as the old Sun license for Java. There was a period of time Sun had extra license for system distributions, but Oracle dropped that. IMHO the situation is clear: we cannot distribute Oracle Java. Greets, Jacek From baggins at pld-linux.org Thu Jun 12 20:04:40 2014 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Thu, 12 Jun 2014 20:04:40 +0200 Subject: /etc/skel to filesystem In-Reply-To: <5396FDD5.5000501@pld-linux.org> References: <5396FDD5.5000501@pld-linux.org> Message-ID: <20140612180439.GA1318@home.lan> On Tue, 10 Jun 2014, Elan Ruusam?e wrote: > $ rpm -qf /etc/skel/ > pwdutils-3.2.19-2.x86_64 > > suggestion: move dir to filesystem package > > rationale: packages providing $HOME skeletons shouldn't depend on > useradd tools Well, $HOME skeletons _are_ provided for the useradd tools, so it sounds strange to me that you don't want this dependency. > in the future pwdutils could be replaced by shadow (again). Even should, AFAIK pwdutils is unmaintained, contrary to shadow. > background: stupid reason (initation for the change): bash Requires > pwdutils for /etc/skel, but pwdutils is pointless dep in chroot intended > to build packages I'm against droping sensible deps for corner cases. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From jajcus at jajcus.net Thu Jun 12 20:19:47 2014 From: jajcus at jajcus.net (Jacek Konieczny) Date: Thu, 12 Jun 2014 20:19:47 +0200 Subject: /etc/skel to filesystem In-Reply-To: <20140612180439.GA1318@home.lan> References: <5396FDD5.5000501@pld-linux.org> <20140612180439.GA1318@home.lan> Message-ID: <5399EF43.2080508@jajcus.net> On 2014-06-12 20:04, Jan R?korajski wrote: > On Tue, 10 Jun 2014, Elan Ruusam?e wrote: > >> $ rpm -qf /etc/skel/ >> pwdutils-3.2.19-2.x86_64 >> >> suggestion: move dir to filesystem package >> >> rationale: packages providing $HOME skeletons shouldn't depend on >> useradd tools > > Well, $HOME skeletons _are_ provided for the useradd tools, so it sounds > strange to me that you don't want this dependency. But providing files for the skeleton doesn't mean that using it (through useradd) is in any way required. >> background: stupid reason (initation for the change): bash Requires >> pwdutils for /etc/skel, but pwdutils is pointless dep in chroot intended >> to build packages > > I'm against droping sensible deps for corner cases. I don't think that was a sensible dep. Bash doesn't need useradd or anything else. You may set up a working linux system with bash and no user accounts. It is, rather, the pwdutils which require bash files in /etc/skel to initialize user accound in a reasonable way, when shell of the user is set to /bin/bash. Still it is not such a hard dependency which should go to package meta-data. Greets, Jacek From baggins at pld-linux.org Thu Jun 12 20:27:37 2014 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Thu, 12 Jun 2014 20:27:37 +0200 Subject: [ANN] PHP changes in Th Message-ID: <20140612182736.GB1318@home.lan> Hi, After a lot of time and work from Elan Ruusam?e, we have new PHP package sets in Th. We decided it will be the best for maintainability and upgradability to have PHP interpreters only as versioned packages. Right now in th and th-ready we have PHP 5.2 to 5.5 as phpXY-* sets. php53 contains appropriate triggers for uprade from old php-5.3-*. Rationale for the change is that PHP upgrades are often problematic, as software requires certain versions, and because of that we'd still had to create versioned packages, creating needless work for admins to bump back and forth from unversioned to versioned packages. Making the switch now avoids that work and leaves the decision what PHP flavour to choose solely to the user. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From glen at delfi.ee Mon Jun 16 11:46:06 2014 From: glen at delfi.ee (=?UTF-8?B?RWxhbiBSdXVzYW3DpGU=?=) Date: Mon, 16 Jun 2014 12:46:06 +0300 Subject: [ANN] PHP changes in Th In-Reply-To: <20140612182736.GB1318@home.lan> References: <20140612182736.GB1318@home.lan> Message-ID: <539EBCDE.4080509@delfi.ee> the testing packages are in th-ready repository (not in main yet) To do the upgrade, you should run poldek -u php53-common or poldek -u php55-common. problems can be reported directly to me or #pld on irc On 12.06.2014 21:27, Jan R?korajski wrote: > Hi, > After a lot of time and work from Elan Ruusam?e, we have new PHP > package sets in Th. We decided it will be the best for maintainability > and upgradability to have PHP interpreters only as versioned packages. > Right now in th and th-ready we have PHP 5.2 to 5.5 as phpXY-* sets. > php53 contains appropriate triggers for uprade from old php-5.3-*. > > Rationale for the change is that PHP upgrades are often problematic, > as software requires certain versions, and because of that we'd still > had to create versioned packages, creating needless work for admins > to bump back and forth from unversioned to versioned packages. > Making the switch now avoids that work and leaves the decision > what PHP flavour to choose solely to the user. -- glen From glen at delfi.ee Thu Jun 19 20:57:13 2014 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Thu, 19 Jun 2014 21:57:13 +0300 Subject: oracle-instantclient (was: Re: /dev/null permissions - solved!) In-Reply-To: <537E7243.1040602@delfi.ee> References: <537A4FD8.7070108@delfi.ee> <537DCF77.8040709@delfi.ee> <537E6F5C.1010508@delfi.ee> <537E7243.1040602@delfi.ee> Message-ID: <53A33289.3030709@delfi.ee> On 23.05.2014 00:55, Elan Ruusam?e wrote: > ok, those two subjects aren't only ones to blame, seems "my > configuration" has caused this. > more particularily, a sqlnet.ora parameter: > > LOG_FILE_CLIENT = /dev/null > > which i took from > http://archimedeseureka.blogspot.com/2011/08/disabling-logging-for-oracle-instant.html > seems the original fix that appeared to work back then LOG_FILE_CLIENT = /dev/impossible/path is not really a fix, it makes library log again, so i'm in the middle of fork what to do, i don't want the logs nor i don't want /dev/null permissions to be altered. -- glen From baggins at pld-linux.org Sun Jun 22 22:54:32 2014 From: baggins at pld-linux.org (Jan =?utf-8?Q?R=C4=99korajski?=) Date: Sun, 22 Jun 2014 22:54:32 +0200 Subject: [ANN] PHP changes in Th In-Reply-To: <20140612182736.GB1318@home.lan> References: <20140612182736.GB1318@home.lan> Message-ID: <20140622205432.GA30365@tachikoma.lan> New php packages have benn moved to main Th ftp repository. On Thu, 12 Jun 2014, Jan R?korajski wrote: > Hi, > After a lot of time and work from Elan Ruusam?e, we have new PHP > package sets in Th. We decided it will be the best for maintainability > and upgradability to have PHP interpreters only as versioned packages. > Right now in th and th-ready we have PHP 5.2 to 5.5 as phpXY-* sets. > php53 contains appropriate triggers for uprade from old php-5.3-*. > > Rationale for the change is that PHP upgrades are often problematic, > as software requires certain versions, and because of that we'd still > had to create versioned packages, creating needless work for admins > to bump back and forth from unversioned to versioned packages. > Making the switch now avoids that work and leaves the decision > what PHP flavour to choose solely to the user. -- Jan R?korajski | PLD/Linux SysAdm | http://www.pld-linux.org/ bagginsmimuw.edu.pl bagginspld-linux.org From jajcus at jajcus.net Mon Jun 23 16:54:40 2014 From: jajcus at jajcus.net (Jacek Konieczny) Date: Mon, 23 Jun 2014 16:54:40 +0200 Subject: glibc-localedb-all for i686 and x86_64 Message-ID: <53A83FB0.8020404@jajcus.net> Hi, There is a problem with locale files on multiarch systems. [jajcus at jajo ~]$ rpm -ql glibc-localedb-all-2.19-2.i686 /usr/lib/locale/locale-archive [jajcus at jajo ~]$ rpm -ql glibc-localedb-all-2.19-2.x86_64 /usr/lib64/locale/locale-archive One is used by 32-bit binaries and the other by 64-bit binaries. The problem is when installing one with poldek, then the other one is un-installed. I had to use: just-install glibc-localedb-all-2.19-2.i686 --force to have locale data available to both 32- and 64-bit binaries. Why is one arch package replacing the other in this case? Shouldn't we fix that? Greets, Jacek From n3npq at me.com Mon Jun 23 17:00:57 2014 From: n3npq at me.com (Jeffrey Johnson) Date: Mon, 23 Jun 2014 11:00:57 -0400 Subject: glibc-localedb-all for i686 and x86_64 In-Reply-To: <53A83FB0.8020404@jajcus.net> References: <53A83FB0.8020404@jajcus.net> Message-ID: <46962727-C69A-488B-920F-567E0AA4DD63@me.com> On Jun 23, 2014, at 10:54 AM, Jacek Konieczny wrote: > Hi, > > There is a problem with locale files on multiarch systems. > > [jajcus at jajo ~]$ rpm -ql glibc-localedb-all-2.19-2.i686 > /usr/lib/locale/locale-archive > [jajcus at jajo ~]$ rpm -ql glibc-localedb-all-2.19-2.x86_64 > /usr/lib64/locale/locale-archive > > One is used by 32-bit binaries and the other by 64-bit binaries. The > problem is when installing one with poldek, then the other one is > un-installed. I had to use: > > just-install glibc-localedb-all-2.19-2.i686 --force > > to have locale data available to both 32- and 64-bit binaries. > > Why is one arch package replacing the other in this case? Shouldn't we > fix that? > The deeper question is Why is the localedb arch dependent? Fix the localedb implementation and you won?t have to worry about package replacement. 73 de Jeff > Greets, > Jacek > _______________________________________________ > 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 Mon Jun 23 23:45:49 2014 From: glen at pld-linux.org (=?windows-1252?Q?Elan_Ruusam=E4e?=) Date: Tue, 24 Jun 2014 00:45:49 +0300 Subject: glibc-localedb-all for i686 and x86_64 In-Reply-To: <46962727-C69A-488B-920F-567E0AA4DD63@me.com> References: <53A83FB0.8020404@jajcus.net> <46962727-C69A-488B-920F-567E0AA4DD63@me.com> Message-ID: <53A8A00D.8020405@pld-linux.org> On 23/06/14 18:00, Jeffrey Johnson wrote: > Fix the localedb implementation and you won?t have to worry > about package replacement. i've seen cases when even same arch localedb was not compatible when glibc version changed. haven't seen it lately as made my localedb package dependencies strict on glibc package version. -- glen From jajcus at jajcus.net Tue Jun 24 12:57:32 2014 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 24 Jun 2014 12:57:32 +0200 Subject: glibc-localedb-all for i686 and x86_64 In-Reply-To: <46962727-C69A-488B-920F-567E0AA4DD63@me.com> References: <53A83FB0.8020404@jajcus.net> <46962727-C69A-488B-920F-567E0AA4DD63@me.com> Message-ID: <53A9599C.2080501@jajcus.net> On 06/23/14 17:00, Jeffrey Johnson wrote: > On Jun 23, 2014, at 10:54 AM, Jacek Konieczny wrote: > > The deeper question is > > Why is the localedb arch dependent? > Fix the localedb implementation and you won?t have to worry > about package replacement. I was not sure if the data can be shared between 64- and 32-bit architectures. It seems it can, so I will fix glibc. I think I can even move the data to /usr/share and make glibc-localedb-all a noarch package. On the other hand? I am still curious why some packages are replaced why other can be installed simultaneously for two architectures. Greets, Jacek From gotar at polanet.pl Tue Jun 24 13:09:23 2014 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 24 Jun 2014 13:09:23 +0200 Subject: ImageMagick Q8 Message-ID: <20140624110923.GA7612@polanet.pl> Hi, most images these days are 8-bit/component, most IM use cases covers simple one-pass actions like converting formats or resizing, so while defaulting to Q16 is the right way to go as suggested by IM docs itself, we should also provide Q8 version, especially for wide range of server-side processing of user supplied content. And the overhead of Q16 is HUGE - 30-50% more of CPU time and TWICE as much of memory. All that wasted when most of the time anyone uses IM. There is Q8 in .test-builds/i686 currently if anyone wants to compare this. As far as I can see these versions can coexist safely, so the question is: is there a way to build package twice automatically when STBRed? Or the second pass needs to be explicitly handled by some loop inside spec? There are a few things that need to be adjusted - packages suffixes (I'd keep Q16 as it is, append to alternatives only), binaries suffixes, removing overlapping files, but putting all this double or triple times (Q32?) inside spec is a no-go (considering %files only). This would be better done in kernel* way, but I doubt anyone would remember to send the Q8 version among default when updating. And if nobody cares, it's pointless to work on. I've just made QuantumDepth overridable from --define and to be honest - it suits me, I don't need to mix different versions. OTOH, there are other packages linked with Q16 lib: autotrace, calibre, digikam, digikam, dvdauthor, emacs, emacs-athena, emacs-motif, gtatool-conv-magick, imgworks, libdmtx-utils, php-pecl-imagick, php53-pecl-imagick, php55-pecl-imagick, psiconv, ruby-RMagick, transcode, transcode-export, transcode-filter, transcode-import, virtuoso-plugins-hosting, xine-decode-image, xlockmore, zbar which might gain some performance when build with Q8, but building them all with alternatives would be an overkill (especially the ones that are not performance greedy and don't do much of image processing - like thumbnailing, which won't hurt on quality of Q8, but won't gain much of a performance either). So, any comments? -- Tomasz Pala From gotar at polanet.pl Tue Jun 24 13:11:36 2014 From: gotar at polanet.pl (Tomasz Pala) Date: Tue, 24 Jun 2014 13:11:36 +0200 Subject: glibc-localedb-all for i686 and x86_64 In-Reply-To: <53A9599C.2080501@jajcus.net> References: <53A83FB0.8020404@jajcus.net> <46962727-C69A-488B-920F-567E0AA4DD63@me.com> <53A9599C.2080501@jajcus.net> Message-ID: <20140624111135.GB7612@polanet.pl> On Tue, Jun 24, 2014 at 12:57:32 +0200, Jacek Konieczny wrote: > I think I can even move the data to /usr/share and make > glibc-localedb-all a noarch package. No endianness issue here? -- Tomasz Pala From jajcus at jajcus.net Tue Jun 24 13:40:00 2014 From: jajcus at jajcus.net (Jacek Konieczny) Date: Tue, 24 Jun 2014 13:40:00 +0200 Subject: glibc-localedb-all for i686 and x86_64 In-Reply-To: <20140624111135.GB7612@polanet.pl> References: <53A83FB0.8020404@jajcus.net> <46962727-C69A-488B-920F-567E0AA4DD63@me.com> <53A9599C.2080501@jajcus.net> <20140624111135.GB7612@polanet.pl> Message-ID: <53A96390.8080809@jajcus.net> On 06/24/14 13:11, Tomasz Pala wrote: > On Tue, Jun 24, 2014 at 12:57:32 +0200, Jacek Konieczny wrote: > >> I think I can even move the data to /usr/share and make >> glibc-localedb-all a noarch package. > > No endianness issue here? I don't know. And we currently support x86 only. But I will leave it in /usr/lib (both for 32 and 64 bits) anyway. It seems everybody keeps it there and this will be easier to package (no need to make sure i686 and x86_64 builds are byte-identical). Greets, Jacek From n3npq at me.com Tue Jun 24 17:40:14 2014 From: n3npq at me.com (Jeffrey Johnson) Date: Tue, 24 Jun 2014 11:40:14 -0400 Subject: glibc-localedb-all for i686 and x86_64 In-Reply-To: <53A9599C.2080501@jajcus.net> References: <53A83FB0.8020404@jajcus.net> <46962727-C69A-488B-920F-567E0AA4DD63@me.com> <53A9599C.2080501@jajcus.net> Message-ID: <91A92FE8-54FA-435B-9BBE-F016DA86F1CB@me.com> On Jun 24, 2014, at 6:57 AM, Jacek Konieczny wrote: > > > I think I can even move the data to /usr/share and make > glibc-localedb-all a noarch package. > Using /usr/share sounds like a great idea if endianness can be handled. > On the other hand? I am still curious why some packages are replaced why > other can be installed simultaneously for two architectures. > I can hazard a guess ? RPM ?prefers? one arch over another if there are two packages with the same name. The reason for the ?preference? for, say, /bin/ls, is this The behavior of the executable doesn?t depend on the arch. The ?preference? choice breaks down when extended beyond executables to packages like localedb that may (or may not) be affected/tainted by some arch property like endianness. The choice there is undecidable, but can be handled (like libraries) by installing content on arch dependent paths. hth 73 de Jeff > Greets, > Jacek > _______________________________________________ > 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 delfi.ee Wed Jun 25 09:16:07 2014 From: glen at delfi.ee (=?ISO-8859-1?Q?Elan_Ruusam=E4e?=) Date: Wed, 25 Jun 2014 10:16:07 +0300 Subject: ImageMagick Q8 In-Reply-To: <20140624110923.GA7612@polanet.pl> References: <20140624110923.GA7612@polanet.pl> Message-ID: <53AA7737.9090204@delfi.ee> On 24.06.2014 14:09, Tomasz Pala wrote: > which might gain some performance when build with Q8, but building them > all with alternatives would be an overkill (especially the ones that are > not performance greedy and don't do much of image processing - like > thumbnailing, which won't hurt on quality of Q8, but won't gain much of > a performance either). > > So, any comments? i noticed similar total performance loss (my site totally blackouted) when upgrading ac->th probably ~1y ago. i didn't know what was the cause, but my suspects were, glibc and ImageMagick. at that time i tried to compile newer glibc for ac and older IM for th, but both failed. so far i've stuck back to ac because this terrible performance loss! so i'm "in" for going back to to Q8 unconditionally distro-wide! -- glen From arekm at maven.pl Wed Jun 25 09:22:10 2014 From: arekm at maven.pl (Arkadiusz =?utf-8?q?Mi=C5=9Bkiewicz?=) Date: Wed, 25 Jun 2014 09:22:10 +0200 Subject: ImageMagick Q8 In-Reply-To: <20140624110923.GA7612@polanet.pl> References: <20140624110923.GA7612@polanet.pl> Message-ID: <201406250922.10436.arekm@maven.pl> On Tuesday 24 of June 2014, Tomasz Pala wrote: > Hi, > > most images these days are 8-bit/component, most IM use cases covers > simple one-pass actions like converting formats or resizing, so while > defaulting to Q16 is the right way to go as suggested by IM docs itself, > we should also provide Q8 version, especially for wide range of > server-side processing of user supplied content. And the overhead of Q16 > is HUGE - 30-50% more of CPU time and TWICE as much of memory. All that > wasted when most of the time anyone uses IM. What major distros do? FC seems to use Q16, didn't check the rest. If most of major distros is using Q8 then we could probably switch back. Or use Q8 for php and Q16 for desktop apps if possible? -- Arkadiusz Mi?kiewicz, arekm / maven.pl From zawadaa at gmail.com Wed Jun 25 13:49:51 2014 From: zawadaa at gmail.com (Andrzej Zawadzki) Date: Wed, 25 Jun 2014 13:49:51 +0200 Subject: ImageMagick Q8 In-Reply-To: <20140624110923.GA7612@polanet.pl> References: <20140624110923.GA7612@polanet.pl> Message-ID: <53AAB75F.1070009@gmail.com> On 24.06.2014 13:09, Tomasz Pala wrote: > Hi, > > most images these days are 8-bit/component, most IM use cases covers > simple one-pass actions like converting formats or resizing, so while > defaulting to Q16 is the right way to go as suggested by IM docs itself, > we should also provide Q8 version, especially for wide range of > server-side processing of user supplied content. And the overhead of Q16 > is HUGE - 30-50% more of CPU time and TWICE as much of memory. All that > wasted when most of the time anyone uses IM. > +1 -- Andrzej Zawadzki