[Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
On Thu, 17 Jul 2003, Stefan van der Eijk wrote:
* Thu Jul 17 2003 Stefan van der Eijk [EMAIL PROTECTED] 2.0.5-3mdk
- add missing .so symlink in /lib
- Why put a .so symlink in /lib?
- Why use /lib since it was necessary to use /%{_lib} and fixed that way?
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 18 July 2003 09:53, Gwenole Beauchesne wrote:
On Thu, 17 Jul 2003, Stefan van der Eijk wrote:
* Thu Jul 17 2003 Stefan van der Eijk [EMAIL PROTECTED] 2.0.5-3mdk
- add missing .so symlink in /lib
- Why put a .so symlink in /lib?
- Why use /lib since it was necessary to use /%{_lib} and fixed that way?
gwenole, I sent you a mail about dmapi earlier with some changes, also a mail
about glibc on sparc, but I got no response, are you ignoring mails not going
to cooker?
(please respond:)
- --
Regards,
Per Øyvind Karlsen
Sintrax Solutions
http://www.sintrax.net - +47 41681061
-
GPG Key: http://sintrax.net/~hawkeye/key.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/F6qRv8F7V9JOSuURAnb5AJ9TJJqXr1IXDR0f4O98l+5TXYbsBQCfRJwd
+iuc56460nUblKP2QaZ8PUc=
=zlJd
-END PGP SIGNATURE-
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
On Fri, 18 Jul 2003, Stefan van der Eijk wrote:
Otherwise we'll have a dead symlink in /usr/lib, which points to the .so
symlink in /lib.
Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so
symlinks. And I insist on %{_lib} %{_libdir}. I had fixed that for lib64
but this magically vanished.
Any objections to updating xfsdump to 2.2.3?
I don't know, kernel people will answer. And I suppose Vincent already
issued an update to 2.2.3.
BuildRequires:libattr-devel
BuildRequires:libdm-devel
BuildRequires:libext2fs-devel
BuildRequires:libxfs-devel
Always BuildRequires: thing-devel forms only, not libthing-devel.
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
On Fri, 18 Jul 2003, Per Øyvind Karlsen wrote: gwenole, I sent you a mail about dmapi earlier with some changes, also a mail about glibc on sparc, but I got no response, are you ignoring mails not going to cooker? Latest mails from you to my mbox are: 520 May 23 Per Ã^Xyvind Karls (5634) netpbm +601 May 15 Per Ã^Xyvind Karls (2242) OpenOffice.org nb/nn + 3014 Sep 20 Per Øyvind Karlsen (4646) opps, I forgot + 3015 Sep 20 Per Øyvind Karlsen (2114) OpenOffice.org building [...] i.e. I can't reply to something and I don't get. Please mail again. ;-)
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
Gwenole Beauchesne wrote:
On Thu, 17 Jul 2003, Stefan van der Eijk wrote:
* Thu Jul 17 2003 Stefan van der Eijk [EMAIL PROTECTED] 2.0.5-3mdk
- add missing .so symlink in /lib
- Why put a .so symlink in /lib?
- Why use /lib since it was necessary to use /%{_lib} and fixed that way?
Otherwise we'll have a dead symlink in /usr/lib, which points to the .so
symlink in /lib.
Funny thing is, it is installed in the build dir, but I guess symlinks
are not detected as unpackaged files.
And at the moment xfsdump doesn't compile, and this fixes that:
http://eijk.homelinux.org/build/cooker/i586/problem/xfsdump-2.0.3-1mdk
/usr/bin/libtool --mode=link gcc -o xfsdump arch_xlate.o cldmgr.o content_common.o dlog.o drive.o drive_scsitape.o drive_simple.o drive_minrmt.o fs.o getdents.o global.o lock.o main.o mlog.o openutil.o qlock.o path.o ring.o stream.o util.o sproc.o inv_api.o inv_core.o inv_files.o inv_fstab.o inv_idx.o inv_mgr.o inv_stobj.o content.o hsmapi.o inomap.o var.o /usr/lib/libuuid.a /usr/lib/libhandle.la /usr/lib/libattr.la /usr/lib/libdm.la ../librmt/librmt.la
mkdir .libs
gcc -o xfsdump arch_xlate.o cldmgr.o content_common.o dlog.o drive.o drive_scsitape.o drive_simple.o drive_minrmt.o fs.o getdents.o global.o lock.o main.o mlog.o openutil.o qlock.o path.o ring.o stream.o util.o sproc.o inv_api.o inv_core.o inv_files.o inv_fstab.o inv_idx.o inv_mgr.o inv_stobj.o content.o hsmapi.o inomap.o var.o /usr/lib/libuuid.a /lib/libhandle.so /lib/libattr.so /lib/libdm.so ../librmt/.libs/librmt.al
gcc: /lib/libdm.so: No such file or directory
make[1]: *** [xfsdump] Error 1
make: *** [default] Error 2
error: Bad exit status from /home/slbd/tmp/rpm-tmp.16807 (%build)
Any objections to updating xfsdump to 2.2.3?
# diff xfsdump.spec.orig xfsdump.spec
2c2
%define version 2.0.3
---
%define version 2.2.3
16c16,20
BuildRequires: libattr-devel libext2fs-devel libxfs-devel libdm-devel
---
BuildRequires:libattr-devel
BuildRequires:libdm-devel
BuildRequires:libext2fs-devel
BuildRequires:libxfs-devel
BuildRequires:ncurses-devel
46a51,53
# Remove unpackaged files (se)
rm -rf %{buildroot}/%{_docdir}/%{name}
53c60
/sbin/*
---
%{_bindir}/*
57a65,70
* Thu Jul 18 2003 Stefan van der Eijk [EMAIL PROTECTED] 2.2.3-1mdk
- 2.2.3
- remove unpackaged files
- some files in %%{_bindir}/*
- no more files in /sbin/*
regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
Otherwise we'll have a dead symlink in /usr/lib, which points to the .so
symlink in /lib.
Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so
symlinks.
Fine with me, as long as xfsdump will build.
And I insist on %{_lib} %{_libdir}. I had fixed that for lib64
but this magically vanished.
Yes, I agree. Sorry about that.
Any objections to updating xfsdump to 2.2.3?
I don't know, kernel people will answer. And I suppose Vincent already
issued an update to 2.2.3.
BuildRequires:libattr-devel
BuildRequires:libdm-devel
BuildRequires:libext2fs-devel
BuildRequires:libxfs-devel
Always BuildRequires: thing-devel forms only, not libthing-devel.
Sure, but:
$ urpmq attr-devel
no package named attr-devel
$ urpmq dm-devel
no package named dm-devel
$ urpmq ext2fs-devel
no package named ext2fs-devel
$ urpmq xfs-devel
no package named xfs-devel
I understand where this is coming from, and I agree that it needs to be
done. But I don't think that it needs to be brought up in this
discussion. I'm getting the feeling that somebody is looking for
something to pick on...
I suggest:
* rpmlint is adjusted to warn about ( enforce?) this on uploads;
* a document is written describing these changes so this can be
finalized into some sort of guideline / policy. So people can
read it through, understand how it works and how it should be
implemented in the packages;
For instance: I don't understand how the mklib stuff works and how I
should fix the rpmlint errors I get on the topic.
regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
Otherwise we'll have a dead symlink in /usr/lib, which points to the .so
symlink in /lib.
Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so
symlinks.
Fine with me, as long as xfsdump will build.
And I insist on %{_lib} %{_libdir}. I had fixed that for lib64
but this magically vanished.
Yes, I agree. Sorry about that.
Any objections to updating xfsdump to 2.2.3?
I don't know, kernel people will answer. And I suppose Vincent already
issued an update to 2.2.3.
BuildRequires:libattr-devel
BuildRequires:libdm-devel
BuildRequires:libext2fs-devel
BuildRequires:libxfs-devel
Always BuildRequires: thing-devel forms only, not libthing-devel.
Sure, but:
$ urpmq attr-devel
no package named attr-devel
$ urpmq dm-devel
no package named dm-devel
$ urpmq ext2fs-devel
no package named ext2fs-devel
$ urpmq xfs-devel
no package named xfs-devel
I understand where this is coming from, and I agree that it needs to be
done. But I don't think that it needs to be brought up in this
discussion. I'm getting the feeling that somebody is looking for
something to pick on...
I suggest:
* rpmlint is adjusted to warn about ( enforce?) this on uploads;
* a document is written describing these changes so this can be
finalized into some sort of guideline / policy. So people can
read it through, understand how it works and how it should be
implemented in the packages;
For instance: I don't understand how the mklib stuff works and how I
should fix the rpmlint errors I get on the topic.
regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 18 July 2003 11:11, Gwenole Beauchesne wrote: On Fri, 18 Jul 2003, Per Øyvind Karlsen wrote: gwenole, I sent you a mail about dmapi earlier with some changes, also a mail about glibc on sparc, but I got no response, are you ignoring mails not going to cooker? Latest mails from you to my mbox are: 520 May 23 Per Ã^Xyvind Karls (5634) netpbm +601 May 15 Per Ã^Xyvind Karls (2242) OpenOffice.org nb/nn + 3014 Sep 20 Per Øyvind Karlsen (4646) opps, I forgot + 3015 Sep 20 Per Øyvind Karlsen (2114) OpenOffice.org building [...] i.e. I can't reply to something and I don't get. Please mail again. ;-) I've forwarded the mails to your adress again, please confirm if you've received them or not - -- Regards, Per Øyvind Karlsen Sintrax Solutions http://www.sintrax.net - +47 41681061 - GPG Key: http://sintrax.net/~hawkeye/key.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/F+tpv8F7V9JOSuURAm4TAJ4lnGiRuPLjQLYQPKIzhEjRtZ30mwCgxfqm l8JDzsvClJkH+EzM5BqsjEw= =CAOo -END PGP SIGNATURE-
[Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
stefan == Stefan van der Eijk [EMAIL PROTECTED] writes:
Otherwise we'll have a dead symlink in /usr/lib, which points to
the .so symlink in /lib.
Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so
symlinks.
stefan Fine with me, as long as xfsdump will build.
And I insist on %{_lib} %{_libdir}. I had fixed that for lib64 but
this magically vanished.
stefan Yes, I agree. Sorry about that.
Any objections to updating xfsdump to 2.2.3?
I don't know, kernel people will answer. And I suppose Vincent
already issued an update to 2.2.3.
BuildRequires:libattr-devel
BuildRequires:libdm-devel
BuildRequires:libext2fs-devel
BuildRequires:libxfs-devel
Always BuildRequires: thing-devel forms only, not libthing-devel.
stefan Sure, but:
ok, will fix in teh same batch.
/me decides to spend the rest of the evening recompiling all his
packages.
/me thinks that this is optimist.
stefan $ urpmq attr-devel
stefan no package named attr-devel
stefan $ urpmq dm-devel
stefan no package named dm-devel
stefan $ urpmq ext2fs-devel
stefan no package named ext2fs-devel
stefan $ urpmq xfs-devel
stefan no package named xfs-devel
stefan I understand where this is coming from, and I agree that it needs to
stefan be done. But I don't think that it needs to be brought up in this
stefan discussion. I'm getting the feeling that somebody is looking for
stefan something to pick on...
stefan I suggest:
stefan * rpmlint is adjusted to warn about ( enforce?) this on uploads;
stefan * a document is written describing these changes so this can be
stefan finalized into some sort of guideline / policy. So people can
stefan read it through, understand how it works and how it should be
stefan implemented in the packages;
There is a document:
http://people.mandrakesoft.com/~gc/somewhere
stefan For instance: I don't understand how the mklib stuff works and how I
stefan should fix the rpmlint errors I get on the topic.
Just fixed it for dmapi, it is trivial:
%define lib_name_orig %mklibname dm
instead of
%define lib_name_orig libdm
Rule of thumb:
- when you have a problem of that kind, look for a package maintained
by gb about how it is done there :p
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
[Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
gwenole == Gwenole Beauchesne [EMAIL PROTECTED] writes:
gwenole On Fri, 18 Jul 2003, Stefan van der Eijk wrote:
Otherwise we'll have a dead symlink in /usr/lib, which points to the .so
symlink in /lib.
gwenole Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so
gwenole symlinks. And I insist on %{_lib} %{_libdir}. I had fixed that for lib64
gwenole but this magically vanished.
Any objections to updating xfsdump to 2.2.3?
No, I was waiting fro the symlink isue to be fixed. I had the update
of the rest of the things.
gwenole I don't know, kernel people will answer. And I suppose Vincent already
gwenole issued an update to 2.2.3.
BuildRequires:libattr-devel
BuildRequires:libdm-devel
BuildRequires:libext2fs-devel
BuildRequires:libxfs-devel
gwenole Always BuildRequires: thing-devel forms only, not libthing-devel.
ok, changing that.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
[...] Always BuildRequires: thing-devel forms only, not libthing-devel. stefan Sure, but: ok, will fix in teh same batch. /me decides to spend the rest of the evening recompiling all his packages. Just wondering, is there going to be a scheme to retire some of the Obseletes / Provides pairs that are floating arround. Some packages are packed with them, perhaps some system / procedure can be throught of to manage this. Or to give a sign when some of them can be removed. /me thinks that this is optimist. :-) stefan $ urpmq attr-devel stefan no package named attr-devel stefan $ urpmq dm-devel stefan no package named dm-devel stefan $ urpmq ext2fs-devel stefan no package named ext2fs-devel stefan $ urpmq xfs-devel stefan no package named xfs-devel stefan I understand where this is coming from, and I agree that it needs to stefan be done. But I don't think that it needs to be brought up in this stefan discussion. I'm getting the feeling that somebody is looking for stefan something to pick on... stefan I suggest: stefan * rpmlint is adjusted to warn about ( enforce?) this on uploads; stefan * a document is written describing these changes so this can be stefan finalized into some sort of guideline / policy. So people can stefan read it through, understand how it works and how it should be stefan implemented in the packages; There is a document: http://people.mandrakesoft.com/~gc/somewhere Did you look in the TeamRoom(tm) yet? stefan For instance: I don't understand how the mklib stuff works and how I stefan should fix the rpmlint errors I get on the topic. Just fixed it for dmapi, it is trivial: %define lib_name_orig %mklibname dm instead of %define lib_name_orig libdm OK... This explains how it was done for this package. I guess this can be applied to any package complaining about missing mklib? Rule of thumb: - when you have a problem of that kind, look for a package maintained by gb about how it is done there :p uhm... you are kidding, right? We need to do better than this... at least write a page on the wiki about it... or make a link on the wiki to where the document is. regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan van der Eijk wrote:
[...]
Just fixed it for dmapi, it is trivial:
%define lib_name_orig %mklibname dm
instead of
%define lib_name_orig libdm
Except that it should be specifying major (and possibly minor) too:
%define libname %mklibname %name %major
is the usual method, assuming you have %name and %major defined before
this. Whether you want to use -d and -s to save you typing a few letters
(evel and tatic) is up to you, except for the case below.
But I don't think mklibname works on older releases, plus it can mess
with --with options, so if you want packages to build everywhere, you
may prefer:
%define libname %{lib}%{name}%{major}
which really does the same thing (mostly, ie you have to type some extra
stuff for the devel packages).
OK... This explains how it was done for this package. I guess this can
be applied to any package complaining about missing mklib?
Rule of thumb:
- when you have a problem of that kind, look for a package maintained
by gb about how it is done there :p
uhm... you are kidding, right?
Trawling other spec files is a good way to learn some tricks, but only
because we haven't got a better document. But things could be done
better, for instance we would be using %{?_with}-style macros in a
similar way to the way the Gentoo guys use their use flags.
We need to do better than this... at least write a page on the wiki
about it... or make a link on the wiki to where the document is.
Thierry had it on his todo list to update the howto, but if Thierry
agrees, it may be more efficient to dump the current mdk-rpm-howto into
the wiki?
I would also like to know what to do with packages that supply multiple
libraries of different names ...
Regards,
Buchan
- --
|--Another happy Mandrake Club member--|
Buchan MilneMechanical Engineer, Network Manager
Cellphone * Work+27 82 472 2231 * +27 21 8828820x202
Stellenbosch Automotive Engineering http://www.cae.co.za
GPG Key http://ranger.dnsalias.com/bgmilne.asc
1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/GCTqrJK6UGDSBKcRAuJTAKC21eyJBg23EQ4b/itAJpJrg/ZLngCgjHcE
AWnRGxrr7vzE2WqnsIlSi1o=
=770c
-END PGP SIGNATURE-
**
Please click on http://www.cae.co.za/disclaimer.htm to read our
e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy.
**
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
On Fri Jul 18, 2003 at 11:05:59AM +0200, Gwenole Beauchesne wrote:
Otherwise we'll have a dead symlink in /usr/lib, which points to the .so
symlink in /lib.
Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so
symlinks. And I insist on %{_lib} %{_libdir}. I had fixed that for lib64
but this magically vanished.
Any objections to updating xfsdump to 2.2.3?
I don't know, kernel people will answer. And I suppose Vincent already
issued an update to 2.2.3.
None whatsoever, and xfsprogs needs updating as well. I was having problems
with the symlink revolving stuff and couldn't get it fixed so I wasn't able
to upgrade xfsprogs and xfsdump in cooker like I had wanted to... dmapi was
holding everything up. If it's fixed now, then please update xfsprogs and
xfsdump as well.
--
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
lynx -source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}
pgp0.pgp
Description: PGP signature
Re: [Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk
[...]
Just fixed it for dmapi, it is trivial:
%define lib_name_orig %mklibname dm
instead of
%define lib_name_orig libdm
Except that it should be specifying major (and possibly minor) too:
%define libname %mklibname %name %major
is the usual method, assuming you have %name and %major defined before
this. Whether you want to use -d and -s to save you typing a few letters
(evel and tatic) is up to you, except for the case below.
But I don't think mklibname works on older releases, plus it can mess
with --with options, so if you want packages to build everywhere, you
may prefer:
%define libname %{lib}%{name}%{major}
which really does the same thing (mostly, ie you have to type some extra
stuff for the devel packages).
OK... This explains how it was done for this package. I guess this can
be applied to any package complaining about missing mklib?
Rule of thumb:
- when you have a problem of that kind, look for a package maintained
by gb about how it is done there :p
uhm... you are kidding, right?
Trawling other spec files is a good way to learn some tricks,
True. But if everybody goes ahead and does that -- quite a waste of
resources. .spec files are also scattered with exceptions, people might
take an exception and use it as their standard, and that might not
be the way it should be done. /me thinks one document containing the
prefered way to do things and also describing why certain things are
done that way (-- some reading material for newby packagers).
but only because we haven't got a better document.
YET
But things could be done
better, for instance we would be using %{?_with}-style macros in a
similar way to the way the Gentoo guys use their use flags.
And there are probably many more improvements to be considered...
We need to do better than this... at least write a page on the wiki
about it... or make a link on the wiki to where the document is.
Thierry had it on his todo list to update the howto, but if Thierry
agrees, it may be more efficient to dump the current mdk-rpm-howto into
the wiki?
I got started on it, but decided to ask the list first.
The conclusion of the discusion was that it is a good idea, but we (I
think Dams was also involved in the thread) weren't sure how it should
be done.
- One big document, or split up per chapter?
- Naming of chapters in WiKi style or not?
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
