Re: packages: xulrunner/xulrunner.spec - up to 1.9.2.3 - some loose *.so added ...
Fryderyk Dziarmagowski fre...@gmx.net [2010-04-03 10:12]:
On Sat, 03 Apr 2010 15:52:28 +0200
duddits dudd...@pld-linux.org wrote:
Author: duddits Date: Sat Apr 3 13:52:28 2010 GMT
Module: packages Tag: HEAD
Log message:
- up to 1.9.2.3
- some loose *.so added to -libs
[...]
+%attr(755,root,root) %{_libdir}/%{name}/libssl3.so
[...]
this is wrong, those are already provided by nss.
Something is still wrong.
poldek:/all-avail upgrade iceweasel-3.6.3-1.i686 -t
Processing dependencies...
iceweasel-3.6.2-1.i686 obsoleted by iceweasel-3.6.3-1.i686
iceweasel-3.6.3-1.i686 marks xulrunner-1.9.2.3-2.i686 (cap xulrunner =
2:1.9.2.3)
xulrunner-1.9.2-4.i686 obsoleted by xulrunner-1.9.2.3-2.i686
xulrunner-1.9.2.3-2.i686 marks xulrunner-libs-1.9.2.3-2.i686 (cap
xulrunner-libs = 2:1.9.2.3-2)
xulrunner-libs-1.9.2-4.i686 obsoleted by xulrunner-libs-1.9.2.3-2.i686
xulrunner-libs-1.9.2.3-2.i686 marks icedove-3.0.4-1.i686 (cap
libssl3.so(NSS_3.12.6))
$ iceweasel
Couldn't load XPCOM.
--
Radosław Zieliński ra...@pld-linux.org
pgpg9DEXEQ6nu.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: packages: perl-DBD-Pg/perl-DBD-Pg.spec - added missind %dir in %files secti...
amateja amat...@pld-linux.org [2009-09-09 13:57]:
Author: amateja Date: Wed Sep 9 11:57:35 2009 GMT
Module: packages Tag: HEAD
Log message:
- added missind %dir in %files section
- release 2
[...]
+%dir %{perl_vendorarch}/Bundle/DBD
%{perl_vendorarch}/Bundle/DBD/Pg.pm
We're not packaging any Bundle.pm; it's pointless. These are only
meaningful to CPAN.pm.
--
Radosław Zieliński ra...@pld-linux.org
pgpHqhXe7UTQh.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
gdb's debuglink support is broken
This path is correct:
$ objdump -s -j .gnu_debuglink
/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so
/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so:
file format elf32-i386
Contents of section .gnu_debuglink:
2f757372 2f6c6962 2f646562 75672f75 /usr/lib/debug/u
0010 73722f6c 69622f70 65726c35 2f76656e sr/lib/perl5/ven
0020 646f725f 7065726c 2f352e31 302e302f dor_perl/5.10.0/
0030 69363836 2d706c64 2d6c696e 75782d74 i686-pld-linux-t
0040 68726561 642d6d75 6c74692f 6175746f hread-multi/auto
0050 2f444244 2f50672f 50672e73 6f2e6465 /DBD/Pg/Pg.so.de
0060 62756700 96e2872fbug/
...but gdb doesn't use it properly; neither of these makes sense:
$ echo set args -MDBD::Pg -e 'warn42'\nr /tmp/foo
$ strace -etrace=file gdb -batch -x /tmp/foo perl 21 | grep Pg.so.debug
open(/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg//usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open(/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/.debug//usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open(/usr/lib/debug//usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg//usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open(/usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg//usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug,
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
According to [1], the paths should be:
/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug
/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/.debug/Pg.so.debug
/usr/lib/debug/usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi/auto/DBD/Pg/Pg.so.debug
I took a look at the 115 patches we have for gdb, but gave up. Anyone
familiar with this code?
[1] http://sources.redhat.com/gdb/current/onlinedocs/gdb_17.html#SEC166
--
Radosław Zieliński ra...@pld-linux.org
pgpANnokkbMMR.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
Arkadiusz Miskiewicz ar...@maven.pl [09-03-2009 22:41]: [...] Opinions? Current plan is to do this on a incoming weekend. 1 week notice for deprecating an architecture is *harsh*, IMO. -- Radosław Zieliński ra...@pld-linux.org pgp9vKwsJUnG1.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Th: dropping athlon and maybe deprecating ppc?
Pawel Golaszewski bl...@pld-linux.org [12-03-2009 15:18]: On Thu, 12 Mar 2009, Radoslaw Zielinski wrote: [...] -1: it's a major change and I can't see a good reason to warrant it. The pain will be much bigger, than the gain [1]. $ perl -le 'map print, @INC' | grep /lib/ /usr/local/lib/perl5/5.10.0/i686-pld-linux-thread-multi /usr/lib/perl5/vendor_perl/5.10.0/i686-pld-linux-thread-multi /usr/lib/perl5/5.10.0/i686-pld-linux-thread-multi We don't have to do it right now but on next bigger perl update? Why not? I'm cool with that. The thing I want to avoid is another needless clusterfuck, like the premature 5.10 update was. If we touch the first one, we'll screw over everyone who installed something using CPAN.pm. Who cares /usr/local entry? It can stay in that form. Well, consistency does. Anyway - can we add more paths to @INC? It will fix all the problems. We could. Some distros used to do that (eg. SuSe, IIRC), years ago; they had really long @INC... The cost is more stat() calls when loading modules (two calls per one entry; one, if we also get rid of *.pmc -- I've never seen it used). Ugly, though. -- Radosław Zieliński ra...@pld-linux.org pgpnXcLHToMLA.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: python-psycopg2.spec - Release 3. Killed nonworking mx bcond. Prepar...
wrobell wrob...@pld-linux.org [22-01-2009 02:43]: [...] i changed my mind. AC bcond is used. hope that's ok and it won't invoke any fucking cvs commit war. That's what branches are for. Creating mess in specs for a decaying distro line doesn't sound like a good idea to me. -- Radosław Zieliński ra...@pld-linux.org pgpt0gNJKEiF7.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Merging PLD patches for RPM @rpm5.org
Jeff Johnson n3...@mac.com [18-01-2009 16:31]: [...] Is the AUTODEP_PKGNAMES portion of the rpm-pld-autodep.patch, which maps dependencies back to package names, actually useful/used by PLD? The No. It has been turned off for Th, as it's an endless source of annoyances for cases where multiple packages can satisfy a given dependency. -- Radosław Zieliński ra...@pld-linux.org pgpWdeVHqVUHx.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Merging PLD patches for RPM @rpm5.org
Jeff Johnson n3...@mac.com [18-01-2009 17:37]: On Jan 18, 2009, at 10:56 AM, Radoslaw Zielinski wrote: Jeff Johnson n3...@mac.com [18-01-2009 16:31]: [...] Is the AUTODEP_PKGNAMES portion of the rpm-pld-autodep.patch, which maps dependencies back to package names, actually useful/used by PLD? No. It has been turned off for Th, as it's an endless source of annoyances for cases where multiple packages can satisfy a given dependency. ok, thanks. The case of multiple Provides: could be detected during the mapping and the mapping could be disabled (or build failed) when multiple Provides: are encountered. Does that permit AUTODEP_PKGNAMES to be useful/used by Th? No, as that would only work for already installed packages. You might have conflicting packages, which satisfy the same dependency (or just not have all of the alternatives installed at build time). It's just so much easier to accept the fact, that to resolve dependencies you need multiple data sets (name, epoch, version, release, provides, requires, %files, conflicts, obsoletes), than to mess around with %_noautoreq and fake provides trying to fit everything into the %name/version/release. -- Radosław Zieliński ra...@pld-linux.org pgp2KarRwPUzJ.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
libdrm 2.4.3 = X segfault
After upgrading libdrm to 2.4.3, my X have segfaulted like this: Backtrace: 0: /usr/bin/Xorg(xorg_backtrace+0x3b) [0x8120717] 1: /usr/bin/Xorg(xf86SigHandler+0x4d) [0x80b7980] 2: [0xb80c5400] 3: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b97400] 4: /usr/lib/xorg/modules/drivers//intel_drv.so [0xb7b98c36] 5: /usr/bin/Xorg(AddScreen+0x184) [0x806ac36] 6: /usr/bin/Xorg(InitOutput+0x1f7) [0x809fff8] 7: /usr/bin/Xorg(main+0x276) [0x806b3e9] 8: /lib/libc.so.6(__libc_start_main+0xee) [0xb7cf46ee] Fatal server error: Caught signal 11. Server aborting Full log: http://radek.cc/Xorg.0.log Does something need to be rebuilt...? Or is it just a screwed up release? -- Radosław Zieliński ra...@pld-linux.org pgp7kUHEI28Vz.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: libdrm 2.4.3 = X segfault
wrobell wrob...@pld-linux.org [24-12-2008 16:42]: On Wed, Dec 24, 2008 at 12:55:56PM +0100, Radoslaw Zielinski wrote: After upgrading libdrm to 2.4.3, my X have segfaulted like this: [...] which version of kernel? kernel-2.6.27.10-1.i686 (latest in Th repository). -- Radosław Zieliński ra...@pld-linux.org pgpyQlHh5i3pf.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: mysqltuner.patch - todo (quite obvious one)
Przemyslaw Iskra [EMAIL PROTECTED] [02-12-2008 00:39]:
On Mon, Dec 01, 2008 at 11:46:04PM +0100, glen wrote:
+TODO: cook perlish which(), or hardcode
should be enough:
sub which($)
{
my $file = shift || return undef;
foreach my $dir ( split /:/, ( $ENV{PATH} || return undef ) ) {
use File::Spec ();
foreach my $dir ( File::Spec-path ) {
my $path = $dir . '/' . $file;
my $path = File::Spec-catfile( $dir, $file );
--
Radosław Zieliński [EMAIL PROTECTED]
pgp5gjIs8annO.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: gdm 2.24.0
Patryk Zawadzki [EMAIL PROTECTED] [13-10-2008 13:54]: 2008/10/13 Radoslaw Zielinski [EMAIL PROTECTED]: Patryk Zawadzki [EMAIL PROTECTED] [13-10-2008 12:34]: [...] - our SystemV starts mingetty after X and tty1 steals keyboard input (Xorg takes the first free vte upon start, this is not a gdm problem). ...and an explanation why this statement is false. Sorry, unless it allows me to log in, I don't consider it working. PLD rc is broken, not gdm. The functionality of being able to log in is broken after update to 2.24. Possible solutions: - install upstart-SystemV which brings ttys up before X - that's what most distros do Conflicts: SysVinit then? R: upstart-SystemV That would silently screw someone who relies on SysVinit. Not acceptable without discussing it and some consensus. Conflicts would prevent both. C: real(SysVinit) # sigh [...] This can't be done in PLD unless we replace gdm-init with some sort of a configurable *dm chooser that we add to inittab which is not likely. [...] Don't ask me, we use a pretty non-standard and not-recommended method to start gdm. Too bad. Seems like it's going to have to wait. -- Radosław Zieliński [EMAIL PROTECTED] pgp1PzyZgNGHA.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: gdm 2.24.0
Patryk Zawadzki [EMAIL PROTECTED] [13-10-2008 12:34]: On Mon, Oct 13, 2008 at 12:05 PM, Radoslaw Zielinski [EMAIL PROTECTED] wrote: I have backed out gdm 2.24.0 to DEVEL. Reasons: 1) does not work: hangs the keyboard (only SysRq works) and the Shutdown / Reboot buttons do nothing It does work A statement... - our SystemV starts mingetty after X and tty1 steals keyboard input (Xorg takes the first free vte upon start, this is not a gdm problem). ...and an explanation why this statement is false. Sorry, unless it allows me to log in, I don't consider it working. Possible solutions: - install upstart-SystemV which brings ttys up before X - that's what most distros do Conflicts: SysVinit then? - move gdm startup to /etc/inittab - that's what the rest of the distros do R: rc-scripts-V-R ? - force Xorg to use a certain tty (there used to be a hack in GDM 2.20 for this as at this time Xorg did not have vte detection of its own, now detection is the recommended way to start Xorg as it allows one to have unlimited Xorg instances on one machine) How? 2) it's not finished, according to http://live.gnome.org/GDM Wrong, I'm a GNOME dev and can assure you it's part of GNOME 2.24 release. Ah. gdmsetup is no more? No word about it in ChangeLog nor in the release notes... Please keep the HEAD in a working state... It's actually being *used*. See above. Please move it back to HEAD. Please feel free to do it yourself, after making sure it works (with Conflicts/Requires where necessary). -- Radosław Zieliński [EMAIL PROTECTED] pgpoq9xpnRtxB.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: gdm 2.24.0
Jan Rekorajski [EMAIL PROTECTED] [13-10-2008 17:18]:
[...]
Ah, I remembered where {xdm,kdm,gdm}.init came from.
It was invented for X servers, a REAL X servers that do not have their
REAL X servers, huh? ;-
[...]
So, the proper solution is to add a no-display/tcp/xdmcp gdm config to
gdm-init and scream in post that this script is not intended for
starting local X server/X session (use /etc/inittab instead).
No, screaming in %post with suggestions on editing some config file
to get a basic desktop functionality is not a proper solution. [gxk]dm
should work OOTB after installing a package. Somehow.
--
Radosław Zieliński [EMAIL PROTECTED]
pgpWcc7WYzW4Z.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
gdm 2.24.0
I have backed out gdm 2.24.0 to DEVEL. Reasons: 1) does not work: hangs the keyboard (only SysRq works) and the Shutdown / Reboot buttons do nothing 2) it's not finished, according to http://live.gnome.org/GDM Please keep the HEAD in a working state... It's actually being *used*. -- Radosław Zieliński [EMAIL PROTECTED] pgpMs5ANasWa0.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pldlinux.pl for PLD Linux purposes
Wojciech Błaszkowski [EMAIL PROTECTED] [23-03-2008 01:15]:
Dnia sobota 22 marzec 2008, Radoslaw Zielinski napisał:
Wojciech Błaszkowski [EMAIL PROTECTED] [22-03-2008 09:57]:
[EN]: I would like to that domain name serves PLD. I can set it on
ns{1,2,3}.pld-linux.org or use present DNS and set them as slaves for PLD
nameservers or set on present DNS proper PLD zone.
The point being?
already discussed with domelu on #pld :)
nameservers set to ns0.pld-linux.org, ep09.pld-linux.org.
But you have not discussed it with everyone else on pld-discuss.
Discussions with domelu on #pld does not a general consensus make.
Decisions on domain names affect the identity of the project, therefore
should not be taken lightly. Not to mention that we had issues with
control over both pld.org.pl (major mess) and pld-linux.org (minor one)
previously.
--
Radosław Zieliński [EMAIL PROTECTED]
pgpBsYG7RDb4U.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: sabayon.spec - 2.22.0 - actually works
Patryk Zawadzki [EMAIL PROTECTED] [19-03-2008 23:53]: 2008/3/19 Radoslaw Zielinski [EMAIL PROTECTED]: [...] Use parenthesis for all virtual names would be a decent policy. whatever(utils) in this case. How does that solve the problem of finding a name for whatever? Unless you propose we use Provides: virtual(shadow) Something like that, yes. -- Radosław Zieliński [EMAIL PROTECTED] pgpNmiaRRUjXG.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: pldlinux.pl for PLD Linux purposes
Wojciech Błaszkowski [EMAIL PROTECTED] [22-03-2008 09:57]:
[EN]: I would like to that domain name serves PLD. I can set it on
ns{1,2,3}.pld-linux.org or use present DNS and set them as slaves for PLD
nameservers or set on present DNS proper PLD zone.
The point being?
--
Radosław Zieliński [EMAIL PROTECTED]
pgpju5rFWHuky.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: sabayon.spec - 2.22.0 - actually works
Jakub Bogusz [EMAIL PROTECTED] [19-03-2008 17:36]: [...] Generally, I'd be for using metapackage name - but with name other than any real package (including shadow or pwdutils). E.g. passwd-utils or shadow-utils. Use parenthesis for all virtual names would be a decent policy. whatever(utils) in this case. -- Radosław Zieliński [EMAIL PROTECTED] pgpNwj3ONXXXE.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: perl-Template-Toolkit.spec - release 4: giving up for now; ...
Andrzej Krzysztofowicz [EMAIL PROTECTED] [17-02-2008 17:41]:
radek wrote:
-%{?with_tests:%{__make} test}
+%{?with_tests:%{__make} test ||:}
If we ignore test errors so what is the point of performing the tests?
We can see the results and are able to interpret them (known / new failures).
--
Radosław Zieliński [EMAIL PROTECTED]
pgpIp1UNATwJg.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: kdelibs.spec - R: sperl (for fileshareset and filesharelist...
arvenil [EMAIL PROTECTED] [01-01-2008 18:40]: Author: arvenil Date: Tue Jan 1 18:40:26 2008 GMT Module: SPECS Tag: HEAD Log message: - R: sperl (for fileshareset and filesharelist) - release 10 [...] +Requires:sperl Nope. sperl has been separated in perl.spec for a reason -- so people don't have to have it installed. If these scripts fail badly when it's not available, update them to do that gracefully instead. Forcing installation of suid root binaries is a bad idea unless really necessary. KDE's file sharing sort of doesn't qualify. -- Radosław Zieliński [EMAIL PROTECTED] pgp1TdWSmqb3B.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: perl-DBD-SQLite.spec - release 2: use bundled sqlite (dumps...
Arkadiusz Miskiewicz [EMAIL PROTECTED] [13-01-2008 21:26]: On Sunday 13 of January 2008, radek wrote: Author: radekDate: Sun Jan 13 21:13:19 2008 GMT Module: SPECS Tag: HEAD Log message: - release 2: use bundled sqlite (dumps core *sometimes* when linked with 3.5.4) - minor cleanup Is internal sqlite modified? I don't know. It's 3.4.2. This might be useful: http://www.sqlite.org/34to35.html If not then don't hide bugs and instead trace what's wrong/bugreport it. Have you checked if it has already been reported before writing this? Why not? -- Radosław Zieliński [EMAIL PROTECTED] pgprYxgxRGQKe.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: perl-DBD-SQLite.spec - release 2: use bundled sqlite (dumps...
Radoslaw Zielinski [EMAIL PROTECTED] [13-01-2008 22:02]: Arkadiusz Miskiewicz [EMAIL PROTECTED] [13-01-2008 21:26]: On Sunday 13 of January 2008, radek wrote: Author: radekDate: Sun Jan 13 21:13:19 2008 GMT Module: SPECS Tag: HEAD Log message: - release 2: use bundled sqlite (dumps core *sometimes* when linked with 3.5.4) One interesting thing here -- first command succeeds, second one fails. No idea why. prove -bdv t/06error.t # OK echo x:\n\tprove -bdv t/06error.t moo; make -f moo x # FAIL ($PWD is ~/rpm/BUILD/DBD-SQLite-1.14/ after perl Makefile.PL make) -- Radosław Zieliński [EMAIL PROTECTED] pgpcSeE4flEnI.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: perl.spec - separated -libs; rel 9
Elan Ruusamäe [EMAIL PROTECTED] [03-12-2007 00:10]: On Monday 03 December 2007 00:48:51 Radoslaw Zielinski wrote: I don't have a --with perl build; does this actually *work* (I mean, the perl functionality, not vim itself)? Is it useful in any way? haven't tested. don't use perl in vim. need just vim. besides disk space perhaps i don't want perl interpreter in that enviroment being present. Why? BTW: $ rpm -q vim vim-7.1.154-3.i686 $ rpm -q --whatrequires perl-libs perl-base-5.8.8-12.i686 So, there seems to be no reason for this split. Or is there...? -- Radosław Zieliński [EMAIL PROTECTED] pgpwuFEcwBbz9.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: perl.spec - separated -libs; rel 9
glen [EMAIL PROTECTED] [23-01-2007 17:03]: Author: glen Date: Tue Jan 23 17:03:26 2007 GMT Module: SPECS Tag: HEAD Log message: - separated -libs; rel 9 What was the reason for this exercise? Gain, purpose? -- Radosław Zieliński [EMAIL PROTECTED] pgpBtpvEg06yg.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: perl.spec - separated -libs; rel 9
Elan Ruusamäe [EMAIL PROTECTED] [02-12-2007 22:11]:
On Sunday 02 December 2007 23:11:40 Radoslaw Zielinski wrote:
glen [EMAIL PROTECTED] [23-01-2007 17:03]:
Author: glen Date: Tue Jan 23 17:03:26 2007 GMT
Module: SPECS Tag: HEAD
Log message:
- separated -libs; rel 9
What was the reason for this exercise? Gain, purpose?
$ q vim --requires|grep perl
libperl.so.5.8.0
perl-libs
I don't have a --with perl build; does this actually *work* (I mean,
the perl functionality, not vim itself)? Is it useful in any way?
$ rpm -qlv perl-base | grep -v gz$ | awk '{xx+=$5} END {print xx}'
1302071
Is it useful on a machine, where additional 1MB of disk space is
something to be concerned with? If so, for what?
--
Radosław Zieliński [EMAIL PROTECTED]
pgpGGR1irQScZ.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: cvs-nserver.spec, cvs.spec - Conflicts instead of Obsoletes
patrys [EMAIL PROTECTED] [29-10-2007 15:37]:
[...]
Provides:cvs = %{version}
^^
-Obsoletes: cvs
+Conflicts: cvs
This won't fly.
--
Radosław Zieliński [EMAIL PROTECTED]
pgpSaOKWIxTrP.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: rpm and mono
Jeff Johnson [EMAIL PROTECTED] [15-07-2007 18:53]: [...] [...] [...] and whether rpmbuild invokes external helpers per-file or per-package that are intimately tied to [...] Would be nice if RPM could invoke perl.prov / perl.req per-package, instead of per-file, as it currently does. -- Radosław Zieliński [EMAIL PROTECTED] pgpMny5yVCTHN.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
[th][builders] access to /dev/tty*, /dev/pts -- perl-Expect
perl-Expect's tests fail while trying to access tty / pty: http://buildlogs.pld-linux.org/index.php?dist=tharch=i686ok=0id=1ffb2a57b980bf3e1ad09b22ddc74e3b http://buildlogs.pld-linux.org/index.php?dist=tharch=x86_64ok=0id=69566d6707d2de644bbcbfd1c9462363 http://buildlogs.pld-linux.org/index.php?dist=tharch=ppcok=0id=48d5eef804499b4df71045c61b47524a I assume it's builder's configuration; passes just fine on athlon and i486. Ideas? -- Radosław Zieliński [EMAIL PROTECTED] pgpXrzFUYuFB3.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: qt4.spec - adapter
Rafał Cygnarowski [EMAIL PROTECTED] [21-06-2007 10:14]: Dnia środa, 20 czerwca 2007, glen napisał: [...] %files -n QtCore-devel -f QtCore-devel.files +%defattr(644,root,root,755) ^^ This change is wrong. Why do you think so? Qt*-devel.files already contains this and it's respected. If this is done by adapter, then adapter needs to be fixed. Remove these lines, please. All %files sections should begin with %defattr; no exceptions. This cuts down the time needed to wonder if it's needed here and just missing or defined somewhere else... Consider it a policy. Benefit: less bugs, saved time. -- Radosław Zieliński [EMAIL PROTECTED] pgpm2pEKhbPZN.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: vim.spec - with python, ruby and tcl by default - rel 3 for...
Elan Ruusamäe [EMAIL PROTECTED] [18-06-2007 08:45]:
[...]
vim needs just perl-libs (at least on AC) --
$ rpm -q --qf '%-12{NAME}: %{SIZE}\n' perl-libs
perl-libs : 1146552
What's that? Why has it been separated?
1. Is there a considerable amount of applications it's enough for?
2. Is there a single one?
vim works with just perl-libs, but do the perl functions actually work -- no
idea never used language bindings.
It should *work* (like, execute something basic), but I doubt it's
usable; a single use strict requires perl-base.
--
Radosław Zieliński [EMAIL PROTECTED]
pgpjmCaYJAi5N.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: mysql-5.0.41 moved back to ready
Elan Ruusamäe [EMAIL PROTECTED] [25-05-2007 16:23]: [...] mysql select a.category_id,count(*) from album a where exists (select album_id from image where album_id=a.id) group by 1; Empty set (0.00 sec) This query makes little sense and is not ANSI SQL compliant (category_id not used in aggregate statement or GROUP BY), so both behaviours are incorrect -- it should return an error. If you want to count the number of albums in a given category which have images, that would be the proper query (exists vs join: depending on the amount of data): select a.category_id, count(*) from album a join image i on i.album_id=a.id group by a.category_id; /offtopic -- Radosław Zieliński [EMAIL PROTECTED] pgpbLqpTvhX7B.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: mysql-5.0.41 moved back to ready
Radoslaw Zielinski [EMAIL PROTECTED] [28-05-2007 12:29]: Elan Ruusamäe [EMAIL PROTECTED] [25-05-2007 16:23]: [...] mysql select a.category_id,count(*) from album a where exists (select album_id from image where album_id=a.id) group by 1; Empty set (0.00 sec) This query makes little sense and is not ANSI SQL compliant (category_id Correction: I'm just plain wrong. I didn't know about this syntax. -- Radosław Zieliński [EMAIL PROTECTED] pgpV8dSUpiBuP.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [RFC] Repository layout chan ge / Zmiana układu repo
Jan Rekorajski [EMAIL PROTECTED] [14-05-2007 00:55]:
On Sun, 13 May 2007, Radoslaw Zielinski wrote:
Patryk Zawadzki [EMAIL PROTECTED] [13-05-2007 23:09]:
On 5/13/07, Radoslaw Zielinski [EMAIL PROTECTED] wrote:
Patryk Zawadzki [EMAIL PROTECTED] [13-05-2007 21:58]:
[...]
What are the problems?
Off the top of my head:
- excessive metadata (CVS/Entries is just a few dozen bytes per file)
Disk space is cheap.
That's no reason for wasting it. Two copies + metadata in case of
SVN is over the line (one copy with SVK).
Come on, the repo will not magically grow by enormous amounts,
[...]
Now (for SPECS): 12k files.
With new layout: 12k files + 12k directories + 12k CVS/ + 3x12k CVS/*.
SVN: 12k files + 12k directories + 12k .svn/ +7x12k .svn/* + copies.
On my (laptop) hardware[1] I see a performance difference. Big enough
to see it as an issue.
[1] No, I can't build OO and large packages do take time. But usually
it's just good enough.
[...]
I'll wait for the proponents of the change to provide the `real life
issues' which would disappear. I mean, the ones which can't be solved
with bash magic.
1) files that belong to more than one package, you either have to _know_
the involved packages and keep them synchronized or you will have a mess
It's just a couple of packages, isn't it? Only relevant for SourceX,
which are fetched from DF anyway. Files stored in VCS (patches, scripts
or whatever) are (or should be) named as %{name}*.
2) orphans, we have ~900 files in SOURCES that don't belong to any
package currently
I might be guilty of forgetting to remove some of these myself... But
then, is it really an issue? If so, a daily or weekly cronjob can fix
it, can't it?
3) guesswork in case you work with more packages at once or with the
whole repo - hmm, file adfgasdfgda.patch does belong to what package?
Why would you care? It's being looked up the other way: package - *.patch.
And those were just everyday, common issues.
Honestly: I can't see these as issues. And certainly not as everyday ones.
--
Radosław Zieliński [EMAIL PROTECTED]
pgpkBJ4KWAiG8.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [RFC] Repository layout chan ge / Zmiana układu repo
Jan Rekorajski [EMAIL PROTECTED] [14-05-2007 01:05]: On Mon, 14 May 2007, Radoslaw Zielinski wrote: Jan Rekorajski [EMAIL PROTECTED] [14-05-2007 00:41]: [...] I don't think you understood, I'm not proposing VCS change, that's for the future. I'm proposing layout change to make it _possible_ to even consider a VCS change. I'm sure I did. I just see it differently: changing layout to a *worse* Why worse? To avoid making up reasons (and repeating ourselves about excessive metadata): I would find this structure more annoying. Longer paths, the need for mkdir. Sorry, but the only real problem you stated is that scripts will stop working, and that can be easily fixed. That was, as I wrote, `off the top of my head', not an analysis. Alright, a weak argument. ;-) one so it's possible to switch to a *worse* (for this purpose) VCS. Anything to back up this statement? There are more VCSs than just CVS or SVN. Widely used (in OSS world)? Come on... Everything (?) else features and focuses on distributed repositories, which we don't need. If there existed a better VCS for our needs, someone would outline the gains and we'd have switched already. -- Radosław Zieliński [EMAIL PROTECTED] pgp3DRA7fGabh.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [RFC] Repository layout chan ge / Zmiana układu repo
Jan Rekorajski [EMAIL PROTECTED] [13-05-2007 20:20]: We all know that CVS sucks, less for some (me included) and more for All version control systems suck. CVS just sucks least for this kind of repository. others. But, if we want to switch to anything else, we have to change the repository layout from flat SPECS/SOURCES to dir-per-package, because any other CMS won't handle such layout (you can imagine how would SVN repo look like - a ~milion directories, and GIT just doesn't scale - I did a test on SPECS and got a monstrosity). This clearly shows problems with *other* VC systems. There is no point in switching. It would create more problems than it'd solve. -1 FUT: -en -- Radosław Zieliński [EMAIL PROTECTED] pgpTZYxdzLaIv.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [RFC] Repository layout chan ge / Zmiana układu repo
Patryk Zawadzki [EMAIL PROTECTED] [13-05-2007 21:58]: On 5/13/07, Radoslaw Zielinski [EMAIL PROTECTED] wrote: Jan Rekorajski [EMAIL PROTECTED] [13-05-2007 20:20]: We all know that CVS sucks, less for some (me included) and more for All version control systems suck. CVS just sucks least for this kind of repository. Why? Why what? others. But, if we want to switch to anything else, we have to change the repository layout from flat SPECS/SOURCES to dir-per-package, because any other CMS won't handle such layout (you can imagine how would SVN repo look like - a ~milion directories, and GIT just doesn't scale - I did a test on SPECS and got a monstrosity). This clearly shows problems with *other* VC systems. There is no point in switching. It would create more problems than it'd solve. What are the problems? Off the top of my head: - excessive metadata (CVS/Entries is just a few dozen bytes per file) - $Log$ - existing tools / macros / aliases / one liners / whatever We have tamed CVS over the years and know how to deal with its shortcomings. The only real unsolved problem is lack of cvs mv, but this could be changed with far less work than changing VCS, if someone cared enough. The so called problems are the rare situations where you need to grep through ALL the spec files. This [...] If you know the answer (or so you think), what's the point of asking? -- Radosław Zieliński [EMAIL PROTECTED] pgpamBAuDSE29.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [RFC] Repository layout chan ge / Zmiana układu repo
wrobell [EMAIL PROTECTED] [13-05-2007 23:22]: On Sun, May 13, 2007 at 11:02:41PM +0200, Radoslaw Zielinski wrote: [...] We have tamed CVS over the years and know how to deal with its shortcomings. The only real unsolved problem is lack of cvs mv, but this could be changed with far less work than changing VCS, if someone cared enough. lack of mv... and also - off-line diff - revert (on-line/off-line) rm cvs up; you can't do much being offline anyway. - atomic commit Blah. - lack of something like svk for svn (or i am just not aware) You mean for CVS (as svk with svn Just Works)? According to svk h mi|grep cvs it's supported, but I couldn't get it to work last time I tried... That would also fix the online diff issue. anyway, it was all discussed several times, so... eot? :) Probably... -- Radosław Zieliński [EMAIL PROTECTED] pgpcODgHStRvm.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [RFC] Repository layout chan ge / Zmiana układu repo
Jan Rekorajski [EMAIL PROTECTED] [14-05-2007 00:41]: On Sun, 13 May 2007, Radoslaw Zielinski wrote: Jan Rekorajski [EMAIL PROTECTED] [13-05-2007 20:20]: [...] others. But, if we want to switch to anything else, we have to change the repository layout from flat SPECS/SOURCES to dir-per-package, because any other CMS won't handle such layout (you can imagine how would SVN repo look like - a ~milion directories, and GIT just doesn't scale - I did a test on SPECS and got a monstrosity). This clearly shows problems with *other* VC systems. There is no point in switching. It would create more problems than it'd solve. I don't think you understood, I'm not proposing VCS change, that's for the future. I'm proposing layout change to make it _possible_ to even consider a VCS change. I'm sure I did. I just see it differently: changing layout to a *worse* one so it's possible to switch to a *worse* (for this purpose) VCS. -- Radosław Zieliński [EMAIL PROTECTED] pgpt5Ha7blEwX.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: postgresql-module-plphp-nophp_test.patch - updated for 1.3.3
blues [EMAIL PROTECTED] [20-04-2007 16:15]: Author: bluesDate: Fri Apr 20 14:15:15 2007 GMT Module: SOURCES Tag: HEAD Log message: - updated for 1.3.3 [...] -# Checks for libraries. -AC_CHECK_LIB([php5], [php_module_startup],[], [have_php5=no], [$PHP_LDFLAGS]) This is pointless. Should be s/php5/php_common/. And it won't work until this is fixed: $ gcc /usr/lib/libphp_common.so 21 | grep so: /usr/lib/libphp_common.so: undefined reference to `pthread_key_create' /usr/lib/libphp_common.so: undefined reference to `pthread_getspecific' /usr/lib/libphp_common.so: undefined reference to `pthread_key_delete' /usr/lib/libphp_common.so: undefined reference to `php_register_internal_extensions' /usr/lib/libphp_common.so: undefined reference to `pthread_setspecific' -- Radosław Zieliński [EMAIL PROTECTED] pgpIdU5cV93LB.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Adding a user to CVS (apollotiger)
Patryk Zawadzki [EMAIL PROTECTED] [20-04-2007 21:12]: On 4/20/07, Joshua [EMAIL PROTECTED] wrote: +1 but i'd like to see him on this mailing list I actually just signed up for aforementioned mailing list at Aredridel's request. :) Ok then, +1 from me makes this +3, CC: cvsadmin. No, it doesn't make +3; I can only see +2 here. +1 means taking the responsibility of coaching a new developer for a period of time. Which requires being subscribed to the mailing list. -- Radosław Zieliński [EMAIL PROTECTED] pgpDF5yoMySkA.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Adding a user to CVS (apollotiger)
Przemyslaw Iskra [EMAIL PROTECTED] [20-04-2007 22:23]: On Fri, Apr 20, 2007 at 09:53:19PM +0200, Radoslaw Zielinski wrote: [...] No, it doesn't make +3; I can only see +2 here. +1 means taking the responsibility of coaching a new developer for a period of time. Which requires being subscribed to the mailing list. I beleve Aria's proposal counts as +1. True, my mistake. -- Radosław Zieliński [EMAIL PROTECTED] pgpp0ZbSlD6IN.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS (AC-branch): filesystem.spec - release 5: %ghost for /initrd...
Elan Ruusamäe [EMAIL PROTECTED] [13-03-2007 21:25]:
On Tuesday 13 March 2007, Radoslaw Zielinski wrote:
Because it's impossible to upgrade if old root (from boot time) is
mounted on /initrd. cpio fails on unpacking the *.rpm.
It has been broken for quite a while... :-/
so fix what's broken.
I have fixed what was broken. At least one part of it.
no, that's not fixing. it's workarounding problem from wrong direction.
initrd needs fixing, not filesystem.spec having workarounds.
If a package can't be upgraded (even in wrong environment), it can be
considered a problem with this package. And IMO this is the case.
anyway not being able to umount /initrd (due unmounted /initrd/dev) is
fixed in geninitrd 8142.
$ rpm -q geninitrd
geninitrd-8286-1
installing geninitrd package doesn't fix your problem.
Indeed, it doesn't fix filesystem.spec.
you need to regenerate initrd using fixed geninitrd.
No kidding...?
if you've all done that, then please show your initrd contents (while /initrd
still mounted to be sure to compare initrd used for boot):
# cat /initrd/linuxrc
#! /bin/sh
set -x
insmod /lib/modules/2.6.20-0.12/kernel/drivers/ide/ide-core.ko
insmod /lib/modules/2.6.20-0.12/kernel/drivers/ide/pci/piix.ko
insmod /lib/modules/2.6.20-0.12/kernel/drivers/ide/ide-disk.ko
insmod /lib/modules/2.6.20-0.12/kernel/fs/xfs/xfs.ko
: 'Creating /dev'
mount -o mode=0755 -t tmpfs none /dev
mknod /dev/console c 5 1
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
mkdir /dev/pts
mkdir /dev/shm
mount -t proc none /proc
mount -t sysfs none /sys
: 'Starting udev'
/sbin/udevd --daemon
kill udevd
umount /proc
umount /sys
set +x
mount -t proc none /proc
root=$(busybox awk ' /root=\/dev\// { gsub(/.*root=\/dev\//,NIL,$0); gsub(/
.*/,NIL,$0); print $0; } ' /proc/cmdline)
if [ -n $root ]; then
rootnr=$(busybox awk -v root=$root ' { if ($4 == root) { print
256*$1+$2; } } ' /proc/partitions)
if [ -n $rootnr ]; then
echo $rootnr /proc/sys/kernel/real-root-dev
fi
fi
umount /proc
set -x
--
Radosław Zieliński [EMAIL PROTECTED]
pgpvNSUN5H7CL.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS (AC-branch): filesystem.spec - release 5: %ghost for /initrd...
Uh, this reply certainly took me a while. Elan Ruusamäe [EMAIL PROTECTED] [12-02-2007 10:19]: On Monday 12 February 2007, radek wrote: why? Because it's impossible to upgrade if old root (from boot time) is mounted on /initrd. cpio fails on unpacking the *.rpm. It has been broken for quite a while... :-/ so fix what's broken. I have fixed what was broken. At least one part of it. it should not be mounted for normal system run. But it *is* mounted on three of four of my PLD systems. Which are working perfectly fine, apart from not being able to upgrade filesystem: $ LANG=C poldek -iv filesystem [...] I filesystem-2.0-6 Need to get 10.0KB of archives. Executing sudo /bin/rpm --install -vh --root / --noorder... Preparing...### [100%] 1:filesystem ### [100%] error: unpacking of archive failed on file /initrd: cpio: chown failed - Read-only file system So, you have reverted it to the broken state. Is this a ping-pong club or what? anyway not being able to umount /initrd (due unmounted /initrd/dev) is fixed in geninitrd 8142. $ rpm -q geninitrd geninitrd-8286-1 doesn't it break fresh installs as i don't think /initrd is mkdir at boot No. %ghost %dir creates it. no, it does not (go and test it) Hmm, true. I must have messed something up while testing this. Any better ideas than %ghost and mkdir in %post? -- Radosław Zieliński [EMAIL PROTECTED] pgptnQkNwdloS.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: xmltv and perl build
Elan Ruusamäe [EMAIL PROTECTED] [22-09-2006 15:11]: On Friday 22 September 2006 13:11, Radoslaw Zielinski wrote: Elan Ruusamäe [EMAIL PROTECTED] [22-09-2006 11:36]: On Friday 22 September 2006 12:31, Radoslaw Zielinski wrote: Elan Ruusamäe [EMAIL PROTECTED] [22-09-2006 00:22]: xmltv from HEAD doesn't build again, could you help me out? Sure, done. Tested in Th environment. Some %files are missing. still fails on AC, some bad BR? No, lack of policy for handling cases, when perl is distributed with a module in version newer or equal than one we have distributed separately. what about policy that we don't bundle the packages in perl-modules? IIRC, we kept (some of) them separate in perl 5.6. While preparing 5.8.0, my goals included: * allow coexistence of different perl versions (I was hoping, that some day RPM will start to handle multiple packages with the same name nicely -- silly me) * poldek -i perl installs whatever modules come with the perl tarball. Right now, both are fulfilled. I'm not too convinced if the first one is actually useful, though. Installing separate perl in /usr/local is way easier, than dealing with RPM. additional pros on that is that the base perl install gets smaller. What would you like to strip? PS I consider it to be rude: publishing e-mail without asking first. -- Radosław Zieliński [EMAIL PROTECTED] pgp7wc0YcypMV.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
[th] apache-base requires /etc/monit
apache-base requires the /etc/monit directory thanks to our new favorite rpm feature. What's the correct way to fix this? R: monit is a no-no, of course. -- Radosław Zieliński [EMAIL PROTECTED] pgpdeldtRyX3W.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [th] apache-base requires /etc/monit
Andrzej Krzysztofowicz [EMAIL PROTECTED] [23-08-2006 20:28]: havner wrote: On Wed, Aug 23, 2006 at 09:00:51PM +0200, Arkadiusz Miskiewicz wrote: Wouldn't monit-apache subpackage be better? We don't end up with tons of application specific directories in filesystem.spec. I'd prefer more or less generic dirs in one package then _tons_ of single one dir packages. The dir should still belong to monit. The apache files that are located in this dir should go to a subpackage. Or maybe put the file in monit as well? It's monit configuration after all. -- Radosław Zieliński [EMAIL PROTECTED] pgpyoBJL4pS3C.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: -DLARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 (was: unzip.spec)
Jakub Bogusz [EMAIL PROTECTED] [08-08-2006 11:46]:
On Tue, Aug 08, 2006 at 11:20:42AM +0200, Radoslaw Zielinski wrote:
Szymon Siwek [EMAIL PROTECTED] [08-08-2006 06:30]:
[...]
- CF=%{rpmcflags} -I. -Wall -DASM_CRC \
+ CF=%{rpmcflags} -I. -Wall -DASM_CRC -DLARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 \
What would be the correct way to do this globally in Th?
Changing %optflags, or rather some gcc header file?
Should we do it?
No.
This is per-app thing.
LFS-ready apps already define proper flags (usually through autoconf
macro).
Well, unzip doesn't (assuming the patch is correct).
As I understand [1] and [2], it's also a problem of mixing applications
/ libraries compiled in 32 and 64 mode.
Others should be reviewed individually. Defining anything won't convert
ints to 64-bit in bad-written code.
But would it hurt to have 64 bit off_t by default?
[1] http://ac-archive.sourceforge.net/largefile/summary.html 404, copy:
http://web.archive.org/web/*/http://ac-archive.sourceforge.net/largefile/summary.html
[2] http://freshmeat.net/articles/view/709/
--
Radosław Zieliński [EMAIL PROTECTED]
pgpJndc93f8k8.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: [STBR] AC
855resolution.spec:AC-branch 915resolution.spec:AC-branch Second one tested and working. Both required to get X working properly on these GPUs. rt2x00.spec:AC-branch Builds, loads, detects card; I haven't had a chance to check if it works yet. -- Radosław Zieliński [EMAIL PROTECTED] pgp5XFmZ0yUta.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: Content of /usr/share/ssl/ca-bundle.crt
Elan Ruusamäe [EMAIL PROTECTED] [20-07-2006 20:28]: On Monday 20 March 2006 11:53, Radoslaw Zielinski wrote: a) Just install it in /usr/share/ssl/, marking as %config(noreplace). b) Create a directory in /etc [2], symlink /usr/share/ssl to it. c) Whatever. For now (and for Ac), I'd chose a). any progress? No complaints in 24 hours = I have commited option a). Revision 1.146.2.1 2006/03/21 19:53:13 radek - release 2: added certificates from Mozilla - moved ca-bundle.crt to main package (rev 1.75 didn't) $ rpm -qf /usr/share/ssl/ca-bundle.crt openssl-0.9.7i-2 -- Radosław Zieliński [EMAIL PROTECTED] pgpuXtbJFNdMk.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: perl-HTML-Mason.spec - up to 1.33
arekm [EMAIL PROTECTED] [06-06-2006 11:43]:
[...]
+%{perl_vendorlib}/Bundle/HTML/Mason.pm
[...]
+%{_mandir}/man3/Bundle*
We do not package Bundle::*.
--
Radosław Zieliński [EMAIL PROTECTED]
pgp1XF7le6ouO.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SOURCES: service_generator.sh - use == instead of = for tests
Jakub Bogusz [EMAIL PROTECTED] [21-06-2006 11:32]: On Sun, Jun 11, 2006 at 07:02:34PM +0200, radek wrote: Author: radekDate: Sun Jun 11 17:02:34 2006 GMT Module: SOURCES Tag: HEAD Log message: - use == instead of = for tests Why? = is standard test operator. [...] -if [ $action = stop ]; then +if [ $action == stop ]; then The commit message should be different, I wanted to fix this: $ cvs up -r1.5 service_generator.sh P service_generator.sh $ sh service_generator.sh foo /dev/null service_generator.sh[16]: [: stop: unexpected operator/operand I wasn't sure if = is preferred to ==; as I find the former ambigous, I changed it too. POSIX indeed defines only = while describing test, but section 1.7.2 lists == (Concepts Derived from the ISO C Standard), so I guess it can also be considered conformant. [ I've replied directly by mistake, sending again here. ] -- Radosław Zieliński [EMAIL PROTECTED] pgp3oHSI55CVx.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: broken grep.
Paweł Sikora [EMAIL PROTECTED] [06-06-2006 20:01]: `grep -F -w -f patterns text` shoud return: I can't see a point in using -F with -f. Without -F it works as expected. -- Radosław Zieliński [EMAIL PROTECTED] ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: jakarta-log4j.spec - version 1.2.13 - commented out BR/R: j...
Jan Rekorajski [EMAIL PROTECTED] [21-05-2006 13:04]: On Sun, 21 May 2006, Jacek Konieczny wrote: On Sun, May 21, 2006 at 12:48:27PM +0200, radek wrote: Author: radekDate: Sun May 21 10:48:27 2006 GMT Module: SPECS Tag: HEAD Log message: - version 1.2.13 - commented out BR/R: javamail, jms, jmx: builds without these (I'm not sure if it's a proper change, though) I think it is not -- that will probably result in very limited log4j package. That should be built with all the requirements and CLASSPATH prepared adequately. The best is to look into jpackage how they did that. In progress. Exactly, without those R we will get incomplete package. I didn't know about java-gnu-mail... so, javamail is not an issue. Will it be incomplete as useless or as with limited functionality? javamail is provided via our gnu-java-mail. I am not sure what provides jms and jmx (it may be sun-java or something elese). jms.spec:http://java.sun.com/products/jms/docs.html jmx.spec:http://java.sun.com/products/JavaManagement/ These two are not distributable, so if we restore BR, we won't be able to distribute log4j... -- Radosław Zieliński [EMAIL PROTECTED] pgpljxQX2teqK.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: TEST build ERRORS: perl.spec
Andrzej Krzysztofowicz [EMAIL PROTECTED] [04-04-2006 23:41]: Tomasz Wittner wrote: On Mon 3. April 2006 16:26, Radoslaw Zielinski wrote: PLD ac-athlon builder [EMAIL PROTECTED] [03-04-2006 14:58]: perl.spec (HEAD): FAILED [...] lib/ExtUtils/t/Constant...FAILED at test 25 [...] I'd need access to builder to debug it, on my Ac/athlon it works fine. Maybe it fails because athlon builder works on amd64 (AFAIK)? All x86 ac-* builders work on the same machine at the moment. Investigation in progress. BTW, what's that (causes t/op/stat.t failures sometimes)? [EMAIL PROTECTED] ~]$ for i in `seq 3`; do ls -lL /dev|grep -q stdin; echo $?; done|grep 1|wc ls: /dev/fd: No such file or directory ls: /dev/stderr: No such file or directory ls: /dev/stdin: No such file or directory ls: /dev/stdout: No such file or directory ls: /dev/fd: No such file or directory ls: /dev/stderr: No such file or directory ls: /dev/stdin: No such file or directory ls: /dev/stdout: No such file or directory ls: /dev/fd: No such file or directory ls: /dev/stderr: No such file or directory ls: /dev/stdin: No such file or directory ls: /dev/stdout: No such file or directory 3 3 6 [EMAIL PROTECTED] ~]$ for i in `seq 3`; do ls -l /dev|grep -q stdin; echo $?; done|grep 1|wc 0 0 0 -- Radosław Zieliński [EMAIL PROTECTED] pgpVDYlLIBovR.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: TEST build ERRORS: perl.spec
PLD ac-athlon builder [EMAIL PROTECTED] [03-04-2006 14:58]: perl.spec (HEAD): FAILED [...] lib/ExtUtils/t/Constant...FAILED at test 25 [...] I'd need access to builder to debug it, on my Ac/athlon it works fine. Test is performed around line 237, defining $keep_files=1 at line 25 will be helpful. -- Radosław Zieliński [EMAIL PROTECTED] pgpbvsk2tPYOj.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Content of /usr/share/ssl/ca-bundle.crt
Introduction /usr/share/ssl/ca-bundle.crt is used by OpenSSL as a database of root certificates. If the certificate for current OpenSSL-served session is not signed by one of the certificates found there, application should display a big fat warning. Security Users who ignore the big fat warning mentioned above, are apt for a man in the middle attack. [1] Using SSL without checking certificates is mostly pointless and gives false sense of safety. Actual condition Our ca-bundle.crt contains only Unizeto certificates. Pointless, should either be empty or contain more. Problem We are, of course, due to state that our users should care about who they trust on their own. Being a perfectly consistent policy (and an easy to maintain one ;-), it's not very user friendly. IMO, user- -unfriendly security issues usually get ignored. Proposed solution Use certificates from Mozilla. Possible implementations Use ca-bundle.pl script from apache1-mod_ssl (only in sources, we don't distribute it) to fetch certificates from Mozilla CVS and create ca-bundle.crt. Then: a) Just install it in /usr/share/ssl/, marking as %config(noreplace). b) Create a directory in /etc [2], symlink /usr/share/ssl to it. c) Whatever. For now (and for Ac), I'd chose a). Alternate solution Create a (init?) script to use the contents of /usr/share/certs and maybe some other directory (for user's own certificates). Unizeto According to [3], there were concerns about distributing their certificates. I'd leave it as is and add them to ca-bundle.pl's output. [1] I know a small ISP who did (maybe still does) that to force own transparent SMTP relay. ISP's CA certificate was (is) installed in user's system by a technician during network installation. Clients never complained... [2] http://blogs.gurulabs.com/dax/archives/2005/05/warning_changes.html [3] http://7thguard.net/news.php?id=1637 -- Radosław Zieliński [EMAIL PROTECTED] pgp1UpVzbROB5.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: TEST build ERRORS: rt2400.spec
PLD ac-sparc builder [EMAIL PROTECTED] [14-03-2006 17:33]:
rt2400.spec (HEAD): FAILED
[...]
CC [M] /home/users/builder/rpm/BUILD/rt2400-1.2.2-b3/Module/rtmp_info.o
/home/users/builder/rpm/BUILD/rt2400-1.2.2-b3/Module/rtmp_info.c: In function
`RT2400_ioctl':
/home/users/builder/rpm/BUILD/rt2400-1.2.2-b3/Module/rtmp_info.c:1434: error:
/home/users/builder/rpm/BUILD/rt2400-1.2.2-b3/Module/rtmp_info.c:1434: error:
this is the insn:
(insn 10626 10621 10681 523 0x70c78390 (set (reg:DI 3136)
(mem/s/j:DI (plus:SI (reg/v/f:SI 27 %i3 [111])
(reg:SI 7 %g7 [3130])) [0
variable.WlanCounters.FCSErrorCount+0 S8 A64])) 46 {*movdi_insn_sp32}
(insn_list 10621 (nil))
(expr_list:REG_EQUIV (mem/s/j:DI (plus:SI (reg/v/f:SI 27 %i3 [111])
(reg:SI 7 %g7 [3130])) [0
variable.WlanCounters.FCSErrorCount+0 S8 A64])
(nil)))
/home/users/builder/rpm/BUILD/rt2400-1.2.2-b3/Module/rtmp_info.c:1434:
confused by earlier errors, bailing out
make[2]: ***
[/home/users/builder/rpm/BUILD/rt2400-1.2.2-b3/Module/rtmp_info.o] Error 1
Compiler bug? Any solutions, or ExclusiveArch?
--
Radosław Zieliński [EMAIL PROTECTED]
pgps3lZ9hFR8e.pgp
Description: PGP signature
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: apache1.spec - unify Provides = http with apache.spec
Elan Ruusamäe [EMAIL PROTECTED] [13-11-2005 12:48]: On Saturday 12 November 2005 19:44, Radoslaw Zielinski wrote: [...] What's the point of Provides: httpd anyway? Most specs use the webserver virtual dependency (R: webserver, and R: webserver = apache if apache only). IIRC that was unified; right now: $ egrep -r '^Requires:[[:blank:]]+httpd' SPECS SPECS/sqmgrlog.spec:Requires: httpd SPECS/squid.spec:Requires: httpd SPECS/w3cam.spec:Requires: httpd SPECS/wwwcount.spec:Requires: httpd SPECS/wordpress.spec:Requires: httpd well. lets decide that R: httpd should be dropped and R: webserver = apache should be used instead. without version. as version is pointless. Agreed. but in real life R: webserver = apache is also pointless, as if package really is both apache compatible then it needs apache = 1.3.33-3, because earlier apache1 didn't have conf.d like support. Well, IMHO better this than nothing. Adding some kind of complicated P:/R: would make an overkill -- this kind of problem can be solved with poldek --upgrade-dist. Conflicts: apache1 1.3.33-3 in appropriate specs should do, but I don't think it's really needed. -- Radosław Zieliński [EMAIL PROTECTED] pgpQiN79n2o9p.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: apache1.spec - unify Provides = http with apache.spec
Elan Ruusamäe [EMAIL PROTECTED] [13-11-2005 17:07]: On Sunday 13 November 2005 15:42, Radoslaw Zielinski wrote: but in real life R: webserver = apache is also pointless, as if package really is both apache compatible then it needs apache = 1.3.33-3, because earlier apache1 didn't have conf.d like support. Well, IMHO better this than nothing. Adding some kind of complicated P:/R: would make an overkill -- this kind of problem can be solved with poldek --upgrade-dist. R: apache = 1.3.33-3 is no more complicated than R: webserver = apache, just use BuildRequires.txt as guide (or appropriate template.spec files) IIRC I have removed P: apache from apache1.spec... IMO providing an existant package name (and using it as virtual dependency) is a *bad thing*. R: webserver = apache should be used when needed. but the upgrade dist will not help with your offer, because poldek/rpm build install older depending on requires lines. and without proper requires it could happen that package is installed (upgraded) earlier than apache that provides the functionality it needs. this leads to mess which average user is not capable of resolving manually. i don't think it's worth of that. Conflicts: apache1 1.3.33-3 in appropriate specs should do, but I don't think it's really needed. if it's *requirement* then there should be requires line :) R: webserver = apache C: apache1 ... to sum this up, i think 'Provides: webserver = apache' has no value, and only 'Provides: webserver' should be used, otherwise use Requires: apache = apache doesn't hurt, and I've added it for a reason (something required apache, but both versions were OK). R: apache, meaning apache1 or apache2, should be shot dead and buried. Of course, if an application requires *any* HTTP server, just R: webserver should be used. Not that many of our specs are prepared for it, but that's another story. -- Radosław Zieliński [EMAIL PROTECTED] pgpowQPygKC9F.pgp Description: PGP signature ___ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
Re: SPECS: python-xmlrpc.spec - I can be python-aware: arch-independen...
Paweł Sakowski [EMAIL PROTECTED] [06-07-2005 15:46]:
On Wed, 2005-07-06 at 13:53 +0200, Radoslaw Zielinski wrote:
and *.py{c,o} shouldn't differ between archs. They do.
They don't.
The one I've checked before writing that mail did (python-ipaddr). ;-]
Read my lips: if they do differ, that's only in the timestamp field.
diff shows such files as different, but closer inspection proves that
there are no functional differences. Further: the serialized bytecode is
strictly speaking identical.
Fine.
So, usually, they don't differ, but not always. Question: do we allow
noarch packages, containing files, which differ between architectures?
IIRC: no, but I may be wrong.
It's normal that different builders produce non-identical rpm files out
of noarch specs. It's most common for %{BUILDTIME} and files' mtime to
vary. With py[co] contents it's the same situation.
For RPMS, it's normal, but it's not normal to produce different *files*
in noarch packages. The situation we're talking about is the only one
I know.
%{BUILDTIME} (or other RPM header's fields) and ctime/mtime are
meaningless in this context.
The important thing is that a packages built on various builders are
functionally equivalent, that is, can be freely interchanged between all
archs.
Agreed. But IIRC someone (havner?) wanted all noarch packages to have
identical content.
I don't really care, just want to know if the packages containing *.py[co]
can be noarch, in case I'd touch the Python mess again. From ankry's
No. I understand they can't.
--
Radosław Zieliński [EMAIL PROTECTED]
___
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
