Re: Multiarch question
Michael Wild them...@users.sourceforge.net writes:
Hi all
I have a question concerning multiarch [1,2]. From what I read it is
conceivable to have something like this on a system:
/usr/{lib,include}/i386-linux-gnu
/usr/{lib,include}/x86_64-linux-gnu
/usr/{lib,include}/x86_64-kfreebsd-gnu
/usr/{lib,include}/sparc64-linux-gnu
Particularly, the case where both linux and kfreebsd directories are
present is of interest. How would one tell gcc to use the foreign kernel?
The background of this question is that at the moment Clang is
completely broken w.r.t. multiarch and I'm looking into fixing it.
Thanks for any hints
Michael
i386-linux-gnu-gcc automatically uses /usr/{lib,include}/i386-linux-gnu.
x86_64-linux-gnu-gcc automatically uses /usr/{lib,include}/x86_64-linux-gnu.
and so on...
What you are talking about here is cross-compiling. The special case of
gcc -m32/-m64 on some archs might even go away and just use cross
compilers for that as well.
Note: Don't use the GNU triplet for the multiarch dir. Use
dpkg-architecture -qDEB_HOST_MULTIARCH.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762ocx2hl.fsf@frosties.localnet
Re: /usr/lib64 or /usr/lib
David Bremner brem...@debian.org writes: On Thu, 09 Jun 2011 15:41:34 -0700, Russ Allbery r...@debian.org wrote: 9.1.1 point 2: The requirement for amd64 to use /lib64 for 64 bit binaries is removed. Yeah, that is the point that confused me. For me, removing the requirement is not the same as forbidding. Due to implementation issues (below) you MUST NOT ship any files in /lib64 or /usr/lib64/ in the package. Also note that /usr/lib64 is just a symlink to /usr/lib on Debian systems. So that makes it a bit academic, at the moment. cheers, d Except for how dpkg behaves. If your package has a file in /usr/lib64/ and gets installed then dpkg records that that directory belongs to your package. Then the next time libc6 gets updated dpkg will try to unpack the /usr/lib64 symlink and fail because you can not replace a directory of another package with a symlink. You have made it impossible to update libc6. MfG Goswin PS: You can (and should if you have plugins) configure/build your package to use /lib64 and /usr/lib64 as long as you ship it as /lib and /usr/lib in the deb. PPS: Using multiarch dirs would be even better for plugins. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y618vnlj.fsf@frosties.localnet
Re: /usr/lib64 or /usr/lib
On 2011-06-11 09:22 +0200, Goswin von Brederlow wrote: Except for how dpkg behaves. If your package has a file in /usr/lib64/ and gets installed then dpkg records that that directory belongs to your package. Then the next time libc6 gets updated dpkg will try to unpack the /usr/lib64 symlink and fail because you can not replace a directory of another package with a symlink. Er no, this is not how dpkg behaves. It never converts symlinks to directories or vice versa, so the actual outcome is¹ that your file gets actually installed into /usr/lib through the symlink. This means that if another package starts shipping a file with the same name in /usr/lib, dpkg will not notice the file conflict which is bad. It's much worse if you ship files in /lib64, because if your package is installed into a chroot and unpacked by the host dpkg with the --root=… option, the files end up in the host system². Sven ¹ Unless your package is unpacked before libc6 while bootstrapping a system, but that's highly unlikely. ² http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514702 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mxhorcyx@turtle.gmx.de
Re: RFS: john (updated package)
Le Tue, Jun 07, 2011 at 10:10:17PM -0500, Ruben Molina a écrit : El mar, 07-06-2011 a las 22:37 +0900, Charles Plessy escribió: Le Tue, Jun 07, 2011 at 08:24:30AM -0500, Ruben Molina a écrit : as I sponsored you in the past I can have a look at your package, but why don't you use the VCS where it was stored anymore ? It would help to review your changes. Did the address change ? Dear Charles, Thank you very much! As the package is no longer maintained by a team, I just stopped using the VCS some time ago. Of course, I will update it if this helps you to review the changes, but I'm having some issues to access via git+ssh just now. So, this can take a while. Dear Ruben, it is your choice to drop the VCS, but consider that later you may want co-maintainers, so keeping come continuity there may help. Also, having a serie of thematic commits instead of a large debdiff helps to review the package for upload. By the way, why don't you try to become DM ? About the update of john, I see that you drop a large number of patches, and it is quite difficult for me to evaluate this. In particular, what blocks me is the removal of the patches that fixed FTBFS on mips. Unfortunately, the only porter box listed on db.debian.org, gabrielli, is unreachable as I write these lines. But still, using the buildds for testing builds is better to be avoided since failures consume their admin's time. Can you ask on the debian-mips mailing list if somebody can test the build of your package that is on mentors.debian.org ? Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110611085334.ga26...@merveille.plessy.net
Re: Re: Specifying %{variable} in control file for use in post inst?
Hi, I have a compiled kernel module for the specific kernel version and I want to create a deb package for it. I want to run depmod -aeF /boot/System.map-$kvers $kvers in postinst script. How can I define kvers in control file and access it in postinst script? I am using cons to compile the kernel module and I can't use make, as my source tree don't have any make files. Thanks, Amit Raj Gupta
Re: RFS: creepy (third Try)
Hi, On Fri, Jun 10, 2011 at 11:27:23PM -0500, Daniel Echeverry wrote: -(snip)- Now using upstream tarball Please Checkout: http://mentors.debian.net/debian/pool/main/c/creepy/creepy_0.1.93-2.dsc uploaded using the orig.tar.gz that's in the archive. Just as a reminder: you must not change *.orig.tar.gz's unless you change upstream versions. The Debian archive will not allow that in! Thanks for your work! -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: cl-launch, cl-asdf (updated packages)
Hi! Faré fah...@gmail.com writes: - dget http://mentors.debian.net/debian/pool/main/c/cl-launch/cl-launch_3.011-1.dsc - dget http://mentors.debian.net/debian/pool/main/c/cl-asdf/cl-asdf_2.016-1.dsc Both uploaded! Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? pgpngfcWHvJtY.pgp Description: PGP signature
Re: RFS: creepy (third Try)
Hi, 2011/6/11 Kilian Krause kil...@debian.org Hi, On Fri, Jun 10, 2011 at 11:27:23PM -0500, Daniel Echeverry wrote: -(snip)- Now using upstream tarball Please Checkout: http://mentors.debian.net/debian/pool/main/c/creepy/creepy_0.1.93-2.dsc uploaded using the orig.tar.gz that's in the archive. Just as a reminder: you must not change *.orig.tar.gz's unless you change upstream versions. The Debian archive will not allow that in! Thanks for your work! ok, I didn't know it that, thank you so much again :) !! -- Epsilon http://www.rinconinformatico.net http://www.fitnessdeportes.com http://www.dragonjar.org Linux user: #477840 Debian user
RFS: micro-evtd (updated package)
Dear mentors and ARM porters, I am looking for a sponsor for the new version 3.4-1 of my package micro-evtd. It builds these binary packages: micro-evtd - Linkstation Pro/Kurobox Pro special features support micro-evtd-udeb - Linkstation Pro/Kurobox Pro special features support - udeb (udeb) The package appears to be lintian clean. The upload would fix these bugs: 534931, 5153353 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/micro-evtd - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/micro-evtd/micro-evtd_3.4-1.dsc The previous uploads of this package were reviewed and sponsored by Martin Michlmayr. Unfortunately he does not have the time to review this upload, so I'm searching for a new sponsor. Thanks, Ryan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4df3c0fe.4000...@nardis.ca
Re: /usr/lib64 or /usr/lib
Sven Joachim svenj...@gmx.de writes: Er no, this is not how dpkg behaves. It never converts symlinks to directories or vice versa, so the actual outcome is¹ that your file gets actually installed into /usr/lib through the symlink. This means that if another package starts shipping a file with the same name in /usr/lib, dpkg will not notice the file conflict which is bad. It's much worse if you ship files in /lib64, because if your package is installed into a chroot and unpacked by the host dpkg with the --root=… option, the files end up in the host system². So we should absolutely forbid this in Policy instead of just removing the requirement. I'll open a bug against debian-policy for this. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y618kse6@windlord.stanford.edu
Re: RFS: john (updated package)
El sáb, 11-06-2011 a las 17:54 +0900, Charles Plessy escribió: Le Tue, Jun 07, 2011 at 10:10:17PM -0500, Ruben Molina a écrit : El mar, 07-06-2011 a las 22:37 +0900, Charles Plessy escribió: Le Tue, Jun 07, 2011 at 08:24:30AM -0500, Ruben Molina a écrit : as I sponsored you in the past I can have a look at your package, but why don't you use the VCS where it was stored anymore ? It would help to review your As the package is no longer maintained by a team, I just stopped using the VCS some time ago. Of course, I will update it if this helps you to review the changes, but it is your choice to drop the VCS, but consider that later you may want co-maintainers, so keeping come continuity there may help. Also, having a serie of thematic commits instead of a large debdiff helps to review the package for upload. Sure, especially in fully reworked packages like this one. I will try to update the VCS, I belive I just need to get familiar with it a little more. By the way, why don't you try to become DM ? I will probably do it in the next weeks. About the update of john, I see that you drop a large number of patches, and it is quite difficult for me to evaluate this. In particular, what blocks me is the removal of the patches that fixed FTBFS on mips. Unfortunately, the only porter box listed on db.debian.org, gabrielli, is unreachable as I write these lines. But still, using the buildds for testing builds is better to be avoided since failures consume their admin's time. I assume your are talking about 05-mipsel.patch which defines a couple of new targets in Makefile: linux-mips and linux-mipsel, and provides some *.h files for them. Well, there is no rule in debian/rules using those targets, therefore mips and mipsel are build using a generic target (Please take a look at the latest available build logs, we are using generic). If it is not really needed, why 1.6-40.2 FTBFS and 1.6-40.3 builds fine? For the 'generic' target some benchmarks are used in order to select the fastest algorithms at build time. * For the remaining compilation targets, benchmark is not needed, because we already know the most convenient algorithm for the arch. * In 1.6-40.* the only compilation targets used were i386 and alpha. * There was a bug report (#420980) for 1.6-40.1 about a FTBFS (it is not clear if all the supported archs were at FTBFS or just ones). * A new revision (1.6-40.2) was released replacing CLK_TCK by CLOCKS_PER_SEC * This new revision still FTBFS in all but i386 and alpha (the bug was located in the benchmark routine, so, optimized targets were not affected) * A new revision (1.6-40.3) was released reverting into 1.6-40.1 and including two different patches: * The first one uses a different approximation to solve #420980 (Ubuntu's sysconf-based patch). * The second one is the mips* one which defines a new target for mips* but does not uses it at debian/rules * At this stage the FTBFS was solved, but, as the mips* targets were never used in the debian/rules, I believe they were not really neeed, and the bug was really solved by the first patch * Finally, upstream rewrites parts of the benchmark function in 1.7.x. * AFAICT the mips.diff was never used. Even if it was useful in order to solve the bug in mips*, a more generic approach was needed for the remaining targets, and it was indeed provided by the sysconf-based patch. Moreover, the changelog for 1.7.2-1 list some few patches (mips* not included) and then says: all other old patches have been kept (but not applied at build-time) for future reference. * And then, in 1.7.3.1-1 it is (accidentally?) re-applied as 05-mipsel.patch I do believe it is not needed at all, but I can be wrong. Can you ask on the debian-mips mailing list if somebody can test the build of your package that is on mentors.debian.org ? Of course. I will ask them. Thank you very much! Best regards, Ruben signature.asc Description: This is a digitally signed message part
