Re: How to get all dependent source packages
sha liu sandyle...@gmail.com writes: 2009/7/20 Goswin von Brederlow goswin-...@web.de sha liu sandyle...@gmail.com writes: Hi everyone, Is there any easy method to get all the *source* packages which are the build dependency of one package? What I want to do is building dpkg from source on a CLFS[0] system. So I have to get all the dpkg's dependency source packages and the dependency of dependency and so on... I look into auto-apt, apt-get builddep. Both of them install the binary packages to fulfill the dependency, not downloading the source packages. It's crazy to download all dependent source packages of dpkg, right? Any suggestion is welcomed! [0][[http://trac.cross-lfs.org/]] For those don't know clfs, just think a CLFS system as a minimal linux system without debianization. -- Best, Sha Liu It is crazy. Or at least in general you can not build a source package without having a full build chroot with binaries already. Just the sources for a minimla build chroot are 800MB already and, last I checked, which is a few years back, include latex and X. Adding all the sources for the Build-Depends of those probably doubles the size again. Just build (c)debootstrap manually or use the static one and create a build chroot from debs. Hi Goswin. debootstrap will just install the binaries. However, what I want is building binaries on my own. The reason I want to do this is I want to port Debian to different arch(MIPS III and loongson 2F), considering there're only mips and mipsel port in Debian archive now. I thought the normal mips(el) port runs just fine on the Longson. But if you must start from scratch then you have a long road ahead of you. You need to build a lot of stuff and a lot of that manually till you have everything needed for a minimal build chroot. Often you will want to build only parts of a source, e.g. skip all the docs because you 1) don't need them and 2) don't have latex yet. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The wider implications of debhelper/dbus breakage
Philipp Kern tr...@philkern.de writes: On 2009-07-20, Stéphane Glondu st...@glondu.net wrote: For example, each OCaml transition involve rebuilding a lot of packages (about 139), with 6 levels of dependencies. So if some build takes 2 days or more (for the current transition, on some builds, it was even more than a week) to be uploaded, it means that transition will last at least 12 days (for the current transition, all packages were rebuilt/uploaded/installed after 21 days). But most of the builds are successful (and fast). If packages were automatically uploaded on success, a dependency level would be cleared at each dinstall run, meaning the whole recompilation would take less than 2 days. Haskell is even more intense. But it's not exactly true because we are autobuilding from accepted, so you do not need to wait for dinstall runs to complete but can get it done much quicker. Kind regards, Philipp Kern The long wait is the signing, not the dinstall run. Even without accepted dinstall runs 4 times a day now. But I have to say I'm totaly against unsigned uploads. The buildds are insecure enough as it is. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to get all dependent source packages
Harald Braumann ha...@unheit.net writes: On Tue, 21 Jul 2009 01:42:44 +0800 sha liu sandyle...@gmail.com wrote: 2009/7/20 Goswin von Brederlow goswin-...@web.de sha liu sandyle...@gmail.com writes: Hi everyone, Is there any easy method to get all the *source* packages which are the build dependency of one package? What I want to do is building dpkg from source on a CLFS[0] system. So I have to get all the dpkg's dependency source packages and the dependency of dependency and so on... I look into auto-apt, apt-get builddep. Both of them install the binary packages to fulfill the dependency, not downloading the source packages. It's crazy to download all dependent source packages of dpkg, right? Any suggestion is welcomed! [0][[http://trac.cross-lfs.org/]] For those don't know clfs, just think a CLFS system as a minimal linux system without debianization. -- Best, Sha Liu It is crazy. Or at least in general you can not build a source package without having a full build chroot with binaries already. Just the sources for a minimla build chroot are 800MB already and, last I checked, which is a few years back, include latex and X. Adding all the sources for the Build-Depends of those probably doubles the size again. Just build (c)debootstrap manually or use the static one and create a build chroot from debs. Hi Goswin. debootstrap will just install the binaries. However, what I want is building binaries on my own. The reason I want to do this is I want to port Debian to different arch(MIPS III and loongson 2F), considering there're only mips and mipsel port in Debian archive now. Use pbuilder. It creates a chroot, downloads and installs all required packages and then builds your source package. Btw., the base chroot is about 80MB (gzipped). How big it gets when building depends on the dependencies, but I never had to download 800MB (if I understood correctly, you don't want to build the whole distribution, just a single package, rigth?) The debs might be just 80MB but the sources for those debs are 800MB. Cheers, harry MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Miles Bader mi...@gnu.org writes: Goswin von Brederlow goswin-...@web.de writes: And why should there be. The package it totally usable and functional as designed. Does it properly support aptitude / synaptic / etc yet? [The whole print a message on stdout telling the user he'd better do something else thing was dodgy beyond belief, and clearly is not acceptable for testing.] -Miles Sure the support isn't perfect yet. But it is useable. It is also purely a temporary inconvenience. The BTS has a patch for libapt that will allow better integration of ia32-apt-get (removes the need for any wrapper) and allows full functionality for all libapt using package managers. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Micha Lenk mi...@lenk.info writes: Hi, Goswin von Brederlow wrote: Am Sonntag 05 Juli 2009 schrieb Goswin von Brederlow: The conversion system is an ugly hack. Sure. [...] [...] The package it totally usable and functional as designed. Don't you feel like contradicting yourself? Something can be a hack and still work. Imho it is the least ugly thing to ties 32bit support over till actual multiarch happens. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Running a 32bits on debian amd64 system
Mike Hommey m...@glandium.org writes: On Mon, Jul 13, 2009 at 04:29:34PM +0200, Mathieu Malaterre wrote: 'lo I am reading: http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292205 But everytime I chroot into my 32bits system, part of my system still sees me as my user: $ sudo chroot ./Debian32Chroot # id uid=0(root) gid=0(root) groups=0(root) # echo $HOME /home/mathieu What should I do so that I either: 1. Completely be root or 2. Completely be user 'mathieu' 3. Read sudo's manual page, option -H. Mike apt-get install schroot RTFM MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Running a 32bits on debian amd64 system
Mathieu Malaterre mathieu.malate...@gmail.com writes: On Mon, Jul 13, 2009 at 5:20 PM, Goswin von Brederlowgoswin-...@web.de wrote: apt-get install schroot RTFM Did you *actually* read it yourself ? *hust, hust* I actually wrote it. At least a small part of it. I'd suggest you reread it: http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292437 There is no mention to chroot -H option whatsoever Indeed, I did not say anything about chroot -H at all. Verry observant of you. You do not need to be rude when I explicitly quote the actual doc I am reading, which obviously should not recommend the use of chroot And if you would just read the next chapter to your above url you would see that it does mention and explain schroot. I'm not being root. I'm just telling you that you should go, as the HowTo puts it, the easier way. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Micha Lenk mi...@lenk.info writes: Hi, Hans-J. Ullrich schrieb: Am Sonntag 05 Juli 2009 schrieb Goswin von Brederlow: The conversion system is an ugly hack. Sure. [...] Despite whatever the people say, I like the new package. And I like the idea behind it. And if it does not work at the beginning, who cares? It is unstable. To those who are mourning: Du you know the meaning of the word unstable? It means, there is no guarantee, things will work! It means, things must not be, as they were since many years. It means, things can crash. Except packages uploaded to unstable will automatically migrate to testing, the next stable release. So, if you already know in advance that the package is not suitable for any faraway release, you (the maintainer) should either file an RC bug against the 'unstable' version in order to keep the package out of testing or should have uploaded it to experimental. As of now I see no such RC bug... Regards Micha And why should there be. The package it totally usable and functional as designed. The only reason for it not to be in squeeze would be if multiarch support will be in squeeze. Which I doubt will actually happen. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Bernd Zeimetz be...@bzed.de writes: Goswin von Brederlow wrote: Bernd Zeimetz be...@bzed.de writes: Goswin von Brederlow wrote: and it has numerous RC bugs. Lets see: http://packages.qa.debian.org/i/ia32-libs-tools.html RC bugs: 1 There were 6 bugs when I looked at the page before writing my mail, guess you've merged/downgraded/... the others.I should have added another one - breaking apt Most importantly fixed in an upload or assigned to the package that did the actual breaking. I got a number of non-bugs caused by libc6-i386 changing lib32 from link to directory too: Like lib32nss-mdns being uninstallable because libc6-i386 conflicts with it. completely while removing the ia32 packages is not nice. Remember, I asked you on irc? It leaves empty files somewhere in /var/lib/apt which breaks apt pretty much... Fixed in version 19: * Remove empty Packages files on remove so update fetches fresh ones. So another fixed in an upload one. :)) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Pierre Habouzit madco...@madism.org writes: On Sat, Jul 04, 2009 at 11:30:12PM +0200, Goswin von Brederlow wrote: Yannick yannick.roeh...@free.fr writes: Goswin von Brederlow wrote: And hey, the good reason was diverting the package management tools is unacceptable. But, no, we have to do insults instead of arguing. Alas, despite the diversion of the package management tools, I find ia32- apt-get pretty useful. For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). With ia32-apt-get, I could install the 32bit version of my GTK theme engine so that Firefox can look good. Is there a design problem in converting 32bits libraries to ia32-* packages or the sole problem is the diversion of apt-get and co? There where 3 minor bug reports about an ia32-* package not working right. Out of an estimate of 160-200 packages people use. I think that is pretty good. All 3 bugs where fix in a subsequent upload and currently there are no reported missconversions. On the other hand ~45 bugs about missconversion or missing packages in the old ia32-libs where closed (and will have to be reopened now). So I don't believe there is a design problem there. That part works just fine. But the diversions had people totaly in outrage. So much so that I believe they didn't even look past that at all. You absolutely don't get it do you ? Your conversion system is an ugly hack, something completely horrible, that is meant to break in horrible ways, has no forward upgrate path to a multiarch work, and so on. The conversion system is an ugly hack. Sure. But it is the same ugly hack 32bit support has always done, for over 5 years. The only change is when the conversion is done, i.e. moved from the buildd to the users system. By moving it there only those things the user needs/wants need converting and all the user needs/wants can be converted. That is the big advantage of ia32-apt-get over ia32-libs. If you find the conversion unacceptable then the only option for you is to request 32bit support on amd64/ia64 is removed till multiarch. The upgrade path to multiarch is for the multiarch i386 deb to Conflicts/Replaces: package that contains the same files. Which means ia32-libs or ia32-libs-gtk for the old system or ia32-package for the ia32-apt-get one. And again with ia32-apt-get there is a huge advantage. As packages convert to multiarch they can be droped in ia32-apt-get on a case by case basis and replaced by the multiarch one. Meaning users don't have to wait for and update 200 packages in a single step. If you really mean to provide something like ia32-apt-get, what you ought to do is to: - help the user create and maintain a proper 32bits chroot; Way to complex and fragile with the millions of possible configurations of users systems. - let ia32-apt-get or whatever it's called be a forward to running apt-get inside that chroot; - find a way to let the user run commands from that chroot seamlessly. Impossible to make that work for everyone/everything. Any solution will be a special case solution and only support some configurations. That would be totally acceptable, and probably an improvement over the current situation. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Roger Leigh rle...@codelibre.net writes: On Sun, Jul 05, 2009 at 03:07:58PM +0200, Stefano Zacchiroli wrote: On Sun, Jul 05, 2009 at 01:26:23PM +0200, Tollef Fog Heen wrote: ]] Yannick | For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 | Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript | engine). With ia32-apt-get, I could install the 32bit version of my | GTK theme engine so that Firefox can look good. You could just use a chroot. It's not that hard. Oh come on, this is really a non-argument. Here we are trying to build a system that can be used by random users, not developers (like probably all of the people reading this thread) with half dozen entries in their schroot.conf. The fact that schroot was primarily written for developers does not make it any less useful for ordinary users. The current version has features such as /etc/schroot/chroot.d which are intended to allow other programs or packages to drop chroot definitions in there. This was done with the intent that someone could write a simple script to create a chroot, drop an automatically generated configuration in there, and it will Just Workâ¢. The existing setup will by default set up /home, /tmp etc. as on the host system, so for most users, it will appear completely transparent. If you look at the sbuild-createchroot script in sbuild, which is a wrapper around debootstrap to set up a buildd chroot, you'll see that it does just this. While I don't personally have the time or inclination to write a user-centric script, such a script could very easily be written to allow such use. TBH, users can just use the existing script, with perhaps some additions to install what they need. As I see it, there are two major hurdles: 1) Initial creation of the chroot. As above, I think a simple script to integrate with the existing tools would work just fine here. Which must handle all possible user configurations for mail, sound, printing, 2) An easy way to run programs inside the chroot. This depends upon exactly what you want to do. Wrapper scripts or shell aliases do a good job for existing users; automatically generated desktop menu files for specific applications would also work. Which then can't generaly send mail, play sound nicely (mix with the non-chroot sound), print documents, ... And most unsovably: You can not start 64bit programs from inside the 32bit chroot again, have them start 32bit, 64, 32, 64, 32, ... How many levels bind mounts do you want to do? While I agree that chroots do appear more technical and fiddly to set up, the reality is that we now have the means to set them up in a reliable and automated fashion, and this will give the user a more robust environment than a monolithic library package set from a security POV, as well as giving them access to the /entire/ archive rather than a restricted subset, making it rather more useful. While multiarch should solve this problem, chroots offer rather more functionality and reliability at the present time, with a (rather small) hurdle to set up initially. Not in a way that is suitable for general desktop applications. And hey, here is this existing way of doing all this so that none of these problems arise: ia32-apt-get. It also is not monolithic, nor a security problem and also gives access to the full archive. Initially it was too much of it even. Regards, Roger MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Tollef Fog Heen tfh...@err.no writes: ]] Stefano Zacchiroli | On Sun, Jul 05, 2009 at 01:26:23PM +0200, Tollef Fog Heen wrote: | ]] Yannick | | | For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 | | Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript | | engine). With ia32-apt-get, I could install the 32bit version of my | | GTK theme engine so that Firefox can look good. | | You could just use a chroot. It's not that hard. | | Oh come on, this is really a non-argument. Here we are trying to build | a system that can be used by random users, not developers (like | probably all of the people reading this thread) with half dozen | entries in their schroot.conf. No, I don't think so. Coming up with random maybe-somewhat-working solutions to cross-installing packages will only take a proper solution take more time to get implemented, since people will be less interested in fixing the problem once their pet problem goes away. More than oh say 5 years? Sorry, but that train has long gone. Maybe ia32-libs did that. But it already did it. | Not arguing about the merits of the specific implementation of | ia32-apt-get, the approach had the advantage that a, say, synaptic | user can use it. A chroot does not enjoy that good property. unless it broke apt completely, requiring more hand-holding than constructing a chroot, you mean? Which was a bug, which for most people it didn't, which needed a one time intervention to install and configure it, which it can't even do anymore since it stoped diverting apt. The ia32-apt-get design actualy is so as to remove all the hand-holding ia32-libs needs. That is the part that is plain unmaintainable in ia32-libs. And yes, multiarch would be better but it is not here NOW and people want 32bit NOW. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Steve Langasek vor...@debian.org writes: On Sun, Jul 05, 2009 at 12:20:08PM +0200, Goswin von Brederlow wrote: The upgrade path to multiarch is for the multiarch i386 deb to Conflicts/Replaces: package that contains the same files. Which means ia32-libs or ia32-libs-gtk for the old system or ia32-package for the ia32-apt-get one. If this means ia32-apt-get is installing files to the multiarch paths, then this is a problem. You're making more work for the implementers of multiarch by requiring them to take into account this ia32-apt-get kludge. There are a lot more things in those packages than *.so files. That is what the Replaces is needed for. The Conflicts on the other hand is needed so only one version of the library is installed on the system. Otherwise you will get the wrong version and things randomly break as Depends/Breaks/Conflicts won't catch right. This already holds for the old ia32-libs and ia32-libs-gtk and has nothing to do with ia32-apt-get or installing to multiarch paths. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Roger Leigh rle...@codelibre.net writes: On Sun, Jul 05, 2009 at 11:36:31PM +0200, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: As I see it, there are two major hurdles: 1) Initial creation of the chroot. As above, I think a simple script to integrate with the existing tools would work just fine here. Which must handle all possible user configurations for mail, sound, printing, I'm not sure I agree here. All possible configurations is a rather impossible goal for any system. The creator of any package would need to decide what to support by default. It can use the d-i tasks just like a normal installation would, but the user will ultimately have the power to configure it as they see fit. That isn't what I ment. Or at least I think you misunderstood. If the user has configured his sound outside the chroot to for example use a network sound daemon and play on another host then inside the chroot the sound should do the same. Or when sound is used outside the chroot by e.g. kopete to beep when a new message comes in then sound should still work for a 32bit flash inside the chroot. And so on. There are a number of things that should be passed from the chroot to the real system and each has tons of different possibilities for the user to configure them. Makeing them work out of the box inside the chroot is shear impossible. And if the solution doesn't work out of the box but needs lengthly manual configuration and tinkering then that isn't a solution. Although I use amd64, I have yet to want to install any 32bit software, so I'm not entirely sure what the use case is for it. If we're talking about specific programs such as proprietary binary- only software and browser plugins etc., then we really only need the specific software and its dependencies in there. I really don't see the need for an entire functional desktop environment inside the chroot, for example. Some further clarification is needed here. It doesn't need an entire functional desktop environment, it just should be entirely functioning. Having a 32bit browser and flash plugin in a chroot is of little use if you don't have sound while kopete is running outside the chroot. 2) An easy way to run programs inside the chroot. This depends upon exactly what you want to do. Wrapper scripts or shell aliases do a good job for existing users; automatically generated desktop menu files for specific applications would also work. Which then can't generaly send mail, play sound nicely (mix with the non-chroot sound), print documents, ... These tasks just require the necessary client libraries and/or programs to talk to the server. In the case of the sound, the device nodes are shared with the host system, as is SYSV and POSIX SHM. For server AF_LOCAL sockets, we can bind mount the sockets in there as well. Yes, you can. It just means do this, and that and that other thing. And then the user uninstalls sound system A and installs sound system B and suddenly the old bind mount is inefective since it mounts the wrong directory. And most unsovably: You can not start 64bit programs from inside the 32bit chroot again, have them start 32bit, 64, 32, 64, 32, ... How many levels bind mounts do you want to do? Well, from a kernel POV, you can certainly use personality(2) to switch the execdomain back to PER_LINUX from PER_LINUX32. You are correct that starting 64bit programs on the host from inside the chroot is not possible. The isolation of the filesystem from the host is, of course, the defining feature of a chroot environment. If we are running specific programs inside only, is this a problem in practice? How would you write a frontend so that it ensures any program the 32bit applications might want to start are available? Like cups for printing. You pretty quickly come to the conclusion that you need to install every binary in both 64bit and 32bit to be sure. It's certainly possible to install schroot inside the chroot and then chroot back into a virtual host system, but I do admit that's rather gross! While I agree that chroots do appear more technical and fiddly to set up, the reality is that we now have the means to set them up in a reliable and automated fashion, and this will give the user a more robust environment than a monolithic library package set from a security POV, as well as giving them access to the /entire/ archive rather than a restricted subset, making it rather more useful. While multiarch should solve this problem, chroots offer rather more functionality and reliability at the present time, with a (rather small) hurdle to set up initially. Not in a way that is suitable for general desktop applications. And hey, here is this existing way of doing all this so that none of these problems arise: ia32-apt-get. It also is not monolithic, nor a security problem and also gives access to the full archive
Re: ia32-libs{-tools}, multiarch, squeeze
Bernd Zeimetz be...@bzed.de writes: Goswin von Brederlow wrote: and it has numerous RC bugs. Lets see: http://packages.qa.debian.org/i/ia32-libs-tools.html RC bugs: 1 There were 6 bugs when I looked at the page before writing my mail, guess you've merged/downgraded/... the others.I should have added another one - breaking apt Most importantly fixed in an upload or assigned to the package that did the actual breaking. I got a number of non-bugs caused by libc6-i386 changing lib32 from link to directory too: Like lib32nss-mdns being uninstallable because libc6-i386 conflicts with it. completely while removing the ia32 packages is not nice. Pray tell, what breaks? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Josselin Mouette j...@debian.org writes: Le vendredi 03 juillet 2009 à 14:59 +0200, Goswin von Brederlow a écrit : Do you *really* want to have more reasons? I would settle for one good one. :) OK, letâs try one that you can understand. Try picturing a bridge. ia32-libs-tools is trying to cross the bridge, but there is Ganneff standing on the bridge wearing full armor, saying âNone shall passâ. And ia32-libs-tools is not wearing Excalibur. More acruate there is this angry mob with torches and pitchforks that chaces ia32-libs-tools back after Ganneff did let it pass. And hey, the good reason was diverting the package management tools is unacceptable. But, no, we have to do insults instead of arguing. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Yannick yannick.roeh...@free.fr writes: Goswin von Brederlow wrote: And hey, the good reason was diverting the package management tools is unacceptable. But, no, we have to do insults instead of arguing. Alas, despite the diversion of the package management tools, I find ia32- apt-get pretty useful. For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). With ia32-apt-get, I could install the 32bit version of my GTK theme engine so that Firefox can look good. Is there a design problem in converting 32bits libraries to ia32-* packages or the sole problem is the diversion of apt-get and co? There where 3 minor bug reports about an ia32-* package not working right. Out of an estimate of 160-200 packages people use. I think that is pretty good. All 3 bugs where fix in a subsequent upload and currently there are no reported missconversions. On the other hand ~45 bugs about missconversion or missing packages in the old ia32-libs where closed (and will have to be reopened now). So I don't believe there is a design problem there. That part works just fine. But the diversions had people totaly in outrage. So much so that I believe they didn't even look past that at all. If there's no design flaw, wouldn't ia32-archive be the correct path? I mean a system to install converted packages which is set apart the package management system (until the actual package installation of course)? I thought so. But people will have to live with no 32bit support or the old ia32-libs monster when Mark uploads it again as the default. Yannick MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted ia32-libs-tools 22 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 02 Jul 2009 07:44:14 +0200 Source: ia32-libs-tools Binary: ia32-libs-tools ia32-archive ia32-apt-get Architecture: source all amd64 Version: 22 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Description: ia32-apt-get - Apt-get, aptitude and dpkg wrapper for on-the-fly conversion ia32-archive - Create a local archive of converted i386 debs for amd64 and ia64 ia32-libs-tools - Tools for converting i386 debs for amd64 and ia64 Closes: 535349 535473 Changes: ia32-libs-tools (22) unstable; urgency=low . * Drop ia32-libs and ia32-libs-gtk by popular demand. * Always use absolute paths in 'cd' in case CDPATH is set (Closes: #535349). * Add apt.conf sniplet and use apt-config instead of hardcoded paths (Closes: #535473). * dpkg-deb: Use fakeroot when available and when called as user. * ia32-archive/bin/apt-update: Fix issues with epochs. * ia32-archive/conf/sources.filter: Update package list. * ia32-libs-tools/packages.list: Update package list. * Remove diversions and use ia32-* commands instead. Checksums-Sha1: 92e5c630a5e61df46a14d113fd07b143e44950c0 996 ia32-libs-tools_22.dsc d128464a8c4d7db28f4b1153c47732651db442a7 33617 ia32-libs-tools_22.tar.gz ae66a7b29b6ca4ca175f97dab14f2c8d4678045b 10924 ia32-archive_22_all.deb 9d197da361ae655be194d3405e80f5339403c32f 17798 ia32-apt-get_22_all.deb 18756f37c6fc0e6dd832873e117f3dd6a2d0ee52 45306 ia32-libs-tools_22_amd64.deb Checksums-Sha256: 4795fb6fd54209ffd749d0c4d9b8fc171542aae4538c6fd0a6d0069d4c59d40a 996 ia32-libs-tools_22.dsc d2ce8d98f9ba58fe29b90f00d67fd06c33c1f6c32d507d202c708c7237c83f3b 33617 ia32-libs-tools_22.tar.gz 1c5d9800b5d9f3d13ecd7d007ec50d19f6383edc175e35ff13f5cfc138ab0f03 10924 ia32-archive_22_all.deb 22a43d09e1e9fca0cd65eb4e48c5db27e64789cfe36707f8ae8ab8540656c418 17798 ia32-apt-get_22_all.deb 232a432e714721a70ebb0afbce329c4e27e18782ed0b5b81a095936070529a07 45306 ia32-libs-tools_22_amd64.deb Files: e950c352bfaeecd5dfd0794a86f10959 996 devel extra ia32-libs-tools_22.dsc 2e496a1b03ed695fcaaa8e9db8e8958c 33617 devel extra ia32-libs-tools_22.tar.gz c43acf23280e88d834c4bf5c65454ff1 10924 devel extra ia32-archive_22_all.deb e920aa7b617e6fbbff196492d2eca1ab 17798 devel extra ia32-apt-get_22_all.deb 25511e5cdf989fd52fed9ec08cb615e0 45306 devel extra ia32-libs-tools_22_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQCVAwUBSk7wqYkABLrCbuiRAQIPjgQAvruu/1YSLPFak6DK0piBZSLt7eJXcg3U /Ps4sqb3tPAK5usWhsrcw7m4Pkkq/ikzhIEePrtZtqIdNcbFee4KFUG6w09QNNFb WzlRmh6YtQ73j18Z3jPI+VTm8U2vxGojFPJGscvwbm44jYoazmLFhEEeR0b+bMAI B0+DVrxrRkQ= =I4M7 -END PGP SIGNATURE- Accepted: ia32-apt-get_22_all.deb to pool/main/i/ia32-libs-tools/ia32-apt-get_22_all.deb ia32-archive_22_all.deb to pool/main/i/ia32-libs-tools/ia32-archive_22_all.deb ia32-libs-tools_22.dsc to pool/main/i/ia32-libs-tools/ia32-libs-tools_22.dsc ia32-libs-tools_22.tar.gz to pool/main/i/ia32-libs-tools/ia32-libs-tools_22.tar.gz ia32-libs-tools_22_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs-tools_22_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Steve Langasek vor...@debian.org writes: On Fri, Jul 03, 2009 at 01:18:14AM +0200, Goswin von Brederlow wrote: There is only one thing that DAK might want to adapt to. For most multiarch architectures there is a definite main architecture that most things should be in and then some corner cases where different architetcure might be prefered or required. Usualy because 32bit mode has smaller code and is faster than 64bit mode but sometimes the larger addresss space of 64bit mode is required. So there might be a need to introduce partial architectures for ppc64, mips64, mips64el, sparc64 that only carry a small subset of Debian. The change would be in policy to allow architecture that are partial and maybe some code to reject unwanted packages from those architectures. + s390x I would encourage people interested in these architectures to work on developing such a policy, building on top of the current multiarch spec. This isn't critical-path for delivering an initial multiarch implementation for squeeze, but I see no reason that it couldn't be worked on in parallel. Last I heart s390 planed to drop 31bit support and go fully 64bit. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: CDPATH and shell scripts
Mike Hommey m...@glandium.org writes: On Thu, Jul 02, 2009 at 02:26:21PM -0700, Russ Allbery wrote: Jonathan Yu jonathan.i...@gmail.com writes: How to fix them? Write Perl scripts, and turn on taint checking -- that fixes the four issues above, because it makes the script exit if any of them look dangerous. Env::Sanctify::Auto is a Perl module that automatically cleans up the paths. My advice: 1. Write scripts that might be run as root (or setuid root) using Perl 2. Turn on taint checking 3. Consider using Env::Sanctify::Auto (shameless plug) I would really prefer that people not start writing maintainer scripts in Perl as a matter of course. Perl is harder to analyze for programs like lintian than shell scripts (which are already hard enough). I wonder, do dpkg unset these variables when running maintainer scripts? That could be a good idea if it doesn't already. Mike It does not, at least not specifically. Nor do nearly all shell scripts in /usr/bin. And think of what fun that would be to debug for a debconf using package. Suddenly debconf gets told some paths and errors out. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Bastian Blank wa...@debian.org writes: On Fri, Jul 03, 2009 at 10:28:24AM +0200, Goswin von Brederlow wrote: Last I heart s390 planed to drop 31bit support and go fully 64bit. This was the plan. However I don't know if it is the best solution. The fact is: only Debian and SuSE still supports a complete 31bit userland. RHEL is released 64bit only with some 31bit libs and SuSE have both. This also means that many of the commercial software is now released as 64bit binaries. On s390 we have the advantage that we have a lot more operations in 64bit aka zarch mode while using the same opcode format. This includes things like 32bit immediate loads and, for z9 and newer only, unicode conversion[1]. So this code can actually be smaller and faster then the 31bit code. So if we are going to get multiarch support, I would vote for a two stage plan: - Do a full 31 and 64bit release for X. - Reduce the 31bit port to minimal for X+1. I hope that apt e.g. will be able to do such an upgrade. Bastian [1] https://bblank.thinkmo.de/blog/s390-assembler, https://bblank.thinkmo.de/blog/smallest-utf32-to-utf8-converter -- I guess that means introducing a full s390x architecture then and eventually making s390 the partial architecture. You can start on the first part for squeeze. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Bernd Zeimetz be...@bzed.de writes: Goswin von Brederlow wrote: Please do files bugs about issues you consider blockers for ia32-libs-tools and squeeze and please include if that applies even if there is the old ia32-libs in parallel to it (i.e. when it doesn't get pulled in on upgrades). The package is a mess, Specifics. Not just ranting please. the idea is broken by the design Not in my opinion. Works perfectly here. and it has numerous RC bugs. Lets see: http://packages.qa.debian.org/i/ia32-libs-tools.html RC bugs: 1 #535486 ia32-libs breaks multiarch buildd and adds useless dependency The fix for this is for fglrx to stop building fglrx-glx-ia32 and letting ia32-apt-get provide the 32bit fglrx-grl package from i386 instead. Purely a transitional issue. It doesn't even break the buildd. It just takes really long to install if you don't have a strong enough source for entropy. Do you *really* want to have more reasons? I would settle for one good one. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
ia32-apt-get: Striking my colors
Hi, I'm striking my colors. By popular demand I'm orphaning the ia32-libs and ia32-libs-gtk transitional packages. As said before the prerequisite for that was that someone else steps up as new maintainer for the old ia32-libs and ia32-libs-gtk monsters and Mark Hymers has agreed to do so. I don't know if Bdale Garbee bd...@gag.com and Frederik Schüler f...@debian.org will remain co-maintainer that is up to them. I've have prepared a new version (22) of ia32-lib-tools http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=ia32-libs-tools http://mentors.debian.net/debian/pool/main/i/ia32-libs-tools/ - drops ia32-libs and ia32-libs-gtk packages so Mark can take them over - removes all diversions to the package management - adds a conflict with ia32-libs and ia32-libs-gtk to all packages - adds a Provides: ia32-abi - introduces new ia32-apt-get/ia32-aptitude/ia32-dpkg/ia32-dpkg-deb wrapper scripts that preserve the old functionality Now why should anyone sponsor that? Simple. The ia32-apt-get/ia32-aptitute will allow users that have already installed ia32-apt-get to update their ia32-lib* packages to ones that Provide: ia32-abi. Then when Mark later uploads ia32-libs and ia32-libs-gtk he can Conflicts: ia32-abi, Replaces: ia32-abi to get a smooth transition. Without this ia32-libs and ia32-libs-gtk would have to Conflicts/Replaces on over 160 packages which would be a real pain. So this is a call to all ia32-apt-get haters to sponsor the upload so Mark can replace it later on. MfG Goswin PS: Thanks to Mark Hymers for being not just talk like many other. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
CDPATH and shell scripts
Hi, it seems to me that the current CDPATH behaviour is verry strange and extremly dangerous for shell scripts. For those that have never heart of CDPATH it does 2 things: 1) a relative cd command with search the CDPATH for the given directory. If unset then '.' is used. 2) it outputs the path it used to stdout. Now say you have the following script: #! /bin/sh cd /tmp mkdir src cd src : do something FOO=$(cd bar cat blub) rm -rf * cd .. rmdir src Calling that with CDPATH=~ exported will 'rm -rf ~/src'. That will be fun. It also suddenly outputs to stdout totally changing the value of FOO. So what is the right course of action here? 1) unset CDPATH in every single shell script there is? 2) never use relartive paths for cd in scripts? 3) shoot the user for doing something dumb? 4) disable CDPATH in /bin/sh (or is that POSIX?) or non-interactive scripts (would break automake I think) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
multiarch and maintainer scripts
Hi, what can be done if the maintainer scripts of a package must behave differently when unpacking the i386 deb on i386 or the i386 deb on amd64? For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on i386 but /usr/lib32/libGL.so.1.2 on amd64. Other examples would be packages that scan for plugins in their postinst to generate a list of them. Pango and gtk used to do that. Even if they are changed the multiarch library dirs they should probably continue to scan the old plugin dirs for backward compatibility. So would it make sense to allow architecture specific maintainer scripts? Back to the fglrx-glx example the control.tar.gz could contain: preinst-amd64 - use when configuring on amd64 preinst - use otherwise I choose '-' so it doesn't collide with debhelpers preinst.amd64 source files. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and maintainer scripts
Russ Allbery r...@debian.org writes: Goswin von Brederlow goswin-...@web.de writes: what can be done if the maintainer scripts of a package must behave differently when unpacking the i386 deb on i386 or the i386 deb on amd64? For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on i386 but /usr/lib32/libGL.so.1.2 on amd64. Surely this is as simple as: case `dpkg --print-architecture` in amd64) # Do some stuff. ;; i386) # Do some other stuff. ;; esac isn't it? That is another possibility. Is that the solution we (as in Debian) want? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: CDPATH and shell scripts
Russ Allbery r...@debian.org writes: Jonathan Yu jonathan.i...@gmail.com writes: How to fix them? Write Perl scripts, and turn on taint checking -- that fixes the four issues above, because it makes the script exit if any of them look dangerous. Env::Sanctify::Auto is a Perl module that automatically cleans up the paths. My advice: 1. Write scripts that might be run as root (or setuid root) using Perl 2. Turn on taint checking 3. Consider using Env::Sanctify::Auto (shameless plug) I would really prefer that people not start writing maintainer scripts in Perl as a matter of course. Perl is harder to analyze for programs like lintian than shell scripts (which are already hard enough). -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ Not to mention humans. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: CDPATH and shell scripts
Jonathan Yu jonathan.i...@gmail.com writes: Another option might be to break from POSIX/etc policy (I'm not sure where these variables are defined) and patch our command like 'cd' to simply ignore 'CDPATH' etc. But I suppose this would then require patches in all the various shells available for Debian to go against something standardized for so long. It's a contentious issue. I wish everyone all the best trying to figure it out, it's scary stuff indeed. Cheers, Jonathan As a middle ground I wouldn't mind $SHELL to unset CDPATH when it switches from an interactive shell to a non-interactive shell, when a script with #! $SHELL is executed. That one is just to damn scary. Also why does it output to stdout and not stderr? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Joerg Jaspert jo...@debian.org writes:
Hello world,
(Please remember that we can only speak for ourselves and not the
security/release/any other teams, individuals or other sentient beings.)
During the recent discussion about about ia32-libs{,-gtk,-tools} there were
various requests for removal / comments about ftpmaster requirements for the
whole ia32-libs situation.
Having looked at the situation both in lenny and in sid, we tend to agree that
ia32-libs-tools in its current form is unacceptable. It was mentioned in the
Please do files bugs about issues you consider blockers for
ia32-libs-tools and squeeze and please include if that applies even if
there is the old ia32-libs in parallel to it (i.e. when it doesn't get
pulled in on upgrades).
threads that comments had been received from ftpmaster that the lenny form of
ia32-libs (the one where all the source is duplicated in two huge packages -
ia32-libs and ia32-libs-gtk) was disliked. This remains the case but it is
still preferable (both to us, and it seems to the majority of the rest of the
project) than the ia32-libs-tools approach.
Given that there are definitely use-cases for some form of ia32-libs, we
suggest that a version of ia32-libs{-gtk} is re-uploaded to Debian, replacing
the current ia32-libs-tools. This needs agreement with the release and
security teams, as this most probably will have to be supported for squeeze in
some form (even if that includes admitting that we have no security support
for
the binary ia32-libs packages).
Also an agreement from Bdale Garbee bd...@gag.com and/or Frederik
Schüler f...@debian.org to remain its maintainer or another
volunteer.
The recent discussions on doing multiarch properly look promising and, even
better, there seems to be broad consensus that this is the right longer-term
direction. The question is whether the first round could be ready for squeeze
so that we don't have to ship ia32-libs again. This obviously depends on
people wanting (and having time) to work on it; hopefully more will be known
after the planned BoF at DebConf. Just to make it clear, there are no
objections at all from ftpmaster to multiarch and we will make sure that any
archive-side changes which may be necessary will be performed so that we don't
block it (although looking at the current proposal from Steve Langasek et al,
we can't really see anything which should need changing).
As per design. :)
There is only one thing that DAK might want to adapt to. For most
multiarch architectures there is a definite main architecture that
most things should be in and then some corner cases where different
architetcure might be prefered or required. Usualy because 32bit mode
has smaller code and is faster than 64bit mode but sometimes the
larger addresss space of 64bit mode is required.
So there might be a need to introduce partial architectures for ppc64,
mips64, mips64el, sparc64 that only carry a small subset of
Debian. The change would be in policy to allow architecture that are
partial and maybe some code to reject unwanted packages from those
architectures.
This should drop the surprising effects users of the ia32-libs-tools packages
experienced in the last few days and also allow us to continue supporting
users
of the 32 bit libraries.
I hope most surprises are addresses in the current version, at least
those that aren't as designed. Please do continue to file bugs when
you run into something so it can be addressed in the package and other
people are spared from the surprise in the future.
This is, as ever, not a statement of the future, but suggestions and thoughts
on the matter. It has mainly been written due to the fact that we have been
asked by multiple people to remove ia32-libs-tools but don't want to do so
until a consensus has been reached on what we're going to do to replace it.
Thanks,
--
bye, Joerg
Md Sesse: I doubt that many people will switch network
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Faidon Liambotis parav...@debian.org writes: Goswin von Brederlow wrote: ia32-wine is only available when ia32-apt-get is installed. WTF? Are you listening to yourself? Do you actually believe that it's okay to mess in such horrendous ways with the packaging system? If you don't want it then don't use it. That is your choice. If you think the old ia32-libs did any less messing around with the debs then you fail to see that the only difference is one of when. And the ia32-apt-get way has the advantage of supporting apt-get install skype and similar invocations. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: multiarch and maintainer scripts
Guillem Jover guil...@debian.org writes:
Hi!
On Thu, 2009-07-02 at 13:58:48 -0700, Russ Allbery wrote:
Goswin von Brederlow goswin-...@web.de writes:
what can be done if the maintainer scripts of a package must behave
differently when unpacking the i386 deb on i386 or the i386 deb on
amd64?
We discussed this with Steve some days ago. My initial idea was to
make âdpkg --print-architectureâ polymorphic, and change what it
prints depending on what architecture the package being installed is.
Then how would you detect if your package is unpacked on i386 or
amd64? An i386 deb knows at compile time that it is build for i386. I
see no good reason to have dpkg tell it so as well.
That would require less packaging changes, but it seems pretty
fragile and non-obvious behaviour, and we have several packages using
âuname -mâ, they'd need to be changed due to this or just to
multiarchify them anyway, so we discarded it.
uname -m tells what kernel is in use, not what architecture the
package was build for nor what architecture it gets installed for.
A mostly useless information. I would consider any package that uses
uname -m in its maintainer scrips buggy. You can not depend on it not
chaning at any time (the system is rebootet) and the mainatiner script
will not be rerun when it does.
But yesterday I came up with a simpler and cleaner solution, just
export an env var matching the package arch being installed. Something
like DPKG_MAINTSCRIPT_ARCH or similar.
That would be better, or at least not destroy other needed information.
For example 32bit fglrx-glx needs to divert /usr/lib/libGL.so.1.2 on
i386 but /usr/lib32/libGL.so.1.2 on amd64.
I don't think this example is relevant. Once libgl has been
multiarchified, then everywhere the i386 file is going to be located
under â/usr/lib/i486-linux-gnu/libGL.so.1.2â.
One can hope it catches on quickly enough. As it is free software it
can be changed easily enough. That might not always be the case,
especially when supporting backward compatible
/usr/lib{,32,64}/package/* plugin scanning though.
Surely this is as simple as:
case `dpkg --print-architecture` in
amd64)
# Do some stuff.
;;
i386)
# Do some other stuff.
;;
esac
isn't it?
In this case it might have been enough, or not needed at all.
But that would print the arch dpkg was built for (i.e. the native
architecture), not the foreign arch of the package we are installing,
which is what we'd be interested in most cases like grub, eglibc,
module-init-tools or util-linux maint scripts.
Which is what was required.
The package always knows the arch it build for at build time. For that
one can use
PKG_ARCH=@DEB_HOST_ARCH@
and
sed 's/@DEB_HOST_ARCH@/$(DEB_HOST_ARCH)/g' postinst.in postinst
or have debian/package.postinst.i386 and debian/package.postinst.amd64
and debhelper install the right one and so on.
(which doesn't mean dpkg exporting the arch at configure time wouldn't
be better in some cases)
regards,
guillem
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted ia32-libs-tools 21 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 01 Jul 2009 17:36:09 +0200 Source: ia32-libs-tools Binary: ia32-libs-tools ia32-archive ia32-apt-get ia32-libs ia32-libs-gtk Architecture: source all amd64 Version: 21 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Description: ia32-apt-get - Apt-get, aptitude and dpkg wrapper for on-the-fly conversion ia32-archive - Create a local archive of converted i386 debs for amd64 and ia64 ia32-libs - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-gtk - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-tools - Tools for converting i386 debs for amd64 and ia64 Closes: 535317 535430 535434 Changes: ia32-libs-tools (21) unstable; urgency=low . * Fix ia32-libgphoto2-2 Depends: libgphoto2-2 hack (Closes: #535317). * dpkg-deb.in: add NATIVE_ARCH instead of defaulting to amd64. * ia32-apt-get.postinst.in: Improve idempotency of gpg key creation. * apt-get.in: unset umask * sources.list files must end in .list, only consider those (Closes: #535430). * Add header blurb to generated sources.list files. * apt-get.in: Fix endless recursion if ALLOWED=None (Closes: #535434). Checksums-Sha1: 35d6aad0f75e1caef3baf79d9cd6f5db7b0dc93b 1087 ia32-libs-tools_21.dsc 69104a8fce7ea431634dfd93d721014b13d23f01 34060 ia32-libs-tools_21.tar.gz 5ab1262ac2c20d8a016ec813a337e66653a99bbe 10646 ia32-archive_21_all.deb a953a5411210a5bb805d2fdfd3ddb35762d62a55 23838 ia32-apt-get_21_all.deb 9093287b29287a937c34adbfa297854cf1110ddb 44538 ia32-libs-tools_21_amd64.deb 433ea3cabd7bfa8d14a89df40182f0b52207943c 5448 ia32-libs_21_amd64.deb 9e6e5ba419d8e4b29630f0b7fe42bc30ea627d99 5488 ia32-libs-gtk_21_amd64.deb Checksums-Sha256: 69c8a148d9a23644b86dded0138194611cdbb7503830f26404b903d2710c1bdb 1087 ia32-libs-tools_21.dsc 532779084f66132f4a95606a3104fcb7dc90060195758159a2d611306b46631e 34060 ia32-libs-tools_21.tar.gz 1a95613b83d5920324195194b2046649dd200d3cdc3a92647f38412a736b1028 10646 ia32-archive_21_all.deb 05efd0facbc1a0346d23c0d42bd44c98b04708e65f356cfec289ae21fbff78bd 23838 ia32-apt-get_21_all.deb 44aff1f3568f161fa531b534776d5db1d2ae86b90e32c95cc8c57e3cfb89f881 44538 ia32-libs-tools_21_amd64.deb 7845042bb0de8f200faf0f2fa8f831af92deafc68599c4c95c9e1fcbf4121c77 5448 ia32-libs_21_amd64.deb 059dd93a1805fdc9f87e07c35cbc4aac84a483b90f0f72af9726e09b449344ca 5488 ia32-libs-gtk_21_amd64.deb Files: 0dafed23d08083c5e8d6e3c101ad72ee 1087 devel extra ia32-libs-tools_21.dsc 114445277cd17681467208794e30b616 34060 devel extra ia32-libs-tools_21.tar.gz df1b52bd9f76841beed1456d7ef40914 10646 devel extra ia32-archive_21_all.deb c21ada87d7565b9bed749404d0700cc0 23838 devel extra ia32-apt-get_21_all.deb bef59c90715a0363f9d529a4607738ec 44538 devel extra ia32-libs-tools_21_amd64.deb 9dffd16d4b7b813e853b7e21983d2cc9 5448 libs optional ia32-libs_21_amd64.deb fc386796eeace5cbb0b296ebf0f58325 5488 libs optional ia32-libs-gtk_21_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQCVAwUBSkzgjokABLrCbuiRAQJL3wP9Gc/0q8DzIntaI3hEJTRK+eKdiwF3+Gqf OHio+LtgYWWsIgqEec6gOTCirOWBTU8iGtH52ql+1RYUrAfiMcZcPZz2vqKSnfea lWqMCqmwpUXf2JvzcX938xQMO4HUJqzfKGqmeqqJ+qVK3u/VEQX1qpdSbCZRaMCI ss9LcVSFudw= =eckH -END PGP SIGNATURE- Accepted: ia32-apt-get_21_all.deb to pool/main/i/ia32-libs-tools/ia32-apt-get_21_all.deb ia32-archive_21_all.deb to pool/main/i/ia32-libs-tools/ia32-archive_21_all.deb ia32-libs-gtk_21_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs-gtk_21_amd64.deb ia32-libs-tools_21.dsc to pool/main/i/ia32-libs-tools/ia32-libs-tools_21.dsc ia32-libs-tools_21.tar.gz to pool/main/i/ia32-libs-tools/ia32-libs-tools_21.tar.gz ia32-libs-tools_21_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs-tools_21_amd64.deb ia32-libs_21_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs_21_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Aneurin Price aneurin.pr...@gmail.com writes: On Tue, Jun 30, 2009 at 05:11, Goswin von Brederlowgoswin-...@web.de wrote: Aneurin Price aneurin.pr...@gmail.com writes: Hi, I've just spent over an hour writing and rewriting this mail, and determined that I can't think of a single constructive thing to say. Not wanting to leave it at that, I've spent a couple of hours today trying to pin down some specifics. Unfortunately I've not had much success. Purging everything related to 32bit compatibility and reinstalling doesn't ever seem to have exactly the same effect - so far I've seen numerous problems, but none of them reproducibly, and many of them making no sense at all - eg how in the world did I lose /usr/bin/dpkg-deb at one point? No clue. The apt segfault went away That would require you to hit ctrl-C in the preinst between a mv and a ln command. Or on remove between dpkg removing the package and running postrm where the diversion is undone. In both cases you would have a half-installed package due to your ctrl-c-ing. after setting Cache-Limit to 50331648 - but why did it only start doing that after a couple of goes? Couldn't say. That makes 4 people having hit that libapt bug. I suspect that all of my problems are secondary damage rooted in a problem I had the first time I tried the update: installing ia32-apt-get requires a ton of entropy to generate a private key (why? beats me). Unfortunately, my system didn't seem to be able to generate sufficient randomness even after an evening of use, so eventually I ^Cd it just so that at least the dpkg database lock would be released. I'm aware that this isn't a good idea, but I didn't feel that I had a great deal of choice - plus I've never had a partial package install be such a headache to clean up before. Curiously, in my later repeats of the process it never took more than a couple of minutes to generate enough entropy, and usually it was less than a minute, so I'm not sure why it had such a problem the first time. I verry rarely have enough random bits for gpg to create a key. Even after hours of uptime without using gpg. Other things eat up enough to keep the pool small. But I never had it block for hours waiting for more. Usualy continious quickly. Do you use ssl for mail and had a fair amount of mail traffic? I heart that that eats up random bits like crazy. Or maybe that, once cleaned up, wasn't the end of the world after all. Another possibility is that I didn't realise until I'd read the other thread that you need to use apt-get to complete the process, so I just used aptitude the first couple of goes, as I usually do. You only need apt-get update. The rest works in aptitude or synaptic. So I'll just ask a couple of questions instead: Is there any way of preventing this kind of major breakage in the future? I don't think many people expect that upgrading one package will FUBAR the packaging system. Is there any chance of Wine becoming functional on amd64 in the forseeable future? # apt-get install ia32-wine Except that it's really: apt-get update apt-get upgrade apt-get update apt-get install ia32-wine Rather than: aptitude update aptitude install wine At least that's what I assume. I can't get past the second apt-get update without something breaking. With version 19 (on mentors.debian.net) you can now also do aptitude install ia32-apt-get aptitude update aptitude install ia32-wine You only need one round of update after ia32-apt-get. ia32-wine depends on all the libraries it needs and pulls them it. It doesn't need an upgrade of ia32-libs before it is installable. This entire direction is a dead end. Having these extra package databases and dpkg-diversions only works in a very narrow set of circumstances. It's only a workable solution if you assume that everyone: * Uses apt-get and nothing else * Doesn't care about having other package-related tools like apt-file fully functional apt-file needs to be patched for multiarch so it can cope with multiple Contents-$ARCH files eventually. If you do that now it will function more and more as libraries are converted to multiarch even if ia32-apt-get is still used to install them. Remember that packages can convert to multiarch prior to dpkg/apt/aptitute/synaptic/... being multiarch capable. * Doesn't care about packages not being shown 'correctly' in eg. aptitude/apt-cache search, at least until the magic setup process is complete. correctly? Inbetween installing ia32-apt-get and running update for the first time after that there is small window where some index files will be unavailable. I'm not aware though that that affects how packages are shown in aptitude or apt-cache. I use apt-cache quite a lot and it displays things just fine for me. * Reads the documentation and knows that they have to complete a multi-step process. * Is actually happy to do so * Is always going to know specifically that a certain
Re: ia32-libs depends on ia32-apt-get ?
Steve Langasek vor...@debian.org writes: On Tue, Jun 30, 2009 at 06:52:34PM +0200, Goswin von Brederlow wrote: Look at perl for example: Package: perl-base Provides: perlapi-5.10.0 I suggest to also provide perlabi-$(DEB_HOST_GNU_TYPE) or perlabi-5.10.0-$(DEB_HOST_GNU_TYPE). Perl extensions that need a matching ABI can then easily depend on the right package. The dh_perl helper could add the dependency automatically allowing a binNMU to transition many packages. Do you intend to do the same for python, which has no such API provides? Or are you only proposing a workaround for perl? Yes. No. I was using perl as example because it verry nearly already is doing this with its perlapi-5.10.0 provide. I imagine dh_python / dh_pycentral / dh_pysupport will be able to autodetect the need for a dependency on the python ABI automatically as well. Also, what are the immediate practical use cases for cross-arch depends on extensible interpreters such as python and perl? Wine doesn't need this, nor does nspluginwrapper AFAICS, so what actually is negatively impacted by requiring that class of dependencies to be deferred by a release cycle? Say you have: Package: foo Architecture: amd64 Depends: perl Package: bar Architecture: i386 Depends: perl Package: libbaz-perl Architecture: amd64 Depends: perl Package: libbat-perl Architecture: i386 Depends: perl This is a hypothetical. I asked for evidence of a *practical* impact. You really need me to go through the rdpends of interpreters and find an example of 2 arch:any packages that depend on one? Ok, here we go: Package: skyped Architecture: i386 Depends: python (= 2.5), python-gnutls, python-skype (= 0.9.28.7) Description: Daemon to control Skype remotely Package: totem Architecture: amd64 Depends: python, python-support (= 0.90.0) Description: A simple media player for the GNOME desktop based on GStreamer So installing skyped would require a 32bit python and 32bit totem prior to a release cycle. 4) Using Depends: perl [same] This would allos foo and bar to be both installed but only the right one of libbaz-perl and libbat-perl. But that takes a release cycle to introduce the new syntax. But if it's unproven that anyone *needs* this, there's no reason to worry about the delay for implementing this corner case. See above. Note that you also need perl to break libbaz-perl and libbat-perl versions prior to the ones with Depends: perl [same] or yet another release cycle. But a Provides: perlabi-$(DEB_HOST_GNU_TYPE) suffers from the same problem. The need for flag days for interpreters is identified as a limitation of this design, and is actually a point that's currently under review. Handling of -dev packages is defined as *out of scope* for this specification. I fail to see how it's broken to confine the initial scope to those elements that impact the package management tools, to avoid getting bogged down in irrelevant discussions about filesystem layouts. The problem is in the dependencies and actually not restricted to just -dev packages. Transitional/Meta packages suffer from this in general. For the sake of an example lets say you have the following packages (xlibs-dev being a real example): You know xlibs-dev is no longer in the archive, right? -dev metapackages don't make a whole lot of sense except on a transitional basis. While there may be some things that still need to be tightened up here, if one of the outcomes is that -dev metapackages have to be made arch: any, I don't think that's too onerous. Not just -dev metapackages, any meta/transitional packages can run into this. xlibs-dev is just the package where I noticed the issue first. Source: foo Build-Depends: xlibs-dev, bar Package: xlibs-dev Architecture: all Depends: libice-dev, libsm-dev, libx11-dev, libxext-dev, ... Package: libice-dev Architecture: any Multi-Arch: same Package: bar Architecture: any Multi-Arch: foreign Depends: baz Package: baz Architecture: any You assume: | Dependencies, Build-Dependencies, and Recommends within an existing | architecture foo will continue to remain closed over the set of | packages declaring either Architecture: foo or Architecture: all. This is a statement of the implications for the archive, and is an expression of the existing archive requirements. It says nothing about how build-dependency fields are to be interpreted on a build system. Say you are building on amd64 and libice-dev:i386, bar:i386 and baz:i386 is installed. 1) The 'Multi-Arch: foreign' breaks your assumption. Bar:i386 + baz:i386 satisfy a dependency on bar for amd64 just fine. You assumption would indicate you don't consider that a satisfaction of the Build-Depends. Per the above, your conclusion here is invalid. It satisfies the build-depends, it's just not sufficient from an archive perspective for bar:i386 to be the *only* package
Re: A standard patch rule for our rules
Rafael Almeida almeida...@gmail.com writes: A ``patch'' rule for debian/rules there should always be for I'd like to easily apply patches created by me Don't worry I don't think of anything too hard a simple standarization will ease my heart Today ``debian/rules build'' is always a good match but there's no mandatory ``debian/rules patch'' Is the ``build'' rule mandatory? I don't even know it seems to work for most packages, though Debian policy describes all the required targets and some optional ones. Patches, it seems, are for ``configure'' rule to apply but I want to make a script and I think it won't fly That script I think of will install my own patches to any installable package, from zopes to apaches Configures can change too much like config.h files and such There should be one and only patch rule and then I'll be able to build my tool man dpkg-source Format: 3.0 (quilt) A source package in this format contains at least an original tarball (.orig.tar.ext where ext can be gz, bz2 and lzma) and a debian tarball (.debian.tar.ext). It can also contain additional original tarballs (.orig-component.tar.ext). component can only contain alphanumeric characters and dashes (-). ... Behold the future is, aeh, soon. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted ia32-libs-tools 20 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 01 Jul 2009 09:08:19 +0200 Source: ia32-libs-tools Binary: ia32-libs-tools ia32-archive ia32-apt-get ia32-libs ia32-libs-gtk Architecture: source all amd64 Version: 20 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Description: ia32-apt-get - Apt-get and dpkg wrapper for on-the-fly ia32-libs conversion ia32-archive - Create a local archive of converted i386 debs for amd64 and ia64 ia32-libs - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-gtk - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-tools - Tools for converting i386 debs for amd64 and ia64 Closes: 535274 Changes: ia32-libs-tools (20) unstable; urgency=low . * Typo fix for pinning thanks to Lionel Elie Mamane. * Don't ship /etc/apt/*/sources.list.d/ or /var/*/apt/*/lists/, generate and remove as needed. * Remove /usr/share/ia32-apt-get/transitional/dists/Release.gpg in prerm (Closes: #535274). * Use gpg --homedir instead of setting HOME. * Protect against gpg being interrupted while creating a key. * Protect against convert-all-sources.list being interrupted. * Mark ia32-apt-get-transitional repository as [arch=i386]. * Prepare for upcoming kfreebsd support: + Eliminate the last occurances of @NATIVE_ARCH@, ask dpkg for it. + Add @FOREIGN_ARCH@ to postrm. Checksums-Sha1: 78a131b879cfe0ff23aafc9cae40ddb0200810c6 993 ia32-libs-tools_20.dsc 5bf9c63b78fb88b83826872cb3cdaebd2c0e9e2d 37763 ia32-libs-tools_20.tar.gz bf74bee04cb5878e4c8218adbd51c3f3ad3f8792 10490 ia32-archive_20_all.deb 25dd57dd58eb5a2640439e7e13156ceec58f4405 23866 ia32-apt-get_20_all.deb 3197ca0ccf0d6a3baed39ec0f1eb90e0f839b924 44176 ia32-libs-tools_20_amd64.deb 78f65136e619c1ae873ab53f042e4beabd921198 5288 ia32-libs_20_amd64.deb 5cc1c52073ceda116e6376e8659c1b905d77e83c 5332 ia32-libs-gtk_20_amd64.deb Checksums-Sha256: bc3e281062f8c129a547e816d4beb0b4fe7285dd1836e6837b83f7a4dece3461 993 ia32-libs-tools_20.dsc be1e4fcf74dee17ec6e9bc8d9141209459c90006f17468ced2a184b968b299e6 37763 ia32-libs-tools_20.tar.gz c0c330fe8c627f7fc92c3f9a823aa51e04be42dfc2ee6ac133b9c70c89c5d25b 10490 ia32-archive_20_all.deb 17cdfd6e474e79be997d255b34d6dfb8a881e40e166352bb45a55ffc72932942 23866 ia32-apt-get_20_all.deb b6eefdf24f1da9fabfd3a9a7d8f938dda054f6e3b3a0e08160bfb08afac51d37 44176 ia32-libs-tools_20_amd64.deb 1bc029b0ef83dc7cc9508cad9098960912ac97232894b61441e9b53bf1d8a020 5288 ia32-libs_20_amd64.deb caf2caa281db94569ec71d9634c63cd6461a013dc98bcdc3a7022fb4aa579bb2 5332 ia32-libs-gtk_20_amd64.deb Files: fc77e4ecd0b9390b9741c68db87073aa 993 devel extra ia32-libs-tools_20.dsc c21a8e94730a014e66f907bf1f979730 37763 devel extra ia32-libs-tools_20.tar.gz bd369eb125e90f812e140d7c051309a6 10490 devel extra ia32-archive_20_all.deb 525aff30b6ed4641c09326bcd564ba42 23866 devel extra ia32-apt-get_20_all.deb 917f913d30585029c400506e15ad1ffe 44176 devel extra ia32-libs-tools_20_amd64.deb a3538ed8c9b838fd7268ea610b6b8084 5288 libs optional ia32-libs_20_amd64.deb 527881d4d8ab343304f072d9eefba9c8 5332 libs optional ia32-libs-gtk_20_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpLfaoACgkQA+GMa4PlEQ837ACfRMe65VGbNbrtmycsirlMruxV YWYAn1EQXxqUBwBLVBwTjz8i8vJ8Fv92 =zyjO -END PGP SIGNATURE- Accepted: ia32-apt-get_20_all.deb to pool/main/i/ia32-libs-tools/ia32-apt-get_20_all.deb ia32-archive_20_all.deb to pool/main/i/ia32-libs-tools/ia32-archive_20_all.deb ia32-libs-gtk_20_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs-gtk_20_amd64.deb ia32-libs-tools_20.dsc to pool/main/i/ia32-libs-tools/ia32-libs-tools_20.dsc ia32-libs-tools_20.tar.gz to pool/main/i/ia32-libs-tools/ia32-libs-tools_20.tar.gz ia32-libs-tools_20_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs-tools_20_amd64.deb ia32-libs_20_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs_20_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Steve Langasek vor...@debian.org writes: On Mon, Jun 29, 2009 at 09:50:01PM +0200, Goswin von Brederlow wrote: Raphael Hertzog hert...@debian.org writes: There is work going on recently. Steve Langasek drafted a plan that he wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a reality inside Debian but I don't know of any timeframe. https://wiki.ubuntu.com/MultiarchSpec They messed up some finer details, broke the existing patches, Patches implementing what? I don't see any public discussion of an agreed design for the package manager. Patches for dpkg to accept the Multi-Arch field as a tristate of Yes, No or missing and for packages to set that field. It's been yes/no/missing in all the mails about multiarch for years and suddnely you changed the string. (Nor is there one for the MultiarchSpec, but that's only because Guillem and I are still hammering out some of the details that we don't yet agree on; so a public announcement is a little bit premature.) So you do that in a dark corner ignoring any other people that worked on multiarch before? You are only 2 people, you only have 4 eyes (I assume). You are bound to miss something that a larger group would spot. made the whole thing need a full release cycle for a transition due to DEBIAN/control format changes You appear to be referring to https://wiki.ubuntu.com/MultiarchSpec#Extended%20semantics%20of%20per-architecture%20package%20relationships. What do you propose as an alternative that would let us achieve multiarch sooner? Multiarch has already failed to get traction for more than two Look at perl for example: Package: perl-base Provides: perlapi-5.10.0 I suggest to also provide perlabi-$(DEB_HOST_GNU_TYPE) or perlabi-5.10.0-$(DEB_HOST_GNU_TYPE). Perl extensions that need a matching ABI can then easily depend on the right package. The dh_perl helper could add the dependency automatically allowing a binNMU to transition many packages. release cycles, and I don't see that your ia32-apt-get kludges are doing anything to get us there sooner. Please stop confusing ia32-apt-get with multiarch. It clearly is a kludge to keep 32bit binaries working till there is multiarch. It is not ment as a replacement. Also, what are the immediate practical use cases for cross-arch depends on extensible interpreters such as python and perl? Wine doesn't need this, nor does nspluginwrapper AFAICS, so what actually is negatively impacted by requiring that class of dependencies to be deferred by a release cycle? Say you have: Package: foo Architecture: amd64 Depends: perl Package: bar Architecture: i386 Depends: perl Package: libbaz-perl Architecture: amd64 Depends: perl Package: libbat-perl Architecture: i386 Depends: perl Foo and Bar are binary packages that in some way use perl as a simple interpreter. Libbaz-perl and libbat-perl on the other hand are bindings for perl to use 2 C libraries libbaz and libbat. Now with your proposal you have a few options: 1) perl has no Multi-Arch field Eigther foo can be installed or bar. But never both. 2) perl has Multi-Arch: same Now perl:i386 and perl:amd64 are flagged as coinstallable. Not supported. 3) perl has Multi-Arch: foreign Now foo and bar can be installed but so can libbaz-perl and libbat-perl. One of the libs will be broken. 4) Using Depends: perl [same] This would allos foo and bar to be both installed but only the right one of libbaz-perl and libbat-perl. But that takes a release cycle to introduce the new syntax. Note that you also need perl to break libbaz-perl and libbat-perl versions prior to the ones with Depends: perl [same] or yet another release cycle. But a Provides: perlabi-$(DEB_HOST_GNU_TYPE) suffers from the same problem. and have a broken plan for -dev packages. Handling of -dev packages is defined as *out of scope* for this specification. I fail to see how it's broken to confine the initial scope to those elements that impact the package management tools, to avoid getting bogged down in irrelevant discussions about filesystem layouts. Actually the filesystem layout for -dev packages is no problem at all. We already have /usr/include/$(DEB_HOST_GNU_TYPE) for include files (where needed) and /usr/lib/$(DEB_HOST_GNU_TYPE) for the *.so links. That part might be work but not a problem. The problem is in the dependencies and actually not restricted to just -dev packages. Transitional/Meta packages suffer from this in general. For the sake of an example lets say you have the following packages (xlibs-dev being a real example): Source: foo Build-Depends: xlibs-dev, bar Package: xlibs-dev Architecture: all Depends: libice-dev, libsm-dev, libx11-dev, libxext-dev, ... Package: libice-dev Architecture: any Multi-Arch: same Package: bar Architecture: any Multi-Arch: foreign Depends: baz Package: baz Architecture: any
Re: ia32-libs depends on ia32-apt-get ?
Mark Brown broo...@sirena.org.uk writes: On Mon, Jun 29, 2009 at 09:31:24PM +0200, Goswin von Brederlow wrote: Mark Brown broo...@sirena.org.uk writes: There seems to be at least some crossover between the people who were looking at multiarch and the people doing this stuff. But not the people blocking the inclusion of patches for multiarch already present in the BTS. Then bring that up and try to move the discussion forward (as now seems to be happening). The approach that's currently being pused seems like a blind alley. People really do seem to confuse this. ia32-apt-get is not an alternative to multiarch. Never has been, never will be. It is the ugly hack that keeps existing things running till mutliarch fixes the problem. The only thing ia32-apt-get is supposed to fix is ia32-libs and ia32-libs-gtk unmaintainability and security bugs. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Didier 'OdyX' Raboud did...@raboud.com writes: Goswin von Brederlow wrote: Aneurin Price aneurin.pr...@gmail.com writes: Hi, I've just spent over an hour writing and rewriting this mail, and determined that I can't think of a single constructive thing to say. So I'll just ask a couple of questions instead: Is there any way of preventing this kind of major breakage in the future? I don't think many people expect that upgrading one package will FUBAR the packaging system. Is there any chance of Wine becoming functional on amd64 in the forseeable future? # apt-get install ia32-wine (...) 0 upgraded, 11 newly installed, 0 to remove and 187 not upgraded. Need to get 11.0MB of archives. After this operation, 51.4MB of additional disk space will be used. Do you want to continue [Y/n]? y ... % winemine Have fun. Works both with sid and experimental wine. Provided you have a lib32ncurses5 and lib32readline5 with the lib32 transition completed that is. Bug the respective maintainers for that one. Hi Goswin, Sorry, but that's plain false. The package ia32-wine is non-existant. # apt-get install ia32-wine Reading package lists... Done Building dependency tree Reading state information... Done E: Couldn't find package ia32-wine Ia32-wine is only available when ia32-apt-get is installed. I assumed you already had that. What exactly will happen with wine or how exactly it will do the trick to be installable out of the box isn't fixed yet. It is possible the same 2 stage install as ia32-libs will be used or something better. But the package wine is and here is what I get : # apt-get install wine (...) works $ winemine (does not work) That will install the wine_..._amd64.deb that is in unstable but missing in experimental for the latest version. Depending on the solution it might disapear in unstable or be repalced by a Meta package of one form or another. From talking to the wine maintainer I know that in the not to distant future wine will support the win64 API so you can run 64bit windows programs. So the actualy outcome might be that you have 3 packages: wine, ia32-wine and wine64. Where wine would pull in ia32-wine and wine64 and an contain a wrapper so wine foo.exe calls the right one. You will have to see how wine will turn out. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Josselin Mouette j...@debian.org writes: Le mardi 30 juin 2009 à 01:55 +0100, Aneurin Price a écrit : Is there any way of preventing this kind of major breakage in the future? I don't think many people expect that upgrading one package will FUBAR the packaging system. Report a critical bug against the package. Arrange so that it can never migrate to testing. Is there any chance of Wine becoming functional on amd64 in the forseeable future? Yes: hijack the ia32-libs package. Will you do security support and regular uploads for it too? Or just a one shot upload? Will you stand against ftp-masters whish to remove it? If so then do join the ia32-libs team on alioth and make an upload. I'm sure Bdale and Frederick have nothing against it. But then you need to do the work too, not just the talk. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Jonas Meurer jo...@freesources.org writes: On 30/06/2009 Goswin von Brederlow wrote: Did anyone who isn't on crack get to see 'ia32-apt-get.preinst' and 'ia32-apt-get.postinst' before they were perpetrated upon an unsuspecting populace? Reading them in the process of trying to unfuck my system made me feel more than slightly ill. Since my package was sponsored I would assume at least one other person looked over it. You are the first to mention illness. I can't change what it does. But do you have suggestion to improve how it does things in preinst/postinst/postrm? it seems like the whole ia32 transition is a major illness. apt-get now installs random packages from i386 over the ones from amd64 in case that the version from i386 is superior. that just happened for initscripts sysvinit sysvinit-utils and rar on my system. why the heck does ia32-apt-get replace amd64 packages with i386 ones at all? is this an attempt to slowly migrate amd64 systems to i386 ones? greetings, jonas Because you didn't read the NEWS. Given the number of people that don't read NEWS or have generally been surprised of ia32-apt-get introducing 32bit packages to the system the next upload of ia32-apt-get will be more explicit about this and only activate after the user confirmed its use. Actualy some constructive discussion on irc about this problem has revealed a possible solution. Binary packages, those that don't get an ia32- prefix, can easily be filtered out of the Packages files preventing any replacement of 64bit packages with 32bit. That also prevents things like skype to be listed though. So I intend to add a debconf question: Do you want to [ ] abort installing ia32-apt-get [ ] only allow 32bit libraries [ ] allow 32bit libraries and binaries (DANGER: see docs about pining) or something of that sort. Will that satisfy you? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Multiarch
Steve Langasek vor...@debian.org writes: On Mon, Jun 29, 2009 at 09:02:05PM +0100, Matthew Johnson wrote: I've also CC'd Hector and Steve who are listed as owners on that document because whatever we do to get multiarch working (and I have no strong views on the right way to do it) we should definitely not do it differently to Ubuntu. Since there seems to be some confusion on this point, let me clarify that there is no proposal for Ubuntu to diverge from Debian in implementing multiarch. A session on multiarch was held at UDS because it was convenient for a face-to-face discussion of *Debian* package management. Most of the people involved in the discussion were Debian developers, including both a dpkg comaintainer (Guillem) and an apt comaintainer (Michael). While the specification resides in the Ubuntu wiki, I'm anticipating that the implementation will be driven directly in Debian first, thanks in large part to Guillem's interest. And indeed, Ubuntu is largely at Guillem's mercy, since no one in Ubuntu has committed any resources to the dpkg implementation. :) We also have a follow-up round table scheduled at DebConf, to take this further: https://penta.debconf.org/penta/submission/dc9/event/395 Thanks for clarifying that. Didn't sound like that before. Do you have any minutes of the meeting you could include in the debian wiki? It probably wouldn't hurt to put the proposal there too and update it as more details are cleared up? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Didier 'OdyX' Raboud did...@raboud.com writes: Goswin von Brederlow wrote: Aneurin Price aneurin.pr...@gmail.com writes: Hi, I've just spent over an hour writing and rewriting this mail, and determined that I can't think of a single constructive thing to say. So I'll just ask a couple of questions instead: Is there any way of preventing this kind of major breakage in the future? I don't think many people expect that upgrading one package will FUBAR the packaging system. Is there any chance of Wine becoming functional on amd64 in the forseeable future? # apt-get install ia32-wine (...) 0 upgraded, 11 newly installed, 0 to remove and 187 not upgraded. Need to get 11.0MB of archives. After this operation, 51.4MB of additional disk space will be used. Do you want to continue [Y/n]? y ... % winemine Have fun. Works both with sid and experimental wine. Provided you have a lib32ncurses5 and lib32readline5 with the lib32 transition completed that is. Bug the respective maintainers for that one. Hi Goswin, Sorry, but that's plain false. The package ia32-wine is non-existant. # apt-get install ia32-wine Reading package lists... Done Building dependency tree Reading state information... Done E: Couldn't find package ia32-wine But the package wine is and here is what I get : # apt-get install wine (...) works $ winemine (does not work) Regards, OdyX Small addition. The reason that wine breaks there is that libc6-i386 is missing a Breaks: wine packages and wine is missing a Pre-Depends: libc6-i386 (= 2.9-18). The existing wine packages (if they are to be kept) need to to the lib32 link - directory transition. Just one more SNAFU of libc6, not my fault. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Josselin Mouette j...@debian.org writes: Le mardi 30 juin 2009 à 18:52 +0200, Goswin von Brederlow a écrit : Please stop confusing ia32-apt-get with multiarch. It clearly is a kludge to keep 32bit binaries working till there is multiarch. It is not ment as a replacement. No, it is not a kludge. It is a horrible pile of trash. ia32-libs, in the state it was before you broke it, was a kludge. One that we can live with until multiarch is ready. ftp-master disagreed. Now if you could just revert the changes in ia32-libs and spend the time you are currently wasting on ia32-apt-get helping with multiarch, that would be more helpful. Thanks, I didn't change anything in ia32-libs. It was replaced completly. So just checkout ia32-libs from svn, increase the version and upload. But then you have to maintain it and do security support for it too. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Yannick yannick.roeh...@free.fr writes: Maybe all of this should go to experimental (is there a problem with wine depending on experimental packages for amd64?) but thank you Goswin for your work. Yannick The problem was that libc6-i386 broke all 32bit support in unstable making all 32bit packages uninstallable. So something had to be done for unstable. I would have prefered doing this in experimental first too. Esspecially seeing how the libc6-i386 screwed up the transition on its first try and is still buggy (breaks wine). The choices where 1) rewrite the old ia32-libs + ia32-libs-gtk for the new libc6-i386 or 2) make ia32-apt-get take over (slightly prematurely in hindsight) According to popcon ~60 people had the previous ia32-apt-get installed so I didn't expect that much of an outrage about it. Now it shows 120 people. Anyway, what is done is done. I uploaded a new version to mentors. If anyone cares to try it out: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=ia32-libs-tools http://mentors.debian.net/debian/pool/main/i/ia32-libs-tools/ MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Didier 'OdyX' Raboud did...@raboud.com writes:
Hi,
Norbert Preining wrote:
On Mo, 29 Jun 2009, Josselin Mouette wrote:
This package was already enough of a hack, but at least it worked
without fiddling in horrible ways with the packaging system.
How can we have a working wine or nspluginwrapper now?
Not that I know about nspluginwrapper, but I got my skype working again
by:
- calling /usr/share/ia32-apt-get/convert-all-sources.list
Which horribly breaks with anything a little custom (proxies, custom
repositories, ...) and fills your /etc/apt/sources.list.d/ with ia32-apt-
get.{i386,amd64} copies of all your pet sources.
Examples please.
It also breaks on install if there is no /etc/apt/sources.list (which is
obviously unuseful if you have filled your /etc/apt/sources.list.d/ ).
- increaing Cache-Limit in /etc/apt/conf.d/00cachesize
I did that configuration in /etc/apt/apt.conf.d/99custom by the way (for
other things)...
- calling apt-get update from the commandline
It dpkg-diverts apt-get but not aptitude... How can we accept to see apt-get
diverted for such a hack ?
You don't have too but then you won't get 32bit support beyond the
verry core libs needed for gcc-multilib.
The reasons for ia32-apt-get are this:
- multiarch is still not there.
- ia32-libs source with all the additional request libs grows to about
1GB in size of which everything is pure duplication.
- ia32-libs contains so many libs that it needs a new upload every
other day (or is constantly out of sync like it always was).
- ia32-libs can only cover unstable or testing but not both.
- ia32-libs has no security support but security bugs.
- ia32-libs doesn't ensure library versions are new (or old) enough
to work with 3rd party debs. They easily miss a library or get a
wrong version.
- ftp-master has vetoed splitting ia32-libs into individual packages
and shown a strong dislike to ia32-libs as it was.
- ia32-libs doesn't allow to install 3rd party 32bit debs or use 3rd
party apt repositories with 32bit packages.
- installing skype from aptitude
Personnally, I don't care for non-free stuff, but main's wine depends on
ia32-apt-get through ia32-libsâ¦
apt-get install ia32-wine (tested with the experimental wine)
Regards,
OdyX, who points to multiarch and suggests it is maybe time to go the real
route insteadâ¦
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Didier 'OdyX' Raboud did...@raboud.com writes:
Goswin von Brederlow wrote:
Didier 'OdyX' Raboud did...@raboud.com writes:
Norbert Preining wrote:
- calling /usr/share/ia32-apt-get/convert-all-sources.list
Which horribly breaks with anything a little custom (proxies, custom
repositories, ...) and fills your /etc/apt/sources.list.d/ with ia32-apt-
get.{i386,amd64} copies of all your pet sources.
Examples please.
Hi Goswin,
Here is an example from my laptop :
I don't have an /etc/apt/sources.list , so installation fails (#534979). In
my /etc/apt/sources.list.d, I have 4 files :
* 00_particulars.list, which contains various repositories, some of them
commented, some of them not, mostly unused now.
* 10_apt-proxy.list, which contains lines for my home apt-proxy-ng with
testing, t-p-u, unstable, experimental and testing/updates.
* 20_std.list.dis and 30_local_pbuilder.list.dis, both disabled for aptitude
(fallback and intent).
You'll find them in the attached apt_sources_list_d.tar.bz2.
# touch /etc/apt/sources.list; aptitude install ia32-apt-get
(Does it really generate a gpg key as root, asking me to move the mouse ?)
Then, in /etc/apt/sources.list.d/, in addition to _MY_ 4 files, I have the
following list :
ia32-apt-get.amd64.00_particulars.list
(Completely broken, no valid repository)
I get:
deb ftp://ftp.uni-kl.de/debian-multimedia/ testing-amd64 main
deb ftp://ftp.uni-kl.de/debian-multimedia/ unstable-amd64 main
deb ftp://ftp.uni-kl.de/debian-multimedia/ experimental-amd64 main
deb http://kernel-archive.buildserver.net/debian-kernel sid-amd64 main
deb http://kernel-archive.buildserver.net/debian-kernel trunk-amd64 main
deb http://pkg-fso.alioth.debian.org/debian unstable-amd64 main
and all the comments. That looks just fine.
ia32-apt-get.amd64.list
(empty)
Expected as sources.list is empty.
ia32-apt-get.i386.ia32-apt-get-transitional.list
(transitional-i386/main not found = nothing valid)
ia32-apt-get.amd64.10_apt-proxy.list
(Completely broken, no valid repository)
deb http://apt.#HIDDEN#:3142/debian/ testing-amd64 main contrib non-free
deb http://apt.#HIDDEN#:3142/debian/ testing-proposed-updates-amd64 main
contrib non-free
...
looks fine too.
ia32-apt-get.i386.00_particulars.list
(Completely broken, no valid repository)
ia32-apt-get.i386.list
(empty)
ia32-apt-get.amd64.ia32-apt-get-transitional.list
(transitional-amd64/main not found = nothing valid)
ia32-apt-get.i386.10_apt-proxy.list
(Completely broken, no valid repository)
Same as the respecive file of the other arch.
ia32-apt-get-transitional.list
(WORKS ! - Contains ia32-libs{,-gtk} 1:3.0)
So among the 9 packages prepared by ia32-apt-get postinst, one is working.
All others are broken.
You'll find them in the attached apt_sources_list_d_after.tar.bz2.
Is that enough of an example ?
Not realy. None of your entries causes an error. They all convert
perfectly.
What do you mean no valid repository? Are you trying to use them
without first having called apt-get update to actualy create the
index files they reference? So far everything you have shown is as
designed.
- calling apt-get update from the commandline
It dpkg-diverts apt-get but not aptitude... How can we accept to see
apt-get diverted for such a hack ?
You don't have too but then you won't get 32bit support beyond the
verry core libs needed for gcc-multilib.
Sorry, but if I install wine, I don't have the choice to have apt-get _not_
divertedâ¦
The reasons for ia32-apt-get are this:
- multiarch is still not there.
- ia32-libs source with all the additional request libs grows to about
1GB in size of which everything is pure duplication.
- ia32-libs contains so many libs that it needs a new upload every
other day (or is constantly out of sync like it always was).
- ia32-libs can only cover unstable or testing but not both.
- ia32-libs has no security support but security bugs.
- ia32-libs doesn't ensure library versions are new (or old) enough
to work with 3rd party debs. They easily miss a library or get a
wrong version.
- ftp-master has vetoed splitting ia32-libs into individual packages
and shown a strong dislike to ia32-libs as it was.
- ia32-libs doesn't allow to install 3rd party 32bit debs or use 3rd
party apt repositories with 32bit packages.
I very much understand all those reasons. I still think that the actual
response ia32-apt-get provides is actually not good enough to let things
like wine rely on.
I would largely prefer if ia32-* in its actual shape would be released in
experimental (where, with this level of touching the base of Debian
repositories handling, it should sit) and version 2.7 uploaded back in
Sid...
Conflicts with libc6-i386.
Regards,
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe
Re: ia32-libs depends on ia32-apt-get ?
Didier Raboud did...@raboud.com writes:
Goswin von Brederlow wrote:
Didier 'OdyX' Raboud did...@raboud.com writes:
Goswin von Brederlow wrote:
Didier 'OdyX' Raboud did...@raboud.com writes:
Norbert Preining wrote:
- calling /usr/share/ia32-apt-get/convert-all-sources.list
Which horribly breaks with anything a little custom (proxies, custom
repositories, ...) and fills your /etc/apt/sources.list.d/ with
ia32-apt- get.{i386,amd64} copies of all your pet sources.
Examples please.
Hi Goswin,
Here is an example from my laptop :
(...)
Is that enough of an example ?
Not realy. None of your entries causes an error. They all convert
perfectly.
What do you mean no valid repository? Are you trying to use them
without first having called apt-get update to actualy create the
index files they reference? So far everything you have shown is as
designed.
Okay. This is #533746 then. I do always use aptitude (both command-line only
and with the curses interface) and never apt-get. You cannot expect me to
use apt-get AFAIK.
While installing wine (e.g) with aptitude, I cannot except to get new
archives added to my sources.list which should be somehow mangled by a
wrapper around apt-get, which I should begin to use instead of aptitude.
s/apt-get/aptitude/g is really too much of an intrusion in the way I admin
my machines... Sorry.
It is work in progress. For now you will have to apt-get update and
then you can use aptitude for everything else.
I never use aptitude and after doing a test upgrade of an older sid to
current with aptitude I'm verry much affirmed on that. The last ~50
packages I upgraded with apt-get upgrade again because the aptitude
interface just wouldn't just do it.
Aptitude even suggested I downgrade some package from 1.2-3 (64bit
flavour) to 1.2-3~18 (32bit flavour) despite the later being pinned
down. That is just horribly broken. apt-get just updated the package
and its dependency instead.
MfG
Goswin
I feel good intentions, but a poor result. This really seems a big plaster
on a wooden leg.
Regards,
OdyX
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Lionel Elie Mamane lio...@mamane.lu writes: While we are on the subject of ia32-apt-get, I'm not sure _what_ happened, but after the upgrade of ia32-apt-get 14 to 18, suddenly aptitude had about 200 package in upgradable state that were not upgradable before. ia32-apt-get encodes its own version into the version of converted packages. That way every time the converter fixes some bug all converted packages get upgraded to a new version. That might not be always neccessary but generally is. So this is totaly expected. The issue is I don't remember for sure what /etc/apt/sources.list looked like before the upgrade, but now it is: lion...@harif:/etc/apt$ cat preferences Package: * Pin: release a=testing Pin-Priority: 600 Better add the pinings from /usr/share/doc/ia32-apt-get/NEWS.Debian.gz as well. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Mehdi Dogguy mehdi.dog...@pps.jussieu.fr writes: Josselin Mouette wrote: Hi, as the topic says, I noticed the new ia32-libs package depends on ia32-apt-get. I searched the list archive and found only one thread[1] related to ia32-apt-get. Correct me if I'm wrong but it was clear for me, when reading comments, that the solution was not acceptable and no consensus was reached. So why was it uploaded without further discussions on the list? Because there where no ideas brought forward to discuss. There where 3 options: 1) ia32-libs + ia32-libs-gtk (+ ia32-libs-kde + ia32-libs-qt) ftp-master asked us to clean that up basically and it would not pass NEW if it where uploaded now 2) ia32-lib* packages in the same schema as ia32-libs vetoed by ftp-master for being way to many packages as ugly as ia32-libs 3) ia32-apt-get So strike option 1 and 2 and what are you left with? Shouldn't be uploaded into experimental instead of unstable? ⦠Do you The libc6-i386 lib32 transition was easier done by switching to ia32-apt-get now than to rewrite ia32-libs for it. So that kind of forced the issue. consider it as a âreleasableâ solution? Going to be. How would aptitude users do now? apt-get update; aptitude [1] http://lists.debian.org/debian-devel/2009/03/msg01849.html Cheers, MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Lionel Elie Mamane lio...@mamane.lu writes: On Mon, Jun 29, 2009 at 03:57:28PM +0200, Goswin von Brederlow wrote: Lionel Elie Mamane lio...@mamane.lu writes: While we are on the subject of ia32-apt-get, I'm not sure _what_ happened, but after the upgrade of ia32-apt-get 14 to 18, suddenly aptitude had about 200 package in upgradable state that were not upgradable before. ia32-apt-get encodes its own version into the version of converted packages. That way every time the converter fixes some bug all converted packages get upgraded to a new version. That might not be always neccessary but generally is. So this is totaly expected. Well, I most certainly didn't have 200 i386 packages installed, I must have had maybe 10 of them, so this cannot be the complete explanation. When I do a spot check on a few specific packages, it seems I went from testing to unstable. For example, take cheese: [UPGRADE] cheese 2.24.3-2 - 2.26.2-1 It went from the squeeze version to the sid version. So the behaviour is as if squeeze had been dropped from my sources.list. Ah, but I have daily backups of that machine! Let's see. Yes! That's it. The upgrade removed squeeze from my sources.list. Here is my sources.list before the upgrade: deb http://ftp.nl.debian.org/debian/ squeeze main contrib non-free deb http://ftp.nl.debian.org/debian/ sid main contrib non-free deb-src http://ftp.nl.debian.org/debian/ sid main contrib non-free deb http://security.eu.debian.org/ squeeze/updates main contrib non-free deb-src http://security.eu.debian.org/ squeeze/updates main contrib non-free ### ia32-apt-get entries ### #deb http://ftp.surfnet.nl/os/Linux/distr/debian/ lenny-i386 main #deb http://ftp.surfnet.nl/os/Linux/distr/debian/ sid-i386 main #deb http://security.eu.debian.org/ lenny/updates-i386 main After, no trace of squeeze anymore. Filing a bug. Since that was with ia32-apt-get prior to version 15 the relevant sources.list file would have been /etc/apt/native/sources.list. I suspect you added squeeze to /etc/apt/sources.list after installing ia32-apt-get the first time and possibly removing (but not purging) it. I should probably add a debconf question there asking what to do instead of restoring the sources.list from before ia32-apt-get. The issue is I don't remember for sure what /etc/apt/sources.list looked like before the upgrade, but now it is: lion...@harif:/etc/apt$ cat preferences Package: * Pin: release a=testing Pin-Priority: 600 Better add the pinings from /usr/share/doc/ia32-apt-get/NEWS.Debian.gz as well. The example in there seems to be missing transitional-i386 and maybe also transitional? Only 2 arch:all meta packages there and the -amd64 or transitional one will always be a higher version. I will probably filter the transitional-$(arch) entries out in the future as they are completly useless and confusing (but not harmfull in any way). -- Lionel MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Josselin Mouette j...@debian.org writes: Le lundi 29 juin 2009 à 17:30 +0200, Goswin von Brederlow a écrit : consider it as a âÂÂreleasableâ solution? Going to be. No, it is not going to be. The whole design needs work before it can be. There is a better design. It is called multiarch. But some people are blocking that. How would aptitude users do now? apt-get update; aptitude And how would synaptic users do? apt-get update; synaptic Do you see a pattern? In synaptic Edit-Reload package information needs to be adapted and Settings-Repositories. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Mark Brown broo...@sirena.org.uk writes: On Mon, Jun 29, 2009 at 06:12:20PM +0200, Norbert Preining wrote: On Mo, 29 Jun 2009, Mark Brown wrote: Multiarch was mentioned in the original thread. Not that I was happy with the original situation (filing myself a bug), but all that multiarch blabla and nothing is going forward in this direction, so this is not a reasonable solution until nobody steps forward and does the work for that. There seems to be at least some crossover between the people who were looking at multiarch and the people doing this stuff. But not the people blocking the inclusion of patches for multiarch already present in the BTS. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Raphael Hertzog hert...@debian.org writes: On Mon, 29 Jun 2009, Norbert Preining wrote: On Mo, 29 Jun 2009, Mark Brown wrote: Figure out an acceptable option 4. Multiarch was mentioned in the original thread. Not that I was happy with the original situation (filing myself a bug), but all that multiarch blabla and nothing is going forward in this direction, so this is not a reasonable solution until nobody steps forward and does the work for that. There is work going on recently. Steve Langasek drafted a plan that he wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a reality inside Debian but I don't know of any timeframe. https://wiki.ubuntu.com/MultiarchSpec Cheers, Too bad they did that without involving the people already working on multiarch via the alioth project. They messed up some finer details, broke the existing patches, made the whole thing need a full release cycle for a transition due to DEBIAN/control format changes and have a broen plan for -dev packages. Guillem Jover is also blocking the inclusion of already existing patches for multiarch. Frustrated, Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Josselin Mouette j...@debian.org writes: Le lundi 29 juin 2009 à 21:30 +0200, Goswin von Brederlow a écrit : Josselin Mouette j...@debian.org writes: No, it is not going to be. The whole design needs work before it can be. There is a better design. It is called multiarch. But some people are blocking that. Identify the blockers. Work with people interested in this, so that Currently the blocker is Guillem Jover guil...@debian.org as you can see in Bugs #528205, #528140, #528143, #528194, #528198, #528141. I stopped filing more after that. As said in the bugs I've taken the discussion to debian-dpkg: http://lists.debian.org/debian-dpkg/2009/05/msg00031.html As you can see it just hits the wall of silence. Same thing that happened to the binutils, gcc and dpkg patches for years now. This really makes me wonder. Don't they want to have multiarch support in Debian? Do they want Ubuntu to have it first and be the saviour of Debian? appropriate action is taken. If people are working against it, we can invoke the TC. All of this, if you do things by the rules. If you continue to push broken software, we will have no other solution but to remove them from the archive. How would aptitude users do now? apt-get update; aptitude And how would synaptic users do? apt-get update; synaptic Do you see a pattern? Yes, I see that you donât understand that ia32-apt-get is FUBAR. ia32-libs and ia32-atpt-get is a dirty ugly horrible hack. That is why over 5 years ago some people got together and worked out the multiarch proposal. Ia32-apt-get is a bandaid to tie people over till finally multiarch comes. It is the best that can be done with mutliarch still being blocked. In synaptic Edit-Reload package information needs to be adapted and Settings-Repositories. No. Adapting each and every APT frontend is not the way to go. Adapting the backend is fine too and for the update part that might totally suffice. But you won't be able to avoid patching Settings-Repositories to know about multiarch. That is changing the sources.list files so it will have to know about extensions to its syntax. Same with aptitude. The update part can most probably be done in libapt but aptitudes peculiar depenency resolver will have to be adapted too. That is what you get for writing your own. And mind that I'm not talking about just ia32-apt-get but multiarch in general. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Raphael Hertzog hert...@debian.org writes: On Mon, 29 Jun 2009, Goswin von Brederlow wrote: Too bad they did that without involving the people already working on multiarch via the alioth project. They messed up some finer details, broke the existing patches, made the whole thing need a full release cycle for a transition due to DEBIAN/control format changes and have a broen plan for -dev packages. Guillem Jover is also blocking the inclusion of already existing patches for multiarch. I'm sorry but I have much more confidence in Guillem's and Steve's technical abilities than in yours. Then maybe you also have some confidence in Tollef Fog Heen, Matt Taggart, Anthony Towns, Aurelien Jarno. And hey, even Guillem Jover itself. He did participate in the Informal multiarch meeting during FOSDEM on 26/02/2006 in Brussels. See the various links on http://wiki.debian.org/multiarch for the work on multiarch going back to 2004. I can understand your frustration but you never offered a viable and clean long-term solution. Sending patches to dpkg to add/enable a Multi-Arch field without making use of it and/or explaining the whole plan and rationale is far from good. I would also not merge patches without knowing if the full plan is credible. I wrote or updated patches that implement the design proposed over and over again since 2004, talked about at debconf, documented in the wiki and mailinglists. I asked Guillem Jover what he thinks is missing to represent a viable and clean long-term solution. He is not interested and I'm tired of posting the same information that has already been posted. This is not just my crazy ideas, I'm just fighting bit-rot. Cheers, MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Yannick yannick.roeh...@free.fr writes: Goswin von Brederlow wrote: There where 3 options: 1) ia32-libs + ia32-libs-gtk (+ ia32-libs-kde + ia32-libs-qt) ftp-master asked us to clean that up basically and it would not pass NEW if it where uploaded now 2) ia32-lib* packages in the same schema as ia32-libs vetoed by ftp-master for being way to many packages as ugly as ia32-libs 3) ia32-apt-get So strike option 1 and 2 and what are you left with? Isn't it possible to have a system similar to apt-build? One would do ia32-apt-convert ia32-libfoo that would convert libfoo 32bits /usr/lib/ia32-libs-tools/convert amd64|ia64 libfoo_1.2-3_i386.deb package and its dependencies, put it in a local repository. Then the user could install ia32-libfoo with apt-get, aptitude, whatever. apt-get install ia32-archive It is probably slightly out of sync with ia32-apt-get because the libc6-i386 upload forced a bit of a rush job on the latest changes but if you look at it you get the idea. Once I have time to verrify ia32-archive still works right and have time to introduce an ia32-remote-archive dummy package I will probably change ia32-libs to Depends: ia32-apt-get | ia32-archive | ia32-remobe-archive. Yannick PS: Of course, there would be a ia32-apt-update to update all the ia32-* installed. ia32-archive already has a hook in /etc/apt/apt-conf.d/ that does that automatically on update. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Aneurin Price aneurin.pr...@gmail.com writes: Hi, I've just spent over an hour writing and rewriting this mail, and determined that I can't think of a single constructive thing to say. So I'll just ask a couple of questions instead: Is there any way of preventing this kind of major breakage in the future? I don't think many people expect that upgrading one package will FUBAR the packaging system. Is there any chance of Wine becoming functional on amd64 in the forseeable future? # apt-get install ia32-wine Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: ia32-libwine ia32-libwine-alsa ia32-libwine-cms ia32-libwine-gl ia32-libwine-gphoto2 ia32-libwine-ldap ia32-libwine-print ia32-libwine-sane ia32-wine-bin ia32-wine-utils Suggested packages: wine-doc binfmt-support ttf-mscorefonts-installer winbind avscan klamav clamav Recommended packages: ttf-liberation The following NEW packages will be installed: ia32-libwine ia32-libwine-alsa ia32-libwine-cms ia32-libwine-gl ia32-libwine-gphoto2 ia32-libwine-ldap ia32-libwine-print ia32-libwine-sane ia32-wine ia32-wine-bin ia32-wine-utils 0 upgraded, 11 newly installed, 0 to remove and 187 not upgraded. Need to get 11.0MB of archives. After this operation, 51.4MB of additional disk space will be used. Do you want to continue [Y/n]? y ... % winemine Have fun. Works both with sid and experimental wine. Provided you have a lib32ncurses5 and lib32readline5 with the lib32 transition completed that is. Bug the respective maintainers for that one. Did anyone who isn't on crack get to see 'ia32-apt-get.preinst' and 'ia32-apt-get.postinst' before they were perpetrated upon an unsuspecting populace? Reading them in the process of trying to unfuck my system made me feel more than slightly ill. Since my package was sponsored I would assume at least one other person looked over it. You are the first to mention illness. I can't change what it does. But do you have suggestion to improve how it does things in preinst/postinst/postrm? Latest source is on svn.debian.org pkg-ia32-libs: http://svn.debian.org/wsvn/pkg-ia32-libs/trunk/ia32-libs-tools/#_trunk_ia32-libs-tools_ -Nye MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted ia32-libs-tools 17 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 27 Jun 2009 20:07:13 +0200 Source: ia32-libs-tools Binary: ia32-libs-tools ia32-archive ia32-apt-get ia32-libs ia32-libs-gtk Architecture: source all amd64 Version: 17 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Description: ia32-apt-get - Apt-get and dpkg wrapper for on-the-fly ia32-libs conversion ia32-archive - Create a local archive of converted i386 debs for amd64 and ia64 ia32-libs - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-gtk - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-tools - Tools for converting i386 debs for amd64 and ia64 Changes: ia32-libs-tools (17) unstable; urgency=low . * Undo wine renaming, conflicts with removeing binaries from lib packages. * ia32-apt-get / ia32-archive: Depend on ia32-libs-tools (= 16). * apt-get.in: Handle apt-get errors during update. * Fix deb-src handling: + Copy *_Sources from arch subdir to main dir. + Include *_Sources in release file. + Remove deb-src from converted sources.list files. * convert: Include package name in fresh changelog when /usr/share/doc/package is a link. Avoids overrite errors. * convert: Move include files to DEB_HOST_GNU_TYPE dir. * ia32-libs: Remove ia32-libnss-ldap and ia32-libpam-ldap because it needs special configuration. Checksums-Sha1: 78d581f7fa84574c8d1b883f9fa450910e5108e8 981 ia32-libs-tools_17.dsc a63e2377afe1796f141ad55676c078b63122117a 29732 ia32-libs-tools_17.tar.gz 601d7766fc7ca6425e6f04138f771ccda9a7cf70 9294 ia32-archive_17_all.deb ee523f15f4e20721bad0ba54d7894f55c7a658ea 20058 ia32-apt-get_17_all.deb aae3d949872b3fc9200b70ff2d48fbb579737466 40892 ia32-libs-tools_17_amd64.deb 8cdf27764aa959134e746f4645d9411c0432d896 4224 ia32-libs_17_amd64.deb d88e647adec077ed2f61649691aa8c35c4a3323d 4262 ia32-libs-gtk_17_amd64.deb Checksums-Sha256: 8cbe665d79c1ebb894270ebc67a51b0976b8492bd8c097b45587f14fe2442871 981 ia32-libs-tools_17.dsc bedd0fcf1a1cd7437677a9dc9104325ac910529f3cb796dabad60789fade2eec 29732 ia32-libs-tools_17.tar.gz 83bc7b70359fdbfd5cb7292a40b67463711b611ca52879102f6dd66c08d1d457 9294 ia32-archive_17_all.deb 4599d4941d0781420591bfcb710af10ecd7bad8c7637cbdc4d51c450b944d395 20058 ia32-apt-get_17_all.deb 3a34018250641b20d22c5173e37133a4736dad3217e646831cdd260937cd61db 40892 ia32-libs-tools_17_amd64.deb 2918432d514b963e04544db6a1891ef623ea409e1b83b9302ba9ad5802259439 4224 ia32-libs_17_amd64.deb fdef6f170491692c2db3c046cbc29f832f26dfbabb229fe2dddf7528073daffa 4262 ia32-libs-gtk_17_amd64.deb Files: c40063f739f2c361bbcbe5f93e218614 981 devel extra ia32-libs-tools_17.dsc 855caf7cd9ea9c9378e4ce06a6a5dc0f 29732 devel extra ia32-libs-tools_17.tar.gz 7bdb1e17eb0d161d45e4661ac35b996c 9294 devel extra ia32-archive_17_all.deb e29e2737c7b2832a740f8ccd2826a223 20058 devel extra ia32-apt-get_17_all.deb 30d96b881329c4d197a46a712ef9aebc 40892 devel extra ia32-libs-tools_17_amd64.deb 3cd80cec290e701ff735e96881bb233d 4224 devel extra ia32-libs_17_amd64.deb 886ac65b4e6f0372371eb4c798787576 4262 devel extra ia32-libs-gtk_17_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpGgW0ACgkQj3BimscY00f5JQCfY9fKOuXhyXtyNWfZvTuItFc9 8XQAn0j0gY/SZOlV0TV53bD3BddUo/r7 =JDD7 -END PGP SIGNATURE- Accepted: ia32-apt-get_17_all.deb to pool/main/i/ia32-libs-tools/ia32-apt-get_17_all.deb ia32-archive_17_all.deb to pool/main/i/ia32-libs-tools/ia32-archive_17_all.deb ia32-libs-gtk_17_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs-gtk_17_amd64.deb ia32-libs-tools_17.dsc to pool/main/i/ia32-libs-tools/ia32-libs-tools_17.dsc ia32-libs-tools_17.tar.gz to pool/main/i/ia32-libs-tools/ia32-libs-tools_17.tar.gz ia32-libs-tools_17_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs-tools_17_amd64.deb ia32-libs_17_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs_17_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted ia32-libs-tools 18 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 27 Jun 2009 22:25:51 +0200 Source: ia32-libs-tools Binary: ia32-libs-tools ia32-archive ia32-apt-get ia32-libs ia32-libs-gtk Architecture: source all amd64 Version: 18 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Description: ia32-apt-get - Apt-get and dpkg wrapper for on-the-fly ia32-libs conversion ia32-archive - Create a local archive of converted i386 debs for amd64 and ia64 ia32-libs - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-gtk - ia32 shared libraries for use on amd64 and ia64 systems ia32-libs-tools - Tools for converting i386 debs for amd64 and ia64 Closes: 484599 531515 533362 533573 534237 Changes: ia32-libs-tools (18) unstable; urgency=low . * Fixes for wine + rename.list: rename wine again + mangle.cc: add Conflicts/Replaces for wine debs + hooks: don't remove binaries in wine debs, don't move /usr/lib/wine . ia32-libs-tools (17) unstable; urgency=low . * Undo wine renaming, conflicts with removeing binaries from lib packages. * ia32-apt-get / ia32-archive: Depend on ia32-libs-tools (= 16). * apt-get.in: Handle apt-get errors during update. * Fix deb-src handling: + Copy *_Sources from arch subdir to main dir. + Include *_Sources in release file. + Remove deb-src from converted sources.list files. * convert: Include package name in fresh changelog when /usr/share/doc/package is a link. Avoids overrite errors. * convert: Move include files to DEB_HOST_GNU_TYPE dir. * ia32-libs: Remove ia32-libnss-ldap and ia32-libpam-ldap because it needs special configuration. . ia32-libs-tools (16) unstable; urgency=low . * mangle.cc: Don't change version in depends on binaries. * rename.list: Add libc-dev - lib32c-dev, rename wine debs too. * convert: Add hack to remove conflicting conffiles and shared data. * dpkg-deb: exit 1 if conversion fails. * dpkg-deb: mangle shlibs files. * hooks: Fix libpango and libgtk, add libwmf0.2-7.hook. . ia32-libs-tools (15) unstable; urgency=low . * Add pre-depends on libc6-i386/ia32-libc6 (= 2.9-18~~) to packages. * Add conflicts with ia32-libs and ia32-libs-gtk to packages. * Take over ia32-libs and ia32-libs-gtk. (Closes: #533362, #484599) + Add ia32-libs and ia32-libs-gtk transitional package pool. + Add ia32-libs and ia32-libs-gtk dummy packages. + Create a local gnupg key on install and add it to apt. * Drop -b from dch --create call to stop it pausing for RETURN. * Add hack for ia32-libgphoto2-2. * Drop the /emul/ia32-linux prefix and use lib32 on Debian too. (Closes: #533573, #534237) * Support dpkg-deb --control -- and -D. (Closes: #531515) [again] * Fix File:// url parsing in apt-get. * Change to new config format for policy compliance. Checksums-Sha1: 0f77837e859aab93e90f4acadb20e2699abb12f2 981 ia32-libs-tools_18.dsc 6e8499257b70f261fb8061eeca1c831a234cd632 30048 ia32-libs-tools_18.tar.gz 80c38cc3b5cc9078cbe558301edd40609877bb9d 9358 ia32-archive_18_all.deb 9ac3a61ac237e19e9417883174a6e08f52643285 20108 ia32-apt-get_18_all.deb 44c9b6838c060152388249953b754d46925ea2d0 42512 ia32-libs-tools_18_amd64.deb 4a3387f8e30d2f53e929d62cd70482205de11361 4288 ia32-libs_18_amd64.deb 7966ed6124332ba63f1186c6a0423cf82bddf6bc 4322 ia32-libs-gtk_18_amd64.deb Checksums-Sha256: 1a0a7735ac18e2d695d6584b4a7d676442ef7812ff396f9e5778a1b7a470686b 981 ia32-libs-tools_18.dsc efa543b806b1d2d4728e532fef822698571b5dceea418e65827bd63e3f7e3bfd 30048 ia32-libs-tools_18.tar.gz 476f33191c08e86609ea9663397c2db32f344f75d8149b3ac1bd35f1a3e49698 9358 ia32-archive_18_all.deb 9a80293348ad57273058abfac23185df4d3686a9a3e2289730919b0310299466 20108 ia32-apt-get_18_all.deb 2af34e8c620aeead3425e1b08d295536ce09bd685fe3dba26f0c71c69d4ca33d 42512 ia32-libs-tools_18_amd64.deb 95f75e371b83cb4b8f40941fb9d5dde737befcdd924e76b49a0249c13c3c3a71 4288 ia32-libs_18_amd64.deb 6f315673d67a8ff946fe98898ff8f7b922ddd739a92b8c8d5d63103f0cb4b99d 4322 ia32-libs-gtk_18_amd64.deb Files: 25a037eb626b8a45a4e6b5ad264d1e83 981 devel extra ia32-libs-tools_18.dsc 664a8b012dcd1a81a369f7d9d5109025 30048 devel extra ia32-libs-tools_18.tar.gz 64a1082028eefd4206ee939b817e51fa 9358 devel extra ia32-archive_18_all.deb 3561a5ea26187a317f2c1b17c89a27b5 20108 devel extra ia32-apt-get_18_all.deb ea67a8388e2b8a97fc692b7cd0659266 42512 devel extra ia32-libs-tools_18_amd64.deb de82ca254efe35f5aec6e2ec09c823b2 4288 devel extra ia32-libs_18_amd64.deb 101f6bab89c521691debc14107a9b755 4322 devel extra ia32-libs-gtk_18_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpGkjcACgkQj3BimscY00cG+wCeNTE0+U3q9sI638rJVduuioPc DtMAnjrU1A5fmxXd7Qhgood0u6g0a7li =lZwj -END PGP SIGNATURE- Accepted: ia32-apt-get_18_all.deb
Re: apt-get wrapper for maintaining Partial Mirrors
Joseph Rawson umebos...@gmail.com writes: On Sunday 21 June 2009 03:33:33 Goswin von Brederlow wrote: snip The Release could be signed using an rsign method with the machine(s) that manage the repository, or it could be done locally on the server using gpg-agent, or an unencrypted private key, depending on how the administrator prefers to manage it. The simplest implementation would be a tiny proxy applet that, when a deb file is requested, checks if the file is in the local archive. If it is then send it. If not then request file from upstream and pipe it to apt (no latency) and a tempfile. When the download has finished then reprepro --include suite deb. Doing the same for source is a little more tricky as you needs the dsc and related files as a group. I don't understand the tempfile part. Otherwise, that's a better idea, since my idea depended on running reprepro update, then sending the appropriate debs. A tempfile so after download the proxy can run: reprepro include sid foo.deb MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /emul/ia32-linux to lib32 transition
Artur R. Czechowski artu...@hell.pl writes: Hello, I made a quick glance at /emul/ia32-linux to lib32 transition in BTS. There was some bugreports submitted. All I spotted can be seen using following link: http://42.pl/u/1GEo Shouldn't all of them be set to RC severity as they are uninstallable at the moment? Additionaly, I've found that ia32-libs and ia32-libs-gtk has no bugreport for transition submitted. Regards Artur -- ¦wiêta mog± byæ Twoje! Pakiet podstawowy ju¿ od 9,99 (bez karpia i choinki) /yacoob/ There are enough bug reports about it breaking due to the transition already. The bugs subject just differs from the other reports. It's also fixed in svn of ia32-libs-tools and pending a sponsor. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: cc vs gcc
brian m. carlson sand...@crustytoothpaste.ath.cx writes: On Sun, Jun 21, 2009 at 10:29:37PM +0300, Peter Eisentraut wrote: There is a bit of discussion in bug #487546 about whether using cc or gcc as the compiler is appropriate. Particular questions: * Are Debian packages supposed to be built by default using /usr/bin/gcc (or whatever gcc is first in the path)? Or is it valid to use cc? cc has traditionally been the system-default compiler for a Unix system. Generally, it will support those options specified by POSIX for c99, since those are a fairly barebones set of options, but it is not mandated to (since it is not specified). Since Debian has it specified as an alternative, I would assume that any C compiler which implements those options would be satisfactory. Whether cc is a valid choice depends on whether the code will work with any such compiler. If a program requires GCC, then it should specify gcc; if any old compiler will work, then cc should be fine. That fails the reproducable test. All uploaded packages should always be build with the same compiler, the debian default gcc, unless a specific compiler is specified in rules. So I would say using cc is wrong. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: apt-get wrapper for maintaining Partial Mirrors
Joseph Rawson umebos...@gmail.com writes: On Saturday 20 June 2009 03:16:33 Goswin von Brederlow wrote: But now you made me think about this too. So here is what I think: - My bandwidth at home is fast enough to fetch packages directly. No need to mirror at all. - I don't want to download a package multiple times (once per host) so some shared proxy would be good. My idea would keep that from happening, at the expense of latency. The latency would be minimal, as it would just be dependant on reprepro retrieving the package(s) and signalling the client that the package is ready. Using reprepro to add extra packages to the repository from upstream without doing a full update may not be possible, but if it were, the latency would certainly be minimum, and the bandwidth to the internet would also be minimum. I just looked at the manpage again, and this may be possible by using the --nolistsdownload option with the update/checkupdate command. - Bootstraping a chroot still benefits from local packages but a shared proxy would do there too. - When I'm not at home I might not have network access or only a slow one so then I need a mirror. And my parents computer has a Linux that only I use and that needs a major update every time I vistit. So the ideal setup would be an apt proxy that stores the packages in the normal pool structure and has a simple command to create Packages.gz, Sources.gz, Release and Release.gpg files so the cache directory can be copied onto a USB disk and used as a repository of its own. Getting reprepro to do this would save a lot of the hassle, but getting reprepro to act as an apt proxy is also tricky. The current cache and proxy methods in the apt-proxy and apt-cache packages don't work as well in making a good repository, as opposed to reprepro. The Release could be signed using an rsign method with the machine(s) that manage the repository, or it could be done locally on the server using gpg-agent, or an unencrypted private key, depending on how the administrator prefers to manage it. The simplest implementation would be a tiny proxy applet that, when a deb file is requested, checks if the file is in the local archive. If it is then send it. If not then request file from upstream and pipe it to apt (no latency) and a tempfile. When the download has finished then reprepro --include suite deb. Doing the same for source is a little more tricky as you needs the dsc and related files as a group. Optional the apt proxy could prefetch package versions but for me that wouldn't be a high priority. Nice would be that it fetches sources along with binaries. When I find a bug in some software while traveling I would hate to not have the source available to fix it. But then it also needs to fetch Build-depends and their depends. So that would complicate matters a lot. I mentioned that part above. MfG Goswin Overall, I think that reprepro does a good job of maintaining a local repository, and we shouldn't reimplement what it does. Reprepro also seems flexible enough to implement most of the backend with simple commands and options. I've never tried to implement a new apt-method before, so I think that would take a bit more research from me. I totally agree that reprepro as the cache/storage backend would be great use of existing software. The problem I have with it being an apt method is that the apt method runs on a different host than the reprepro. That would require ssh logins from all participating clients or something to alter the reprepro filter. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: apt-get wrapper for maintaining Partial Mirrors
Joseph Rawson umebos...@gmail.com writes: On Friday 19 June 2009 12:57:25 Goswin von Brederlow wrote: Or have a proxy that adds packages that are requested. When I woke up this morning, I was thinking that it might be interesting to have an apt method that talks directly to reprepro. It's just a vague idea now, but I'll give it some more thought later. Way too much latency to mirror a deb when requested and you need to run apt-get update for it to show up. The best you can do is add the package to the filter list and then fetch it directly. Then the next night the mirror will pick it up for future updates. But now you made me think about this too. So here is what I think: - My bandwidth at home is fast enough to fetch packages directly. No need to mirror at all. - I don't want to download a package multiple times (once per host) so some shared proxy would be good. - Bootstraping a chroot still benefits from local packages but a shared proxy would do there too. - When I'm not at home I might not have network access or only a slow one so then I need a mirror. And my parents computer has a Linux that only I use and that needs a major update every time I vistit. So the ideal setup would be an apt proxy that stores the packages in the normal pool structure and has a simple command to create Packages.gz, Sources.gz, Release and Release.gpg files so the cache directory can be copied onto a USB disk and used as a repository of its own. Optional the apt proxy could prefetch package versions but for me that wouldn't be a high priority. Nice would be that it fetches sources along with binaries. When I find a bug in some software while traveling I would hate to not have the source available to fix it. But then it also needs to fetch Build-depends and their depends. So that would complicate matters a lot. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: apt-get wrapper for maintaining Partial Mirrors
Joseph Rawson umebos...@gmail.com writes: On Friday 19 June 2009 00:27:06 Goswin von Brederlow wrote: Joseph Rawson umebos...@gmail.com writes: If so then you can configure a post invoke hook in apt that will copy the dpkg status file of the host to the server [as status.$(hostname)] and then use those on the server to generate the filter for reprepro. I think I still have a script for that somewhere but it is easy enough to rewrite. That's good for binaries, but I don't know about the source. It wasn't long ago that I noticed a problem with reprepro not obtaining the corresponding source packages when you use a filter list taken from dpkg --get-selections. I remember that the source for jigdo wasn't in my partial mirror, because there were no binaries named jigdo, rather jigdo-file and jigdo-lite. Since there were no sources with that name, the jigdo source was never mirrored on my partial mirror. I don't know if that behavior has been fixed now, since there is now a binary named jigdo, instead of jigdo-lite. My filter first converted the packages listed in the status file(s) to source package names (packages with different name have a Source: entry) and then output those for sources. Also, it's more difficult for the local repository to determine the difference between the automatically selected and manually selected packages in this type of setup, since you would be sending a longer list of manually selected packages, instead of distinguishing which ones are actually selected. I guess that it doesn't matter much, as a package would only be removed from the repository once it's not listed on any of the lists. There were times when I didn't want certain packages to be removed from the repository, regardless of whether they were installed or not, so I used to run xxdiff on the packages files, so the newer ones were added. Same problem here. Esspecially build-depends. There where a lot of packages I only needed inside my build chroots and only for the time of the build. So they never showed up on the mirror. Then I just resized the mirror partition and mirrored all debs. In my way of thinking, I'm not looking to merge upstream repositories together in one repository. Besides, there are already tools, such as apt-move that would be better for this job. Long ago, apt-move was the primary tool that I used to keep a local repository, and it worked pretty well, as long as all the machines that were using it were on the same release. I have found that reprepro is the absolute best tool for maintaining a debian mirror. The only problem I have with it is when I want to maintain a partial mirror, and I don't want a merged repository, is that I have to spread the packages lists to different places, and when you start adding machines, you start adding more lists to the configuration, when it would probably be better to maintain a set of master lists that are generated from the many lists that come from the machines. Or have a proxy that adds packages that are requested. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: apt-get wrapper for maintaining Partial Mirrors
Joseph Rawson umebos...@gmail.com writes: There is another application that will help with the dependencies. It's called germinate, and it will take a short list of packages and a list of repositories and build a bunch of different lists of packages and their dependencies. Germinate will also determine build dependencies for those packages and recursively build a list of builddeps and the builddeps' builddeps. I have thought of making an application that would get germinate and reprepro to work together to help build a decent partial mirror that had the correct set of packages, but the process was a bit time consuming. It's been a while Was it that bad? It only needs to run 4 times a day when the mirror push comes in. since I've worked on this, since my temporary solution to the problem was to buy a larger hard drive. Currently, I have a full mirror that I keep updated, and a repository of locally built packages next to it. I'm not really happy with this solution, as it uses too much disk space and I'm downloading packages that will never be used, but it's given me time to tackle more important problems. Before writing any code, I would recommend taking a look at both reprepro and germinate, as each of these applications is good at solving half of the problems you describe. I think that an ideal solution would be to write a frontend program that takes a list of packages and upstream repositories, feeds them into germinate, obtains the result from germinate, parse those results and build a reprepro configuration from that, then get reprepro to fetch the appropriate packages. Combining germinate and reprepro is the right thing to do. Or reprepro and a new filter instead of germinate. But don't rewrite reprepro. Given a little bit of care when writing the reprepro config this can be completly done as part of the filtering. There is no need for a seperate run that scanns all upstream repositories as long as you can define a partial order between them, i.e. contrib needs things from main but main never from contrib. That would also have the benefit that you only need to process those packages files that have changed. I would be happy to help with this, as I could use such an application, and I already have a meager bit of python code that parses the output of germinate (germinate uses a wiki-type markup in it's output files). I stopped working on the code since I bought a new hard drive, since I just used the extra space to solve the problem for me, but I can bring it back to life, as I would desire to use a more correct solution. Urgs, that sucks. It should take a Packages/Sources style input and output the same format. Maybe rewriting it using libapt would be better than wrapping germinate. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: apt-get wrapper for maintaining Partial Mirrors
Frank Lin PIAT fp...@klabs.be writes: On Tue, 2009-06-09 at 16:16 -0500, Joseph Rawson wrote: On Tuesday 09 June 2009 13:14:53 sanket agarwal wrote: This can be stated as: if a person wants to keep a customised set of packages for usage with the distribution, the tool should be able to develop dependencies, fetch packages, generate appropriate documentation and then create the corresponding directory structure in the target mirror! The task can be extended to include packages which are currently not under one of the standard mirrors! lazy-way One don't have to merge the repositories, one can just declare multiple sources in /etc/apt/* /lazy-way Lets say I want to mirror xserver-xorg from experimental. Then I would want it to include xserver-xorg-core (= xyz) also from experimental as the dependency dictates but not include libc6 from experimental as the sid one is sufficient. A key point here would be flexibility. I think the tool can have immense utility in helping people automate the task of mantaining the repositories. Suggestions, positive and negative are invited. I have not included the impl details as I would first like to evaluate the idea at a feasibility and utility level. If the scope of your project includes being able to bootstrap systems from the mirror, resolving dependency is much more complex (some packages aren't resolved by dependencies. For instance, the right kernel is select by some logic in Debian-installer). I found some interesting logic in debian-cd package. You would include linux-image-type in your package list. That isn't really a problem of the tool. Just of the input you need to provide. Also you would include everything udeb and everything essential/required for bootstraping purposes. Again flexibility is the key. Still, I don't consider that allowing bootstrapping is mandatory. Your project would still be extremely valuable without it. [for those 95% of the people that install from CD, as opposed to netboot]. Regards, Franklin MfG Goswin PS: the essential/required packages can already easily be filtered with grep-dctrl. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: apt-get wrapper for maintaining Partial Mirrors
Joseph Rawson umebos...@gmail.com writes: BTW, the subject of this thread is apt-get wrapper for maintaining Partial Mirrors. The solution I'm proposing is a simple tool for maintaining Partial Mirrors (which could possibly be wrapped by apt-get later). I think that just pursuing an apt-get wrapper leads to some complications that could be avoided by creating the partial mirror tool first, then looking at wrapping it later. One complication might be how do handle apt-get remove, and another might be how to handle sid libraries that disappear from official repository, yet local machines must have them. Ahh, so maybe I completly misread that part. Do you mean a wrapper around apt-get so that apt-get install foo on any client would automatically add foo to the list of packages being mirrored on the server? If so then you can configure a post invoke hook in apt that will copy the dpkg status file of the host to the server [as status.$(hostname)] and then use those on the server to generate the filter for reprepro. I think I still have a script for that somewhere but it is easy enough to rewrite. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Ken Bloom kbl...@gmail.com writes: Josselin Mouette j...@debian.org wrote: Le lundi 01 juin 2009 à 16:26 +0200, Goswin von Brederlow a écrit : What has the initramfs got to do with this? For / to be on LVM you need an initramfs. / on raid (with custom kernel) or plain partition works without one. I already know that, thanks, but it still doesnât make your point. Just because you have some religious taboo against initramfs doesnât make it an invalid solution. Go back and look at what Goswin wrote in the first place: As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. It sounds like he feels that having an initramfs is very fragile the way Debian handles it now. If / is outside of lvm, then when the initramfs breaks, he can boot up without it and get to a place where he can regenerate an initramfs. That's not a religious taboo against initramfs. That's sensible troubleshooting behavior. --Ken Not quite. I don't need an initramfs at all. I boot with root=/dev/md0 using the raid autodetect of the kernel. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted ia32-libs-tools 14 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 03 Jun 2009 17:58:14 +0200 Source: ia32-libs-tools Binary: ia32-libs-tools ia32-archive ia32-apt-get Architecture: source all amd64 Version: 14 Distribution: unstable Urgency: low Maintainer: Debian ia32-libs Team pkg-ia32-libs-maintain...@lists.alioth.debian.org Changed-By: Goswin von Brederlow goswin-...@web.de Description: ia32-apt-get - Apt-get and dpkg wrapper for on-the-fly ia32-libs conversion ia32-archive - Create a local archive of converted i386 debs for amd64 and ia64 ia32-libs-tools - Tools for converting i386 debs for amd64 and ia64 Closes: 531515 Changes: ia32-libs-tools (14) unstable; urgency=low . [ Francois Marier ] * Bump Standards-Version up to 3.8.1 . [ Goswin von Brederlow ] * Fix dpkg-deb --control archive syntax (Closes: #531515) * Remove debug output of the commandline, confuses lintian. Checksums-Sha1: 2cbab3d0a54eb9fd69f518600a92a2a829b72f72 947 ia32-libs-tools_14.dsc 41d9292709162fe53e48f3aa3457818c8927e451 24028 ia32-libs-tools_14.tar.gz 499e45aa94a0aa0a65837879fa695f6bb8e71a1e 8562 ia32-archive_14_all.deb 1dbd1bd299058f641a435150647750b3a304e181 8030 ia32-apt-get_14_all.deb 8e053345281aa60329f0de436285c7771782029e 37546 ia32-libs-tools_14_amd64.deb Checksums-Sha256: 34f774c64a2b719458c1910cd6aa0451061b769669ba5cfc1bcb7b97de5facae 947 ia32-libs-tools_14.dsc fd00861ab94ae0bb85a68a32f723e38a3514241277bb89bdf1f3b6fcc3bc6fb9 24028 ia32-libs-tools_14.tar.gz bc10623a7ad5f6d87cf7b06584d6cfecd6fbf3a7156720bd09507fec014641d2 8562 ia32-archive_14_all.deb 8ced0554615845d9e51cef2068241e895f64d8cb7d71a5dba76d49aa19e2e262 8030 ia32-apt-get_14_all.deb 097b7d52d968005cbbf173b28972121ecd9e1671827c3105bb5ff371eed8d9be 37546 ia32-libs-tools_14_amd64.deb Files: a3b912cb467553e0d84e3eac00d07e27 947 devel extra ia32-libs-tools_14.dsc 26b4909f3b46c2cc535b86be3f98d3a7 24028 devel extra ia32-libs-tools_14.tar.gz b5b99f96f4ad56cd17b053ceb83ef576 8562 devel extra ia32-archive_14_all.deb 9a6a9d80b18131dc7d5ab9c7d67d3a2d 8030 devel extra ia32-apt-get_14_all.deb 829395cbef1bf5579c6a262dcfab6046 37546 devel extra ia32-libs-tools_14_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkonkZcACgkQScUZKBnQNIbBTACfVDbbRa8P3bolJtWOgSvAkfAV cSgAn1cKQ+xC1VGndDqRN+mPLrFt4tYl =UdBQ -END PGP SIGNATURE- Accepted: ia32-apt-get_14_all.deb to pool/main/i/ia32-libs-tools/ia32-apt-get_14_all.deb ia32-archive_14_all.deb to pool/main/i/ia32-libs-tools/ia32-archive_14_all.deb ia32-libs-tools_14.dsc to pool/main/i/ia32-libs-tools/ia32-libs-tools_14.dsc ia32-libs-tools_14.tar.gz to pool/main/i/ia32-libs-tools/ia32-libs-tools_14.tar.gz ia32-libs-tools_14_amd64.deb to pool/main/i/ia32-libs-tools/ia32-libs-tools_14_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Josselin Mouette j...@debian.org writes: Le mardi 02 juin 2009 à 11:22 +0200, Martin Wuertele a écrit : Still that doesn't mean that the project should depricate support for a separate /usr for the sake of udev. If some want to use an initramfs less kernel let them have a functional system, same goes for those that prefere a udev less system. What about those who want a system without libc? Did you think about them? Yes, we have uclibc for them. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Josselin Mouette j...@debian.org writes: Le dimanche 31 mai 2009 à 19:43 +0200, Marco d'Itri a écrit : All things considered, I have no immediate plan to push for deprecating a standalone /usr. Thanks for going back. However, if you think this debate is going to come back later, maybe we could ensure that we can remove this support later. This starts by encouraging people to use alternate solutions when possible, so that we donât hit again the âI have setups that do thisâ issue in a few years. Discouraging the use of a separate /usr should start by removing the explicit option to mount a partition to /usr in the installer. You could still specify it by hand, but that would imply knowing what youâre doing. Some of the arguments mentioned in favour of a standalone /usr are: - NFS: but it's still unclear exactly how this is managed in practice (apparently it requires much handwaving), and there are alternatives like an unionfs or really stateless clients which are probably simpler and better Indeed, if you want /usr on NFS, you also want / on NFS. Maybe those interested in such setups could write a package that makes this easier, but everything is already here. - LVM and/or RAID: no real reason nowadays to not use these for the root As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. - mounting it read only: some people obviously like this, but it's hardly something irreplaceable Again, if people want all of this for /usr, they also want it for /. Maybe the policy could make clear that any package not working with a read-only / is RC? You can not mount / nodev if you don't use udev. But you /usr you can. What I'm trying to say is that read-only is not the only option that can differ between / and /usr. - dmcrypt: not crypting /usr is just an optimization. E.g. on my laptop I decided to crypt only /home, and use symlinks for the few files in /etc which contain sensitive information, YMMV. Iâm the only one who quoted it, and I already find this is a minor use case. Count me there too. Crypting /usr on a laptop just wastes performance and cpu which spells into real battery life. Although ecryptfs is probably a even better alternative. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Josselin Mouette j...@debian.org writes: Le lundi 01 juin 2009 à 13:11 +0200, Goswin von Brederlow a écrit : As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. What has the initramfs got to do with this? For / to be on LVM you need an initramfs. / on raid (with custom kernel) or plain partition works without one. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Pierre Habouzit madco...@madism.org writes: On Mon, Jun 01, 2009 at 01:11:20PM +0200, Goswin von Brederlow wrote: Josselin Mouette j...@debian.org writes: - LVM and/or RAID: no real reason nowadays to not use these for the root As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. You meant /boot right ? No, /. Where /boot is has no effect on wether you need an initrd or not. That only interests the bootloader. You can not mount / nodev if you don't use udev. But you /usr you can. What I'm trying to say is that read-only is not the only option that can differ between / and /usr. What's the purposes of mounting /usr nodev as all directories there are owned by root (or at least should be) ? Only allow what is neccessary. That way when accidentally some device node lands in /usr it still can't be abused. For example someone could sneak in a package into Debian that contains crw-rw-rw- 1 root kmem 1, 1 May 30 15:55 /usr/lib/rootkit/mem crw-rw-rw- 1 root kmem 1, 2 May 30 15:55 /usr/lib/rootkit/kmem - dmcrypt: not crypting /usr is just an optimization. E.g. on my laptop I decided to crypt only /home, and use symlinks for the few files in /etc which contain sensitive information, YMMV. Iâm the only one who quoted it, and I already find this is a minor use case. Count me there too. Crypting /usr on a laptop just wastes performance and cpu which spells into real battery life. Although ecryptfs is probably a even better alternative. Give me numbers please, crypting /usr in my experience wastes little amount of CPU given that the in-ram cache is _not_ encrypted, so as long you don't hit the disk, it costs almost nothing. Agreed. If it is cached it doesn't matter. IF. Most peoples /usr partition is by far larger than available ram not to mention only a part of that is used for cache. My old laptop only had 128MB ram. Forget about caching there. And as soon as you hit the disk, I'm told that the disk consumptions in nowadays hardware wins over the CPU one from decryption. (I don't count encryption as you usually very seldomly _write_ to /usr except when you upgrade or install packages). Cpu frequency scalled up all the way in both cases for the test: r...@frosties:~# time dd if=/dev/sdc of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 46.6188 s, 92.1 MB/s dd if=/dev/sdc of=/dev/null bs=1M count=4096 0.01s user 8.35s system 17% cpu 46.737 total r...@frosties:~# time dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 56.5635 s, 75.9 MB/s dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 0.02s user 8.66s system 15% cpu 56.806 total Despite that it says only 15% system is used in the case of sdc-crypt all the remaining cpu power is used up by: 2651 root -5 00 R 78.7 0.0 1:00.28 kcryptd Those 78% means that the cpu goes into full speed. The voltage and frequency is increased. The cpu fan spins up to a higher setting. The time spend in kcryptd is also stolen from e.g. gcc or ld. Compiling takes longer, esspecially the first time. The CPU stays in full speed for longer eating more power. For me the takes longer part is actually more important. That even holds when you are not running on battery. I don't have numbers on the battery life as I never compared the time with and without dm-crypt. Feel free to time it yourself. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Pierre Habouzit madco...@madism.org writes: On Mon, Jun 01, 2009 at 03:08:02PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 01 Jun 2009, Pierre Habouzit wrote: Think again, if I do such a package, I would obviously check with some kind of trivial perl programm if the device containing /usr/lib/rootkit is mounted with nodev, would use mount -o remount,dev on the problematic mount point in the preinst, let the unpacking happen, and remount properly in the postinst. AFAIK, nodev blocks device nodes from _WORKING_ as well. Anyway, one would need to just remount it dev as root to exploit. Of course, when you have el-crap-o pathbased security plus something locking down remounts, the above is an attack vector that separate /usr could close. Not something someone using SE Linux would need to care about, though. And if you really care about those extra bits of performance, then what I'd do is _not_ to not encrypt /usr but rather to let / be unencrypted, And now you need /etc as a separate partition, which is a lot worse to pull off than /usr as a separate partition... cat /etc/fstab /srv/localhost/etc / auto bind ^D mount /etc done And if that fails to mount: go await, you don't exist. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: no deprecation of /usr as a standalone filesystem
Pierre Habouzit madco...@madism.org writes: On Mon, Jun 01, 2009 at 05:13:16PM +0200, Goswin von Brederlow wrote: Pierre Habouzit madco...@madism.org writes: On Mon, Jun 01, 2009 at 01:11:20PM +0200, Goswin von Brederlow wrote: Josselin Mouette j...@debian.org writes: - LVM and/or RAID: no real reason nowadays to not use these for the root As long as debian does not provide support for kernel independent non breaking initramfs support (i.e. not regenerated on every whim and break) having / outside lvm and no initramfs is a real plus. You meant /boot right ? No, /. Where /boot is has no effect on wether you need an initrd or not. That only interests the bootloader. Huh, I completely fail to see why not having / on LVM is a matter of importance. Because / on LVM requires an initramfs to start lvm. You can not mount / nodev if you don't use udev. But you /usr you can. What I'm trying to say is that read-only is not the only option that can differ between / and /usr. What's the purposes of mounting /usr nodev as all directories there are owned by root (or at least should be) ? Only allow what is neccessary. That way when accidentally some device node lands in /usr it still can't be abused. For example someone could sneak in a package into Debian that contains crw-rw-rw- 1 root kmem 1, 1 May 30 15:55 /usr/lib/rootkit/mem crw-rw-rw- 1 root kmem 1, 2 May 30 15:55 /usr/lib/rootkit/kmem Think again, if I do such a package, I would obviously check with some kind of trivial perl programm if the device containing /usr/lib/rootkit is mounted with nodev, would use mount -o remount,dev on the problematic mount point in the preinst, let the unpacking happen, and remount properly in the postinst. If you're root, nodev is useless. That's exactly why I mentioned the fact that every single path in /usr is supposed to be root:root, IOW to create a device there you *have* to be root, and nodev won't stop you. Nodev prevents the device node from working. Doesn't phase mknod at all. That means while you can still create device nodes and give them any permissions you like nobody can use them. Cpu frequency scalled up all the way in both cases for the test: r...@frosties:~# time dd if=/dev/sdc of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 46.6188 s, 92.1 MB/s dd if=/dev/sdc of=/dev/null bs=1M count=4096 0.01s user 8.35s system 17% cpu 46.737 total r...@frosties:~# time dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes (4.3 GB) copied, 56.5635 s, 75.9 MB/s dd if=/dev/mapper/sdc-crypt of=/dev/null bs=1M count=4096 0.02s user 8.66s system 15% cpu 56.806 total Despite that it says only 15% system is used in the case of sdc-crypt all the remaining cpu power is used up by: 2651 root -5 00 R 78.7 0.0 1:00.28 kcryptd Those 78% means that the cpu goes into full speed. The voltage and frequency is increased. The cpu fan spins up to a higher setting. The time spend in kcryptd is also stolen from e.g. gcc or ld. Compiling takes longer, esspecially the first time. The CPU stays in full speed for longer eating more power. For me the takes longer part is actually more important. That even holds when you are not running on battery. I don't have numbers on the battery life as I never compared the time with and without dm-crypt. Feel free to time it yourself. The point is, unless you're loading pretty large stuff (IOW larger than a few hundreds of kilobytes, say files of size 512k) your figures are wrong, because for small stuff (and it's most of what people are reading from /usr) spining the hard disk is way slower than decrypting the data. Have you looked at the size of kde or gnome in the last, oh say, 5 years? And you are wrong even for small files, or should I say esspecially? On small files you seek, you read a chunk of encrypted data, you decrypt it, you process it and only then the next chunk is requested. With random access things like the disks read-ahead won't decrypt the next block already while you process the current one. Raw performance is actually very far from what actually happens in real life. Sure, real life is usualy an order slower. And if you really care about those extra bits of performance, then what I'd do is _not_ to not encrypt /usr but rather to let / be unencrypted, and to encrypt /var, /srv and /home, with the option to let /home be a bind mount of /srv/home or similar if you don't want 3 partitions. IOW even for this kind of optimization, you have a trivial workaround And let anyone stealing my laptop steal my data too? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian source code search engine
Michael Banck mba...@debian.org writes: On Mon, May 25, 2009 at 11:01:55AM +0200, Javier Fernandez-Sanguino wrote: Is there a way to tell 'make' to execute all the dependencies for a target but not go through the target itself? It is not forbidden to unpack and patch the upstream source in the build target, AFAIK. Michael Or create build, build-xen, build-vserver, build-xen-vserver directories as copies of the source and apply a different patch set to each as the kernel does. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian source code search engine
Peter De Wachter pdewa...@gmail.com writes: Op Mon, 25 May 2009 03:36:28 +0100 schreef Ben Hutchings b...@decadent.org.uk: Cool - that looks really useful. However, it looks like you're just running dpkg-source -x to unpack packages. This misses any Debian changes made using a patch system. Unfortunately there is no standard mechanism to apply patches in version 1 source patches, but it should be easy enough to support the standard patch queue formats. I know, it's not ideal. Unfortunately, running debian/rules patch is going to be difficult, as the site runs on a FreeBSD system :) [1][2] (It's a friend's system that has lots of spare cpu cycles and bandwidth available.) Hopefully packages with patch systems will be mostly replaced with 3.0 (quilt) format once DAK allows them. With 3.0 (quilt) formar dpkg-source -x already applies all patches and that is what we want. That just leaves packages with complicated patch systems and/or conditional patches. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Raising minimum CPU requirement for i386 kernel
J.A. Bezemer cos...@wormhole.robuust.nl writes: On Sun, 24 May 2009, Bastian Blank wrote: Hi folks I would like to raise the minimum CPU requirement for the shipped Linux kernels in the i386 port to i686 (with cmov). [..] Popcon gives us some rough numbers to think about: linux-image-2.6-68649518 linux-image-2.6-486 6191 Given that the installer's automatic kernel choice tends to be accurate, we've got quite some non-cmov users. Actually, i386 has got many more non-cmov users than any non-i386/amd64 architecture has _in total_: linux-image-2.6-ixp4xx 772 (=arm/armel) linux-image-2.6-powerpc 551 linux-image-2.6-sparc64 192 linux-image-2.6-orion5x 106 (=arm/armel) (rest 100) #include popcon-accuracy-disclaimer.h So, the good work you're doing to keep supporting arm/powerpc/sparc/etc. will actually benefit much less users than the number you'll be annoying when you drop i386 non-cmov ... Best regards, Anne Bezemer And how many people with such low power systems do run popcon? How many use a custom kernel? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: i386.changes vs source.changes
Russ Allbery r...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au writes: Russ Allbery r...@debian.org writes: Cyril Brulebois k...@debian.org writes: You call it superfluous. It's particularly helpful for source-only uploads. Well, yes, it's superfluous for Debian, which doesn't support source-only uploads. But not for hackers preparing packages for Debian, who want to present those for others to inspect or collaborate on. A prime example being the mentors.debian.net workflow. So, y'all realize that pdebuild --buildresult .. by default breaks the *_source.changes file that it generates because it regenerates a source package as part of the regular build, right? How are you actually using that *_source.changes file? Always having pdebuild put its build results in a different location than where it generates the source package? What does it actualy do? a) Build binary+source in *_arch.changes? b) Build binary and merge in *_sources.changes? c) Build binary only? You sound like it does a, which I would consider slightly buggy. It should really do b or c depending on options or at least remove the *_sources.changes when it breaks it. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#529525: ITP: vsag -- Very Simple Archive Generator
Robert Millan rmh.debian@aybabtu.com writes:
On Wed, May 20, 2009 at 03:44:38AM +0200, Guillem Jover wrote:
Hi!
On Tue, 2009-05-19 at 22:18:51 +0200, Robert Millan wrote:
Package: wnpp
Severity: wishlist
Owner: Robert Millan rmh.debian@aybabtu.com
* Package name: vsag
Version : 0.0.1
Upstream Author : Robert Millan rmh.deb...@aybabtu.com
* URL : not yet released
* License : GPL
Programming Lang: bash, make
Description : Very Simple Archive Generator
Vsag is a very simple program aimed at generating Debian archives out of
a directory filled with packages.
.
It doesn't track state or manage the directory itself in any way. Its
purpose is to provide a very simple method to generate the files normally
provided by a Debian archive so that it can be used by programs like apt
or debootstrap.
Why not improve dpkg-scanpackages instead? What is there missing that
you'd need?
Not at all! dpkg-scanpackages works fine, in fact Vsag uses it to generate
Packages files. But it does also a few other things:
- Generates compressed Packages.{gz,bz2}.
- Generates Release indexes.
- Automated gpg signatures.
- DAK-like dists/ directory structure (with per-architecture separation)
- etc
Why not use reprepro ich is real simple to configure and does all this
and more.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Giacomo A. Catenazzi c...@debian.org writes: Gabor Gombas wrote: On Thu, May 14, 2009 at 03:53:23PM +0200, Giacomo A. Catenazzi wrote: No, /root cannot be a separate filesystem. /root is part of very basic system, and it is required for super user when he/she is restoring the systems or doing some kind of administration (e.g. moving filesystems, etc.). Obviously not. If fscking / fails then / _will_ be read-only and you _must_ be able to fix it without being able to write under /root, so any system restoration task must work without /root being writeable. If you want to write to /root, then _make_ it writable! That's why you are the system administrator after all. If you want / to be read-only, then move /root to some other filesystem. If you want /root to be on the same filesystem as /, then do not make / read-only. Really, this is a Doctor, it hurts if I shoot myself in the foot - Don't do it, then kind of situation... I totally agree that / (thus /root) could be read-only. I pointed out to you that /root is required to be in the same filesystem as / (FHS) and I gave you the rationale. I really prefer to allow / and /root read-only than to allow /root in a different filesystem (user could do also this choice, but outside debian support cases). ciao cate There is absolutely no reason why you can not mount a filesystem over /root later in the boot process. I agree that /root should/must exist at all time so one can login when for example fsck fails. But that works perfectly fine with /root being an empty directory on / and later having a filesystem mounted there. So I would be against /home/root, as one would have to create that on / before /home gets mounted so it is always available. That kind of shadowed directory is harder to create for DI and wouldn't show up in a backup and be missing after a restore. I would rather bind mount /home/root to /root to make /root read-write. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Manoj Srivastava sriva...@debian.org writes: Sure. I can hack things so that I have a writable home directory for root while having a read only /. But then it is incorrect to state that it works out of the box. manoj If you have a read-only / you need to have /var and /home as seperate filesystem. Requireing to have /root seperate as well is no different. That is still out of the box for me. Also I don't consider writing to /root normal. Works out of the box for normal operations if you will. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: should -dev libraries depending on other -dev packages?
Robert Collins robe...@robertcollins.net writes: On Wed, 2009-05-13 at 08:06 +0200, Josselin Mouette wrote: Le mercredi 13 mai 2009 à 11:23 +1000, Brian May a écrit : Is this still considered to be a libtool issue? Yes, but instead of dropping the .la entirely, Iâd recommend to simply purge it from the dependency libs. See /usr/share/gnome-pkg-tools/1/rules/clean-la.mk for a way to do it. If you have no reverse dependency that uses *.la files then please drop yours so things you depend on can drop theirs in turn. But only then. If the pkg-config files or the headers still reference libdb, youâll need it as a dependency anyway, but otherwise, it can be safely removed after you do that. Are the following two items correct: - to link statically you need libdb ? - to link dynamically you don't ? If they are both simultaneously correct then the .la should represent this, and be doing the right thing. Afaik the la can not represent that. If its not, it may be a libtool platform bug, or possibly [but unlikely] we've found a bug in libtools .la format. Welcome to the new millenium. Now you know why people hate *.la files. I'd need to check the source, which I don't have time to do just-now, but I thought there was provision for static and shared linking having different needs. -Rob MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Manoj Srivastava sriva...@debian.org writes: On Tue, May 12 2009, Goswin von Brederlow wrote: I don't know if there are more blocker. Oh, and /root is a home directory; unless we move that, a read only / would affect root negatively. How so? Only thing I can think of is the bash history. But it is not like we force a read-only /. That is a choice. it is the principle of the thing. /root is the home directory for the root user. Home directories are mutable, programs may store configuration files there, as may the user, by themselves. The root user should not be more constrained than other users on the machine are; making wirking as root irritating, less customizable, and harder does not help the end user admin any. Ideally, we should map /root somewhere persistent, writable, and also a location available in single user mode; and there are few pleasing solutions that meet that criteria; though less than perfect solutions exist. manoj You can always (bind) mount something on /root. If you want read-only / but can't live with read-only /root then that is the way to go. Alternatively you can change roots hoomedir or create a toor user with id 0 and /home/toor or something. I for my part don't work as root making use of sudo where required. Never felt a great need to use /root. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Manoj Srivastava sriva...@debian.org writes: On Mon, May 11 2009, Goswin von Brederlow wrote: Henrique de Moraes Holschuh h...@debian.org writes: On Mon, 11 May 2009, Goswin von Brederlow wrote: A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). A read-only / does the trick just as well. And if you don't want writes to /usr you probably don't want writes to /bin or /sbin either. So read-only / is really the way to go. Not a strong argument for a seperate /usr. No, RO / is a lot more difficult to pull off (remember: some of us don't want initrds), while RO /usr is really just a three-char change on fstab (and if you want apt to remount things automatically, two lines in a config file). Why would you need an initrd for a read-only /? A read-only / should work out of the box just like a read-only /usr. I Except it does not. I said should. :) Last I set one up it still needed some assembly but that is being worked on. It is certainly within reach for Squeeze. haven't installed a fresh one in a long while though so if you know of problems speak up so bugs can be filed and packages can be fixed. There is the /etc/mtab issue, and then there are things like resolvconf that try to scribble in /etc. I have not tried recently, so The /etc/mtab problem is finaly solved for all cases (like quota users) with kernel 2.6.26. There is a bug report about it and that is hopefully soon to be made to work out of the box. No assembly required then anymore. Resolvconf uses /lib/init/rw so that isn't a stoper anymore. ifup/down has some code for read-only / in it too. I don't know if there are more blocker. Oh, and /root is a home directory; unless we move that, a read only / would affect root negatively. How so? Only thing I can think of is the bash history. But it is not like we force a read-only /. That is a choice. A read-only / would be nice, but unless you try it on a real box, I don't think you assert it should be working out of the box. I'm sure there are some packages out there that still don't work right with read-only /. But none I use and thuse none I know about. As far as I know the /etc/mtab issue is the last pending thing. manoj MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FYI: permission with rsync on people.debian.org
Osamu Aoki os...@debian.org writes: Hi, When my usual web page updates failed, I was checking my ethernet connection ... I wondered why ... Here is the reason: I might have missed some announcment, ... but it seems rsync on people.debian.org creates directories and files with 700 permission. This is new behavior. If you are synching html pages from your work station, you need to follow rsync with ssh running chmod. Osamu Are you sure you are using the right flags and your local files have the right permissions? -a, --archive archive mode; equals -rlptgoD (no -H,-A,-X) -p, --perms preserve permissions MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Henrique de Moraes Holschuh h...@debian.org writes: On Mon, 11 May 2009, Goswin von Brederlow wrote: A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). A read-only / does the trick just as well. And if you don't want writes to /usr you probably don't want writes to /bin or /sbin either. So read-only / is really the way to go. Not a strong argument for a seperate /usr. No, RO / is a lot more difficult to pull off (remember: some of us don't want initrds), while RO /usr is really just a three-char change on fstab (and if you want apt to remount things automatically, two lines in a config file). Why would you need an initrd for a read-only /? A read-only / should work out of the box just like a read-only /usr. I haven't installed a fresh one in a long while though so if you know of problems speak up so bugs can be filed and packages can be fixed. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Roger Leigh rle...@codelibre.net writes: On Mon, May 11, 2009 at 09:59:36AM -0300, Henrique de Moraes Holschuh wrote: On Mon, 11 May 2009, Goswin von Brederlow wrote: A read-only / should work out of the box just like a read-only /usr. I haven't installed a fresh one in a long while though so if you know of problems speak up so bugs can be filed and packages can be fixed. Last time I tried it, /etc was a problem. I'd have to retry doing it, and frankly, I do not have the time to muck with that right now. #494001 is the main blocker. It's just waiting for the patch to be applied AFAICT. Ok, that one doesn't work out of the box but is easily rectified by the admin. But it has been known a long time and is finaly fixable. Should have said unknown bugs. :) MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Environment variables, debian/rules and dpkg-buildpackage
Steve Langasek vor...@debian.org writes: On Sun, May 10, 2009 at 11:37:46PM +0300, Peter Eisentraut wrote: On Sunday 10 May 2009 13:56:04 Steve Langasek wrote: I thought it was generally recognized that it's a Bad Idea to implement config files using your interpreter's 'include' functionality, but that's basically what we have here. Guillem pointed out one problem: Either you do it via a make include (which you have issues with), or you stop supporting calling debian/rules directly (inconvenient, probably prone to break things) I don't agree that dpkg-buildpackage sets additional environment variables to implement a distro/site policy for builds implies calling debian/rules directly is unsupported. Or maybe I've misunderstood, and there are Debian developers who are building official packages for *upload* by calling debian/rules by hand, and that's what people are concerned about preserving while still getting the benefits of these distro build flags? I hadn't considered that possibility, because I can't imagine anyone wanting to build packages that way instead of using dpkg-buildpackage, which does it all in a single command. So I really don't consider that an important use case, weighed against the concerns I outlined. And yet people do. Also don't forget that many people call debuild, get an error, edit some file, run debian/rules foo to see if it got fixed. Now suddenly that quick check if it got fixed behaves differently. For example, you possibly get something different depending on whether you call debian/rules, dpkg-buildpackage, debuild, or pbuilder. And the difference is hard to explain or analyze. Er, both debuild and pbuilder invoke dpkg-buildpackage. So it seems clear to me that the only difference would be when calling debian/rules directly, and at that point you're opting out of lots of other conveniences, not just distro build policy. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Environment variables, debian/rules and dpkg-buildpackage
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes: On Sun, May 10, 2009 at 09:54:11PM +0200, Raphael Hertzog wrote: On Sun, 10 May 2009, Steve Langasek wrote: I'm really surprised to see this approach getting traction. To me, this seems like a significant, unprecedented departure from the kinds of interfaces we've mandated in Policy in the past (i.e., environment variables, executables and command-line options). While one build helper or another may mandate Makefile includes, there's never been anything of the sort in Policy, and I don't think it's good to add such a thing now. I thought it was generally recognized that it's a Bad Idea to implement config files using your interpreter's 'include' functionality, but that's basically what we have here. I have sympathy for Steve viewpoint however it lacks an alternative proposal. However I cannot only strongly disagree with Raphael argument below: Another negative aspect of the include approach is the lack of tracability. Right now when the user overrides a build flag it appears in the build log since dpkg-buildpackage prints it out in the log: dpkg-buildpackage: use CFLAGS from environment: -O3 -Wall With the include approach, we lack this feature and bad/broken local overrides can't be detected if we only have the build log at hand. There is nothing that prevents a future dpkg-buildpackage to cat to stdout the relevant files at startup so that they appear in the buildlog. Cheers, $(info CFLAGS = $(CFLAGS)) in the makefile sniplet. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Environment variables, debian/rules and dpkg-buildpackage
Holger Levsen hol...@layer-acht.org writes: Hi, On Sonntag, 10. Mai 2009, Raphael Hertzog wrote: With the include approach, we lack this feature and bad/broken local overrides can't be detected if we only have the build log at hand. which reminds me that we dont have build logs for probably a lot more than 25% (*) of the most used packages in the archive. The ones build manually by the developer... I would really like to see that binaries for all archs are (re-)build on builds and that those logs are kept archived and linked from the PTS. (And arch all too of course). regards, Holger (*) wild guess, asuming that most packages are upload on amd64/i386/powerpc and mostly used on i386. Debuild already creates a build log. I think it would be nice to include that file in the changes file and have DAK forward it to buildd.debian.org for archival. git-buildpackage, svn-buildpackage, ... or even dpkg-buildpackage could do this too. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Henrique de Moraes Holschuh h...@debian.org writes: On Fri, 08 May 2009, David Weinehall wrote: No. But we do leave /usr read-only the rest of the time, which is often 99.999% of the time. A separate /usr is required for this. Uhm, no? mount --bind /usr /usr First, you'd need a RO bind mount (yes, it exists, but your command doesn't do it). Second, the filesystem is still RW, so it gains you very little as far as data safety goes. A separate /usr *is* the way to go if you don't want any writes in that filesystem 99.9% of the time (i.e. when you're not doing an upgrade). A read-only / does the trick just as well. And if you don't want writes to /usr you probably don't want writes to /bin or /sbin either. So read-only / is really the way to go. Not a strong argument for a seperate /usr. The other mount options like nodev or having a different filesystem type for /usr are stronger reasons. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Possible mass bug filing: non-doc packages recommending doc packages
Roger Lynn ro...@rilynn.demon.co.uk writes: On Fri, May 08, 2009 at 07:00:25PM +0200, Stefano Zacchiroli wrote: On Thu, May 07, 2009 at 09:47:56PM -0700, Daniel Burrows wrote: As a practical matter, downgrading these dependencies will cause aptitude and other package managers to believe that the documentation is unnecessary and suggest removing it. Even if the user marked as non-automatic the involved -doc packages? Anyhow, even if it is the case, I'm tempted to just reply too bad. The admin will notice that and take it as an occasion for doing a review of which doc she really wants and which she wants not. As a user, I like being able to mark documentation packages as being automatically installed, so that when I remove the associated packages the package manager will automatically offer to remove the then unneeded documentation packages at the same time. Otherwise there is a good chance the documentation packages will litter the system forever, or at least until I get around to doing a manual cleanup (which might never happen). I suppose another way around this would be to be able to mark suggested packages as being automatically installed so they could be removed automatically when the suggesting package is removed. Roger I think a better solution would be to mark packages as tied to each other. Foo-doc or foo-data should be marked as tied to foo. That means as long as foo is installed they will be kept installed. As soon as foo gets removed they fall under the auto-install rule. Unlike Depends, Recommends, Suggests this would be purely a users choice. For example you could tie autotools-dev and devscripts to build-essential. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Breaking /emul/ia32-linux for squeeze
Clint Adams sch...@debian.org writes: On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote: But moving the 32-bit libs to /usr/lib32 does not make us standards-conformant on amd64, because the FHS (yuckily) standardized on storing the *32-bit* libs in /usr/lib on this architecture, with 64-bit libs in /usr/lib64. That is true, which means that someone will undoubtedly file FHS-violation bugs on anything using /usr/lib32 after such a transition. Exactly. You go from the wrong place to another wrong place. Nothing gained but bug reports. On Thu, Mar 12, 2009 at 10:53:21AM +0100, Goswin von Brederlow wrote: NO NO NO NO NO NO NO NO. It is high time to change to the multiarch dir. For that gcc needs to be fixed first so compiling 32bit code does not break. Transitioning to /usr/lib32 will just needlessly break systems. The rest of this thread gives me the impression that 1) there is precious little chance that multiarch will happen anytime reasonably soon gcc-4.4 has a new multiarch patch included. It is still buggy but it makes me hopes the gcc maintainers care about it. 2) there is no point in using multiarch directories instead of /usr/lib32 prematurely Aurélien and I are talking about switching to /usr/lib32 somewhere around the time that (E)GLIBC hits sid. You do realize what that entails, right? /usr/lib32 is currently a link so you need a predepends on libc6 in every 32bit package. Are we going to have multiarch soon so that project can be abandoned? Imho once the default gcc can link against libraries in /usr/lib/i486-linux-gnu with gcc -m32 that directory can be populated. The libfoo i386 multiarch package will have to Conflicts: lib32foo in any case as far as I'm concerned to avoid two versions of the same lib to be available no matter where they are located. Having them both in /usr/lib/i486-linux-gnu just adds the need for Replaces: lib32foo which I don't consider a bad thing. On the road to true multiarch there is another step though that you (glibc maintainers) can work on. The split of libc6 into libc6 and libc6-bin. Policy requires that already but the last ftp-master did shut it down of fear of breaking things. Maybe time would be better spend implementing and extensively testing the split rather than a unneccessary transition to /usr/lib32. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
m...@linux.it (Marco d'Itri) writes: I have been told by upstream maintainers of one of my packages and by prominent developers of other distributions that supporting a standalone /usr is too much work and no other distribution worth mentioning does it (not Ubuntu, not Fedora, not SuSE). I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. So, does anybody still see reasons to continue supporting a standalone /usr? If you do, please provide a detailed real-world use case. A partial list of invalid reasons is: - I heard that this was popular in 1998 - it's a longstanding tradition to support this - it's really useful on my 386 SX with a 40 MB hard disk -- ciao, Marco Home case: / is a small raid1 that is directly booted into without initramfs /usr is on lvm on raid5 Without a seperate /usr this would require the use of an initramfs and seperate /boot partition or much more space. Work case: / is an initramfs /usr is shared over network for many hosts Useability reasons: - If fsck repairs anything while checking / the system has to reboot. All other filesystems can just continue. By splitting / and /usr there is less of a chance of / needing repair saving the reboot. - Fsck for / is run first and then other filesystems can run in parallel. - Less chance of filesystem corruption on / if /usr is another filesystem. That also means I can still boot even when /usr is damaged and then try to repair it. - / is small and relatively constant while /usr grows all the time. With / outside LVM it can be booted directly and /usr inside LVM allows easy resize when more space is needed. - / contains data that might need to be encrypted (/etc) while /usr can be left plain for more speed/less cpu usage. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Roger Leigh rle...@codelibre.net writes: On Tue, May 05, 2009 at 06:49:47PM +0200, Josselin Mouette wrote: Le mardi 05 mai 2009 à 17:24 +0100, Roger Leigh a écrit : That might have been a traditional reason for a shared /usr. However, the package manager can't cope with this setup since you have some components of a package installed locally and some remotely for all systems using the shared part. It's an impossible situation to actually cater for in real life. Has anyone ever actually *done* this? Of course, you just need to think the image you actually update as a master image, after which it is replicated by any means necessary (be it systemimager or NFS). Sure, but you effectively only have one master image. You don't have multiple users of /usr with differing /etc or /var. They are all kept in sync. This kind of makes /usr redundant since it is sharable but only among identical systems or else you will run into problems. The important part would be that a small / is replicated across all hosts. Possibly automatically on boot whenever it changed. The large /usr on the other hand is exported via NFS. This keeps the amount of data being replicated small. As for NFS, Iâd use root NFS instead of complicating my life with two different methods for / and /usr, but I guess some are doing it this way. On the compute cluster I helped set up for biological modelling, we opted to use Debian Live images on the cluster. It IIRC NFS mounts a read-only cramfs filesystem and uses aufs on top of that. There's just the one big filesystem (plus some site-specific mounts for shared data and a big scratch area all the nodes can access). We certainly saw no point in making just /usr mountable since you need a matching rootfs to accompany it. I have a setup with unionfs-fuse for xen/kvm instances here. I have one master tree that every instance mounts read-only and unionfs-fuse overlays a read-write branch from server:/srv/rw/ip/. But just like you I don't need a seperate /usr for that. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Giacomo Catenazzi c...@debian.org writes: Roger Leigh wrote: On Tue, May 05, 2009 at 05:41:06PM +0200, Stéphane Glondu wrote: Marco d'Itri a écrit : I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. A partial list of invalid reasons is: [...] How about: my /usr is shared by many machines over NFS? That might have been a traditional reason for a shared /usr. However, the package manager can't cope with this setup since you have some components of a package installed locally and some remotely for all systems using the shared part. It's an impossible situation to actually cater for in real life. Has anyone ever actually *done* this? So why we created /usr/share (and moved documentation) ? .oO(preparing for Multiarch support :) I see a lot of parallel installed system, so in this case I see no problem on sharing /usr. [BTW one of the most important conference is not LISA, about such configurations?] But also I don't think it is a problem sharing usr on multiple system with multiple configurations. On non public working stations, one doesn't run randomly programs. If I installed mysql-server on a system, it will work on such system, but if I install on an other system, it work also on the other system, occupying only one instance. I don't see problem from package management (also because we have a nullpotent dpkg), so we can upgrade from multiple system without problems. apt-get install libmysqlclient16 apt-get remove --purge libmysqlclient16 and suddenly your other system has a broken mysql-server. With your setup you can only install packages savely but not remove them. Which one can decide to live with. Looking at GNU/Hurd, /usr is a symlink to /. If we were to make /usr non-separable, maybe this would be the way to go. or plan9, which bind mount all /*/bin into the main /bin. I can live with such solution, but please allow us to use /usr in a different (maybe shared) partition. ciao cate MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem? [386 support]
Josselin Mouette j...@debian.org writes: Le mardi 05 mai 2009 à 23:38 +0200, Frank Lin PIAT a écrit : Interesting. I thought 386 wasn't supported anymore (?) AFAIK the kernel is able to emulate a 486 when running on a 386. Afaik only when properly patched to do so and including glibc patches. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
