Re: Depends: libfoo:foreign ???
On Sat, 18 May 2013 01:36:02 +0200 Adam Borowski kilob...@angband.pl wrote: On Fri, May 17, 2013 at 07:12:26PM -0400, The Wanderer wrote: I can already say that it won't be binary identical to the 64+32 build, because even the 64-bit standalone build isn't binary identical to the 64-bit side of a combined build (even though they're configured the exact same way). I'm not sure what the differences are, though vbindiff confirms that (in at least one file selected at random) it's not just a few random bytes. A wild idea: what if official amd64 buildds were mandated to have i386 enabled? That's nasty special casing, but far less nasty than multilib. Special casing which gets in the way as soon as people ask for armel on armhf etc. Multi-Arch is not just about runtime, there are very good reasons to have foreign architectures installed together with Multi-Arch (armhf on amd64) rather than just related architectures (i386 on amd64). Cross-architecture dependencies are going to be necessary for other packages (like sane Multi-Arch cross-compilers), not just Wine. This isn't about just 32bit vs 64bit. The solution needs to be generic for any combination of architectures. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp2rGU0FUy3h.pgp Description: PGP signature
Re: Depends: libfoo:foreign ???
On 05/14/2013 09:40 AM, Goswin von Brederlow wrote: Could you build a 32bit only, a 64bit only and a 32+64bit wine, run make install for each case and generate a file list for each? Including file output so it shows what is 32bit and what 64bit in the mixed case. I have these file lists now, along with several other lists based on the same data; they aren't attached because the combination of all 5 file lists alone would be close to 1.5MB, and I'm not sure what's acceptable on-list here. I can provide them, here or elsewhere, on request. I've spent some time considering them, but I'm not sure what conclusions to draw. Also what happens if you take the list for 32+64bit and then manually pick the respective files from the 32bit only and 64bit only tree according to bitness of the files? Does that produce something functional? Equal to the 32+64bit build? As there are over 3000 files involved, this is a fairly big task to handle manually, and I haven't yet found the time to either do it by hand or devise a way to automate it. This is therefore still pending. I can already say that it won't be binary identical to the 64+32 build, because even the 64-bit standalone build isn't binary identical to the 64-bit side of a combined build (even though they're configured the exact same way). I'm not sure what the differences are, though vbindiff confirms that (in at least one file selected at random) it's not just a few random bytes. I'm coming to lean towards the conclusion that further work on this would probably be better done in the context of the Debian Wine packaging team, if not (for some parts of it) Wine upstream... -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5196b95a.7040...@fastmail.fm
Re: Depends: libfoo:foreign ???
On Fri, May 17, 2013 at 07:12:26PM -0400, The Wanderer wrote: I can already say that it won't be binary identical to the 64+32 build, because even the 64-bit standalone build isn't binary identical to the 64-bit side of a combined build (even though they're configured the exact same way). I'm not sure what the differences are, though vbindiff confirms that (in at least one file selected at random) it's not just a few random bytes. A wild idea: what if official amd64 buildds were mandated to have i386 enabled? That's nasty special casing, but far less nasty than multilib. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130517233602.ga25...@angband.pl
Re: Depends: libfoo:foreign ???
On Mon, May 13, 2013 at 07:55:30AM -0400, The Wanderer wrote: On 05/09/2013 11:59 AM, Wookey wrote: +++ Goswin von Brederlow [2013-05-09 11:39 +0200]: I would say that a foreign dependency on a library is never right. That's too strong. It can make sense for cross-tools, or maybe emulators, which genuinely need a foreign-arch library to operate. But I'm not aware of other sensible usages. If I'm correctly understanding what's being described here, I would think that the full-functionality 64+32 Wine would probably be another exception (unless it falls under emulators, in which case another doesn't apply); the 64-bit side is built against and depends on 64-bit libraries, and the 32-bit side is built against and depends on both 32-bit libraries and the already-built 64-bit side, and both sides are needed for an install capable of handling both 32-bit and 64-bit Windows programs. I don't see any practical way to let a package providing the full-functionality 64+32 Wine work without depending on both the 64-bit (native) and the 32-bit (foreign) libraries. Wouldn't that be 64-bit + 32-bit binaries? I thought wine had seperate binaries and a wrapper that picks the right one to start. Wine depends on wine-bin:i386 or wine64-bin:amd64 (similar for kfreebsd). The arch qualifier is not needed since the right thing already happens (normaly). Except there is wine-bin:powerpc. That kind of ruins that. A system with amd64, i386 and powerpc configured would hapily use wine-bin:powerpc instead of wine-bin:i386. Or wine-bin:i386 can be used instead of wine-bin:kfreebsd-i386. But that is a matter of pining the architectures corectly. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Apart from the above exceptions, I agree. For the full 64+32 Wine, I don't believe this is possible - or if it is possible, no way of doing it has yet been documented that I know of. The official Wine documentation of how to build that configuration involves compiling the 32-bit side on the same 64-bit host as the 64-bit side - and, importantly, compiling it against the already-built but not-yet-installed 64-bit build tree. Theoretically it might be possible to build the 64-bit side on an amd64 machine, make the resulting tree available to an i386 machine, let the i386 machine compile the 32-bit side against the 64-bit tree, make the resulting tree available to the amd64 machine again, and let the amd64 machine do the final 'make install' or equivalent process. I wouldn't expect that to actually work, though, given that it looks like the Wine tools built on the 64-bit side may get run during the 32-bit side of the build - and even if it does work, that seems like far more trouble than should be justifiable for what is otherwise a straightforwardly scriptable build process. That seems to be a problem in the wine build system though. It should already be possible to build a 32bit only wine and a 64bit only wine. And then you just need something to build the extra tools that chose between 32bit and 64bit. Or not? I don't know the wine build system so I can't say how much pain that would cause. But it would be the most logical way. (This is the main use case I have for multi-arch -dev packages; without them, the only way I can think of to potentially accomplish a full 64+32 Wine build which I would expect to result in full functionality is to identify all -dev packages needed for the desired Wine library support, then pause in between build stages to manually swap which architecture of each of those -dev packages is installed - and swap back afterwards for normal compilation of other things.) Shifting the build tree around between amd64 and i386 and back to amd64 is no solution. That will never fly. If the two archs can't be build seperately then I guess you will have to encourage maintainers to make their -dev packages coinstallable quickly for jessie. And get support for Build-Depends: libfoo-dev:i386 [amd64] added. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130514133439.GG27079@frosties
Re: Depends: libfoo:foreign ???
On Mon, May 13, 2013 at 10:31:54AM -0400, The Wanderer wrote: On 05/13/2013 10:22 AM, The Wanderer wrote: On 05/13/2013 09:46 AM, Wookey wrote: Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles against end up installed in a final installation (as libraries?) or are they really just intermediate 'during build' items? They do end up getting installed, though whether as libraries or not I don't recall offhand. I think I may have misunderstood this question. Some of the 64-bit components which would ordinarily get installed in a 64-bit-only build get omitted from the final install (and possibly from compilation) in a combined build, because the 32-bit components replace them. Not all do, however, and some - I think most - do get installed as both in parallel. I would have to investigate the build process more closely in order to say much more with any certainty. Could you build a 32bit only, a 64bit only and a 32+64bit wine, run make install for each case and generate a file list for each? Including file output so it shows what is 32bit and what 64bit in the mixed case. Also what happens if you take the list for 32+64bit and then manually pick the respective files from the 32bit only and 64bit only tree according to bitness of the files? Does that produce something functional? Equal to the 32+64bit build? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130514134017.GH27079@frosties
Re: Depends: libfoo:foreign ???
On 05/14/2013 09:34 AM, Goswin von Brederlow wrote: On Mon, May 13, 2013 at 07:55:30AM -0400, The Wanderer wrote: If I'm correctly understanding what's being described here, I would think that the full-functionality 64+32 Wine would probably be another exception (unless it falls under emulators, in which case another doesn't apply); the 64-bit side is built against and depends on 64-bit libraries, and the 32-bit side is built against and depends on both 32-bit libraries and the already-built 64-bit side, and both sides are needed for an install capable of handling both 32-bit and 64-bit Windows programs. I don't see any practical way to let a package providing the full-functionality 64+32 Wine work without depending on both the 64-bit (native) and the 32-bit (foreign) libraries. Wouldn't that be 64-bit + 32-bit binaries? I thought wine had seperate binaries and a wrapper that picks the right one to start. It does have separate binaries, but although I'm not an expert on the Wine software architecture, AFAICT it doesn't have a wrapper; rather, in a combined build, each binary will apparently detect what kind of program you're running and either handle things itself (when the architectures match) or transfer things over the other binary (when they don't). Wine depends on wine-bin:i386 or wine64-bin:amd64 (similar for kfreebsd). The arch qualifier is not needed since the right thing already happens (normaly). Except there is wine-bin:powerpc. That kind of ruins that. A system with amd64, i386 and powerpc configured would hapily use wine-bin:powerpc instead of wine-bin:i386. Or wine-bin:i386 can be used instead of wine-bin:kfreebsd-i386. But that is a matter of pining the architectures corectly. I'm afraid I don't quite understand what you're talking about here. Or rather I think I do, but I don't see why you would have mentioned it at this point, so I suspect I may be wrong. For the full 64+32 Wine, I don't believe this is possible - or if it is possible, no way of doing it has yet been documented that I know of. The official Wine documentation of how to build that configuration involves compiling the 32-bit side on the same 64-bit host as the 64-bit side - and, importantly, compiling it against the already-built but not-yet-installed 64-bit build tree. Theoretically it might be possible to build the 64-bit side on an amd64 machine, make the resulting tree available to an i386 machine, let the i386 machine compile the 32-bit side against the 64-bit tree, make the resulting tree available to the amd64 machine again, and let the amd64 machine do the final 'make install' or equivalent process. I wouldn't expect that to actually work, though, given that it looks like the Wine tools built on the 64-bit side may get run during the 32-bit side of the build - and even if it does work, that seems like far more trouble than should be justifiable for what is otherwise a straightforwardly scriptable build process. That seems to be a problem in the wine build system though. It should already be possible to build a 32bit only wine and a 64bit only wine. And then you just need something to build the extra tools that chose between 32bit and 64bit. Or not? I don't know the wine build system so I can't say how much pain that would cause. But it would be the most logical way. As far as I can tell, there are no extra tools; it's all integrated into the usual Wine binaries. I could be wrong about that, but I haven't seen anything which seems to indicate such. The real question is the one you posed in your other mail: can you assemble a working combined install (with functionality equivalent to the as-documented combined build) from the results of two separate standalone builds, by correctly selecting which files from each side to install, or are there actual important (functional) differences in the binaries created by a combined build? I'm running the builds to try to test that now, but it's not clear how long it will take to come up with an even vaguely reliable answer. I'll provide what information I come up with when I have it. (If this becomes specifically about Wine, it may not any longer be really on topic for -devel; if there would be a better place to discuss it, I'd be willing to move the discussion, but if this is considered sufficiently on-topic I don't have a problem with continuing it here.) (This is the main use case I have for multi-arch -dev packages; without them, the only way I can think of to potentially accomplish a full 64+32 Wine build which I would expect to result in full functionality is to identify all -dev packages needed for the desired Wine library support, then pause in between build stages to manually swap which architecture of each of those -dev packages is installed - and swap back afterwards for normal compilation of other things.) Shifting the build tree around between amd64 and i386 and back to amd64 is no solution. That will never fly. Yes, of course; that
Re: Depends: libfoo:foreign ???
On Thu, May 09, 2013 at 04:59:28PM +0100, Wookey wrote: +++ Goswin von Brederlow [2013-05-09 11:39 +0200]: On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client A Depends like in this case is never right since it mixes biarch (libc6-i386) packages with multiarch (libfoo:i386). This does seem wrong, especially in this case. I can't think of a case where it makes sense offhand, but there might be one. It should be libc6:i386, libfoo:i386 at least. I would say that a foreign dependency on a library is never right. That's too strong. It can make sense for cross-tools, or maybe emulators, which genuinely need a foreign-arch library to operate. But I'm not aware of other sensible usages. Right. cross-tools are probably the exception there. Forgot about them for a minute. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Apart from the above exceptions, I agree. We haven't yet formulated any policy on what is/isn't going to be allowed/deemed sensible. Also, iirc, the use of foreign dependencies is only supposed to be on packages with Multi-Arch: allowed. I don't think that's relevant/correct. A foreign-arch dep is appropriate when the binary is linked against/uses said library, and a same-arch libfoo-arch-cross isn't used instead. Said library could be a perfectly normal M-A:same package. I guess it's time to have a think about this stuff and write down some guidelines/policy. Wookey Should that include binaries linked against libraries? Imho any foreign arch binary or library should come from a foreign arch package. So even for cross-tools if they need a foreign binary or library they should depend on the foreign package containing them. [And how will they run the foreign binary? seems like the foreign binaries case shouldn't happen at all.] That should only leave the uses foreign library case. Like a gcc cross-compiler uses the foreign libgcc. The gcc cross-compiler itself is not linked against the foreign libgcc though. But that destroys the idea of DAK catching it. I don't see how teamspeak-client depending on libfoo:i386 would be cought but i486-linux-gnu-gcc depending on libfoo:i386 would pass. Unless we add a specific tag for cross-tools to excempt them from the check. Looks like we have to keep catching those bugs by hand. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130513102146.GD8366@frosties
Re: Depends: libfoo:foreign ???
On 05/09/2013 11:59 AM, Wookey wrote: +++ Goswin von Brederlow [2013-05-09 11:39 +0200]: I would say that a foreign dependency on a library is never right. That's too strong. It can make sense for cross-tools, or maybe emulators, which genuinely need a foreign-arch library to operate. But I'm not aware of other sensible usages. If I'm correctly understanding what's being described here, I would think that the full-functionality 64+32 Wine would probably be another exception (unless it falls under emulators, in which case another doesn't apply); the 64-bit side is built against and depends on 64-bit libraries, and the 32-bit side is built against and depends on both 32-bit libraries and the already-built 64-bit side, and both sides are needed for an install capable of handling both 32-bit and 64-bit Windows programs. I don't see any practical way to let a package providing the full-functionality 64+32 Wine work without depending on both the 64-bit (native) and the 32-bit (foreign) libraries. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Apart from the above exceptions, I agree. For the full 64+32 Wine, I don't believe this is possible - or if it is possible, no way of doing it has yet been documented that I know of. The official Wine documentation of how to build that configuration involves compiling the 32-bit side on the same 64-bit host as the 64-bit side - and, importantly, compiling it against the already-built but not-yet-installed 64-bit build tree. Theoretically it might be possible to build the 64-bit side on an amd64 machine, make the resulting tree available to an i386 machine, let the i386 machine compile the 32-bit side against the 64-bit tree, make the resulting tree available to the amd64 machine again, and let the amd64 machine do the final 'make install' or equivalent process. I wouldn't expect that to actually work, though, given that it looks like the Wine tools built on the 64-bit side may get run during the 32-bit side of the build - and even if it does work, that seems like far more trouble than should be justifiable for what is otherwise a straightforwardly scriptable build process. (This is the main use case I have for multi-arch -dev packages; without them, the only way I can think of to potentially accomplish a full 64+32 Wine build which I would expect to result in full functionality is to identify all -dev packages needed for the desired Wine library support, then pause in between build stages to manually swap which architecture of each of those -dev packages is installed - and swap back afterwards for normal compilation of other things.) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5190d4b2.2030...@fastmail.fm
Re: Depends: libfoo:foreign ???
+++ The Wanderer [2013-05-13 07:55 -0400]: On 05/09/2013 11:59 AM, Wookey wrote: +++ Goswin von Brederlow [2013-05-09 11:39 +0200]: I would say that a foreign dependency on a library is never right. That's too strong. It can make sense for cross-tools, or maybe emulators, which genuinely need a foreign-arch library to operate. But I'm not aware of other sensible usages. If I'm correctly understanding what's being described here, I would think that the full-functionality 64+32 Wine would probably be another exception (unless it falls under emulators, in which case another doesn't apply); the 64-bit side is built against and depends on 64-bit libraries, and the 32-bit side is built against and depends on both 32-bit libraries and the already-built 64-bit side, and both sides are needed for an install capable of handling both 32-bit and 64-bit Windows programs. I don't see any practical way to let a package providing the full-functionality 64+32 Wine work without depending on both the 64-bit (native) and the 32-bit (foreign) libraries. OK. If that's how it works, then I agree - this is another sensible use-case. Thanks for the explanation. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Apart from the above exceptions, I agree. For the full 64+32 Wine, I don't believe this is possible - or if it is possible, no way of doing it has yet been documented that I know of. The official Wine documentation of how to build that configuration involves compiling the 32-bit side on the same 64-bit host as the 64-bit side - and, importantly, compiling it against the already-built but not-yet-installed 64-bit build tree. OK. I'd like to understand some more about this, as it's a similar issue to other cross-compiler toolchains, and if we can't solve both the same way then our design is poor. By '32+64 wine' do you mean packages designed to be installed on an amd64 machine that run both 32bit and 64bit windows apps? Or do you mean versions of wine to run on both i386 and amd64 machines? Theoretically it might be possible to build the 64-bit side on an amd64 machine, make the resulting tree available to an i386 machine, let the i386 machine compile the 32-bit side against the 64-bit tree, make the resulting tree available to the amd64 machine again, and let the amd64 machine do the final 'make install' or equivalent process. Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles against end up installed in a final installation (as libraries?) or are they really just intermediate 'during build' items? If the former then the it should work to build the 64-bit tree, then have the 32-bit build depend on a package that contains those parts it needs to build aginst. Still, there may not be much point doing this, and just building both in one go on a 64-bit build machine, so the 64-part is natively build and the 32-bit part is cross-built may make more sense. My understanding of wine is currently too weak to say anything further. I wouldn't expect that to actually work, though, given that it looks like the Wine tools built on the 64-bit side may get run during the 32-bit side of the build - and even if it does work, that seems like far more trouble than should be justifiable for what is otherwise a straightforwardly scriptable build process. There are various aspects to this, such as making it buildable on our autobuilders, trying not to diverge too much from upstream/getting them to understand how multiarch is useful, and incorporating that into the build system, future expansion of wine to other architectures (arm/arm64). I'd hope that using multiarch makes these things simpler, not more complicated. Arranging to build things on the arch they are inteded to be run on seems a sensible initial stance, but I'm not going to be religious about it if it turns out to be a daft idea. (This is the main use case I have for multi-arch -dev packages; without them, the only way I can think of to potentially accomplish a full 64+32 Wine build which I would expect to result in full functionality is to identify all -dev packages needed for the desired Wine library support, then pause in between build stages to manually swap which architecture of each of those -dev packages is installed - and swap back afterwards for normal compilation of other things.) Right. You should be able to install any needed foo-dev:host-arch packages on your build system and either build natively against them if you are building on the correct arch, or cross-build against them if on a foreign arch. That's how it should work. The neat (and radical by past standards) bit being that the the -dev:host-arch packages are the same packages (in the same paths) for both cases. It sounds like (at least) you and Stephen Kitt and I should discuss this (wine and mingw) further and flesh out how it should all work. Is a
Re: Depends: libfoo:foreign ???
On 05/13/2013 09:46 AM, Wookey wrote: +++ The Wanderer [2013-05-13 07:55 -0400]: For the full 64+32 Wine, I don't believe this is possible - or if it is possible, no way of doing it has yet been documented that I know of. The official Wine documentation of how to build that configuration involves compiling the 32-bit side on the same 64-bit host as the 64-bit side - and, importantly, compiling it against the already-built but not-yet-installed 64-bit build tree. OK. I'd like to understand some more about this, as it's a similar issue to other cross-compiler toolchains, and if we can't solve both the same way then our design is poor. By '32+64 wine' do you mean packages designed to be installed on an amd64 machine that run both 32bit and 64bit windows apps? Or do you mean versions of wine to run on both i386 and amd64 machines? The former. I don't know if there's an official term for that, but I don't know of any other; the full 64+32 Wine is just what I've been using in my own conversations as a shorthand for a longer explanation. Theoretically it might be possible to build the 64-bit side on an amd64 machine, make the resulting tree available to an i386 machine, let the i386 machine compile the 32-bit side against the 64-bit tree, make the resulting tree available to the amd64 machine again, and let the amd64 machine do the final 'make install' or equivalent process. Just to clarify: at least for a non-package-build arrangement, the amd64 machine would have to run the 'make install' from *both* trees, separately and in the correct order, after both builds had completed. This isn't automated, at least not last I checked; I've had to write wrapper scripts to automate part of it myself, for my own builds. Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles against end up installed in a final installation (as libraries?) or are they really just intermediate 'during build' items? They do end up getting installed, though whether as libraries or not I don't recall offhand. IIRC, the end result gets wineserver from the 64-bit side, wine from the 32-bit side, and wine64 from the 64-bit side, along with supporting files for both; I haven't examined it recently enough to remember what libraries (aside from the numerous Wine-internal fake-DLL objects) that may include. If the former then the it should work to build the 64-bit tree, then have the 32-bit build depend on a package that contains those parts it needs to build aginst. I think that could work, although as far as I can see it doesn't help the normal-build scenario (i.e. not building for a Debian package, just for a local install), which is the angle I approach this from. Having an intermediate package containing a build tree (as opposed to the results of installing from that build tree) seems like an undesirable thing, though. Still, there may not be much point doing this, and just building both in one go on a 64-bit build machine, so the 64-part is natively build and the 32-bit part is cross-built may make more sense. My understanding of wine is currently too weak to say anything further. My own understanding of Wine isn't in terribly much depth, but that is the scenario prescribed by the official Wine documentation for building something capable of running both 32-bit and 64-bit Windows programs, and I at least understand why it works that way; I think I know enough to also understand why it *has* to work that way, but I can't swear I'm not wrong about that. It sounds like (at least) you and Stephen Kitt and I should discuss this (wine and mingw) further and flesh out how it should all work. Is a debconf session a useful venue? I'm not sure how much I'd be able to contribute to such a discussion; I'm not actually involved with the Wine project on more than a very peripheral level (reporting occasional bugs and trying to track them down), I'm just a user who has use for the combined 64+32 functionality. I'm also not familiar with what a debconf session, in this context, means or involves; my kneejerk interpretation was a face-to-face discussion session during an official Debian meetup or other convention, but brief online searching seems to imply that that may not be accurate. I'd be willing to contribute what I can, however, and I'm always willing to learn more. (It's not like I don't have enough projects already, but this would at least be another interesting one.) -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5190f734.3030...@fastmail.fm
Re: Depends: libfoo:foreign ???
On 05/13/2013 10:22 AM, The Wanderer wrote: On 05/13/2013 09:46 AM, Wookey wrote: Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles against end up installed in a final installation (as libraries?) or are they really just intermediate 'during build' items? They do end up getting installed, though whether as libraries or not I don't recall offhand. I think I may have misunderstood this question. Some of the 64-bit components which would ordinarily get installed in a 64-bit-only build get omitted from the final install (and possibly from compilation) in a combined build, because the 32-bit components replace them. Not all do, however, and some - I think most - do get installed as both in parallel. I would have to investigate the build process more closely in order to say much more with any certainty. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5190f95a.6010...@fastmail.fm
Re: Depends: libfoo:foreign ???
On 05/13/2013 10:31 AM, The Wanderer wrote: On 05/13/2013 10:22 AM, The Wanderer wrote: On 05/13/2013 09:46 AM, Wookey wrote: Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles against end up installed in a final installation (as libraries?) or are they really just intermediate 'during build' items? They do end up getting installed, though whether as libraries or not I don't recall offhand. I think I may have misunderstood this question. Some of the 64-bit components which would ordinarily get installed in a 64-bit-only build get omitted from the final install (and possibly from compilation) in a combined build, because the 32-bit components replace them. Argh. I think I got this wrong again. If I'm not mistaken, it's actually closer to the other way around. Post-install-time, the 32-bit build tree contains symlinks pointing to the 64-bit build tree for three directories: fonts/, server/, and tools/. Post-install-time, the 64-bit build tree contains symlinks pointing to the 32-bit build tree for two executables: loader/wine and loader/wine-preloader. Everything else appears to be separate for the two build trees. As far as I'm aware, the installs for both of them run completely separately. However, since the directions call for installing the 32-bit version first and the 64-bit version second, some files installed by the 32-bit version may get overwritten. If that happens, I have no idea which ones. I would have to investigate the build process more closely in order to say much more with any certainty. This remains true. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51910019.5030...@fastmail.fm
Re: Depends: libfoo:foreign ???
+++ The Wanderer [2013-05-13 10:22 -0400]: On 05/13/2013 09:46 AM, Wookey wrote: +++ The Wanderer [2013-05-13 07:55 -0400]: For the full 64+32 Wine, I don't believe this is possible - or if it is possible, no way of doing it has yet been documented that I know of. The official Wine documentation of how to build that configuration involves compiling the 32-bit side on the same 64-bit host as the 64-bit side - and, importantly, compiling it against the already-built but not-yet-installed 64-bit build tree. OK. I'd like to understand some more about this, as it's a similar issue to other cross-compiler toolchains, and if we can't solve both the same way then our design is poor. I was actually confusing mingw and wine when I wrote that. By '32+64 wine' do you mean packages designed to be installed on an amd64 machine that run both 32bit and 64bit windows apps? Or do you mean versions of wine to run on both i386 and amd64 machines? The former. I don't know if there's an official term for that, but I don't know of any other; the full 64+32 Wine is just what I've been using in my own conversations as a shorthand for a longer explanation. OK. And is 32-bit wine (to be installed on amd64) an amd64 binary that understands i386 code or is it actually i386 code? If the latter to what degree are wine32:amd64 and wine32:i386 any different? Do we actually (ideally perhaps) just have 2 things: wine64:amd64 (amd64, amd64, win64) wine32:i386 (amd64, i386, win32) or three things: wine64:amd64 (amd64, amd64, win64) wine32:amd64 (amd64, amd64, win32) wine32:i386 (amd64, i386, win32, if cross-built) (i386, i386, win32, if native-built) where: (Build, Host, Target) means: Build is the arch built on, Host is the arch it runs/is installed on, and target is the code/abi '(not)-emulated' Perhaps this question is too simplistic once libraries are taken into account. Theoretically it might be possible to build the 64-bit side on an amd64 machine, make the resulting tree available to an i386 machine, let the i386 machine compile the 32-bit side against the 64-bit tree, make the resulting tree available to the amd64 machine again, and let the amd64 machine do the final 'make install' or equivalent process. Just to clarify: at least for a non-package-build arrangement, the amd64 machine would have to run the 'make install' from *both* trees, separately and in the correct order, after both builds had completed. This isn't automated, at least not last I checked; I've had to write wrapper scripts to automate part of it myself, for my own builds. Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles against end up installed in a final installation (as libraries?) or are they really just intermediate 'during build' items? They do end up getting installed, though whether as libraries or not I don't recall offhand. IIRC, the end result gets wineserver from the 64-bit side, wine from the 32-bit side, and wine64 from the 64-bit side, along with supporting files for both; I haven't examined it recently enough to remember what libraries (aside from the numerous Wine-internal fake-DLL objects) that may include. If the former then the it should work to build the 64-bit tree, then have the 32-bit build depend on a package that contains those parts it needs to build aginst. I think that could work, although as far as I can see it doesn't help the normal-build scenario (i.e. not building for a Debian package, just for a local install), which is the angle I approach this from. Not if you need to rebuild both the 'library' and the tools (i.e the whole thing), no. But if you just want to rebuild the tools then that should work so long as the relevant 'wine32 library bits' -dev package is installed. multiarch layouts won't help for upstream builds unless they adopt support for it (which would be good). I've only been thinking about the packaged version. upstream stuff is a different matter. Having an intermediate package containing a build tree (as opposed to the results of installing from that build tree) seems like an undesirable thing, though. Yes, it only makes sense if this part is essentially a library-dev package type thing which has some logical existence in it's own right, as something to build-dep on. Still, there may not be much point doing this, and just building both in one go on a 64-bit build machine, so the 64-part is natively build and the 32-bit part is cross-built may make more sense. My understanding of wine is currently too weak to say anything further. My own understanding of Wine isn't in terribly much depth, but that is the scenario prescribed by the official Wine documentation for building something capable of running both 32-bit and 64-bit Windows programs, and I at least understand why it works that way; I think I know enough to also understand why it *has* to work that way, but I can't swear I'm not wrong about
Re: Depends: libfoo:foreign ???
On 05/13/2013 11:00 AM, Wookey wrote: +++ The Wanderer [2013-05-13 10:22 -0400]: On 05/13/2013 09:46 AM, Wookey wrote: OK. I'd like to understand some more about this, as it's a similar issue to other cross-compiler toolchains, and if we can't solve both the same way then our design is poor. I was actually confusing mingw and wine when I wrote that. That clears up a bit of confusion, then. By '32+64 wine' do you mean packages designed to be installed on an amd64 machine that run both 32bit and 64bit windows apps? Or do you mean versions of wine to run on both i386 and amd64 machines? The former. I don't know if there's an official term for that, but I don't know of any other; the full 64+32 Wine is just what I've been using in my own conversations as a shorthand for a longer explanation. OK. And is 32-bit wine (to be installed on amd64) an amd64 binary that understands i386 code or is it actually i386 code? If the latter to what degree are wine32:amd64 and wine32:i386 any different? To the best of my ability to determine, it is the latter. On a per-file level, I don't actually know that they are different, and what investigation I've done seems to indicate that they may not be. On a package-wide level, some components which get built and installed during a standalone 32-bit build don't get built for a combined build, because they are covered by components provided by the 64-bit build. (The same also appears to be true in reverse.) Do we actually (ideally perhaps) just have 2 things: wine64:amd64 (amd64, amd64, win64) wine32:i386 (amd64, i386, win32) or three things: wine64:amd64 (amd64, amd64, win64) wine32:amd64 (amd64, amd64, win32) wine32:i386 (amd64, i386, win32, if cross-built) (i386, i386, win32, if native-built) where: (Build, Host, Target) means: Build is the arch built on, Host is the arch it runs/is installed on, and target is the code/abi '(not)-emulated' The three things case seems almost accurate, except for one thing: wine32:amd64 would be targeted to install on an amd64 host, but would be i386 code. That may be what you intended, but I don't see it implied by the above statement. Perhaps this question is too simplistic once libraries are taken into account. I'm not sure it is; I think this may be enough to account for everything. Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles against end up installed in a final installation (as libraries?) or are they really just intermediate 'during build' items? If the former then the it should work to build the 64-bit tree, then have the 32-bit build depend on a package that contains those parts it needs to build aginst. I think that could work, although as far as I can see it doesn't help the normal-build scenario (i.e. not building for a Debian package, just for a local install), which is the angle I approach this from. Not if you need to rebuild both the 'library' and the tools (i.e the whole thing), no. But if you just want to rebuild the tools then that should work so long as the relevant 'wine32 library bits' -dev package is installed. I'm looking at the scenario of (potentially frequent) compilation of the Wine development tree, rather than of a released version. Since the 32-bit and 64-bit build trees have to be built against the same source for this to work properly, the wine32 library bits package wouldn't help. multiarch layouts won't help for upstream builds unless they adopt support for it (which would be good). I've only been thinking about the packaged version. upstream stuff is a different matter. Acknowledged. For packaging purposes, this does seem like a reasonable approach, modulo the questionability of a separate build-tree-only package. (It seems to me that coinstallable multiarch -dev packages would allow this to work for Wine with the existing documented approach, with no upstream changes; it's certainly worked fine with ia32-libs-dev so far. But I agree that this is a separate question.) Still, there may not be much point doing this, and just building both in one go on a 64-bit build machine, so the 64-part is natively build and the 32-bit part is cross-built may make more sense. My understanding of wine is currently too weak to say anything further. My own understanding of Wine isn't in terribly much depth, but that is the scenario prescribed by the official Wine documentation for building something capable of running both 32-bit and 64-bit Windows programs, and I at least understand why it works that way; I think I know enough to also understand why it *has* to work that way, but I can't swear I'm not wrong about that. If what is being built is all amd64 code, then clearly it makes sense to build it all in one go, on one machine. If part of what is being built is i386 code, depending on :i386 libs then it may make sense to do part of that on i386 build machines, or it may make more sense to cross-build it on amd64. Part of what is being built
Re: Depends: libfoo:foreign ???
On Mon, 13 May 2013 11:43:05 -0400, The Wanderer wande...@fastmail.fm wrote: On 05/13/2013 11:00 AM, Wookey wrote: OK. And is 32-bit wine (to be installed on amd64) an amd64 binary that understands i386 code or is it actually i386 code? If the latter to what degree are wine32:amd64 and wine32:i386 any different? To the best of my ability to determine, it is the latter. On a per-file level, I don't actually know that they are different, and what investigation I've done seems to indicate that they may not be. On a package-wide level, some components which get built and installed during a standalone 32-bit build don't get built for a combined build, because they are covered by components provided by the 64-bit build. (The same also appears to be true in reverse.) Do we actually (ideally perhaps) just have 2 things: wine64:amd64 (amd64, amd64, win64) wine32:i386 (amd64, i386, win32) or three things: wine64:amd64 (amd64, amd64, win64) wine32:amd64 (amd64, amd64, win32) wine32:i386 (amd64, i386, win32, if cross-built) (i386, i386, win32, if native-built) where: (Build, Host, Target) means: Build is the arch built on, Host is the arch it runs/is installed on, and target is the code/abi '(not)-emulated' The three things case seems almost accurate, except for one thing: wine32:amd64 would be targeted to install on an amd64 host, but would be i386 code. That may be what you intended, but I don't see it implied by the above statement. The upstream approach would be three things, using multilib rather than multiarch for the wine32:amd64 packages and native building for the i386 packages. It may be possible to support the two things approach using multiarch, but it would make life a bit harder for maintainers and would introduce yet another change from upstream (but if multilib disappears in favour of multiarch we'd need to do it anyway). Mike Gilbert is working on all this just now, he'd be the one to ask! Regards, Stephen signature.asc Description: PGP signature
Re: Depends: libfoo:foreign ???
Goswin von Brederlow goswin-v-b at web.de writes: I would say that a foreign dependency on a library is never right. If Nope. I’m waiting for support for that for pcc. (And that pcc CVS HEAD gets stable/usable again, but that’s a totally different issue.) bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130511t173458-...@post.gmane.org
Re: Depends: libfoo:foreign ???
On Thu, 2013-05-09 at 08:43 +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client It appears that will block it from reaching testing: Indeed, Britney does not support those annotations (at the moment?). To avoid issues with this kind of thing, we made her consider such dependencies for unsatisfiable[1]. So for now anything using that form in Depends or Pre-Depends will not reach testing (without manual intervention from the Release team and I am not sure how likely we are to do that). [...] During this release cycle I'm hoping to get rid of the 'amd64' kernel flavour in i386. The linux-image-3.2.0-4-amd64 package is already installable in wheezy with amd64 as a foreign arch. However, the linux-headers-*-amd64 packages are not, as they depend on a specific major version of gcc (e.g. gcc-4.6). I think that a dependency on 'gcc-4.6 | gcc-4.6:i386' might fix that, but what would britney think of it? Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: Depends: libfoo:foreign ???
On 2013-05-10 14:48, Ben Hutchings wrote: On Thu, 2013-05-09 at 08:43 +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client It appears that will block it from reaching testing: Indeed, Britney does not support those annotations (at the moment?). To avoid issues with this kind of thing, we made her consider such dependencies for unsatisfiable[1]. So for now anything using that form in Depends or Pre-Depends will not reach testing (without manual intervention from the Release team and I am not sure how likely we are to do that). [...] During this release cycle I'm hoping to get rid of the 'amd64' kernel flavour in i386. The linux-image-3.2.0-4-amd64 package is already installable in wheezy with amd64 as a foreign arch. However, the linux-headers-*-amd64 packages are not, as they depend on a specific major version of gcc (e.g. gcc-4.6). I think that a dependency on 'gcc-4.6 | gcc-4.6:i386' might fix that, but what would britney think of it? Ben. As I understand the code, she ignores unsatisifiable dependencies in an OR clause (as long as the result is not empty). That said, our test case for this does not include alternatives. Though looking at the commit log, if she doesn't accept it (I think she will, but...) you will get a big fat warning on the excuses page[1]. If you want to know ahead of time, you are welcome to donate a test case[2]. :) ~Niels [1] http://anonscm.debian.org/gitweb/?p=mirror/britney2.git;a=commitdiff;h=3e9c1acb8e3724c7f1cf10f4578a4082fb5c1756 [2] http://anonscm.debian.org/gitweb/?p=collab-maint/britney2-tests.git I think t/multi-arch-depends should serve as a good starting point. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518cf552.9080...@thykier.net
Re: Depends: libfoo:foreign ???
On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client It appears that will block it from reaching testing: Indeed, Britney does not support those annotations (at the moment?). To avoid issues with this kind of thing, we made her consider such dependencies for unsatisfiable[1]. So for now anything using that form in Depends or Pre-Depends will not reach testing (without manual intervention from the Release team and I am not sure how likely we are to do that). http://packages.qa.debian.org/t/teamspeak-client.html The proper thing to do would be to remove the amd64 package entirely and have users install the i386 version. Indeed, I believe that should work. ~Niels [1] Though she ignores them in Recommends/Suggests and possibly also in Breaks/Conflicts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518b458a.2020...@thykier.net
Re: Depends: libfoo:foreign ???
On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client It appears that will block it from reaching testing: Indeed, Britney does not support those annotations (at the moment?). To avoid issues with this kind of thing, we made her consider such dependencies for unsatisfiable[1]. So for now anything using that form in Depends or Pre-Depends will not reach testing (without manual intervention from the Release team and I am not sure how likely we are to do that). http://packages.qa.debian.org/t/teamspeak-client.html The proper thing to do would be to remove the amd64 package entirely and have users install the i386 version. Indeed, I believe that should work. It is the indended solution. If it doesn't work then that is a bug and needs to be fixed. ~Niels [1] Though she ignores them in Recommends/Suggests and possibly also in Breaks/Conflicts. A Depends like in this case is never right since it mixes biarch (libc6-i386) packages with multiarch (libfoo:i386). I would say that a foreign dependency on a library is never right. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Also, iirc, the use of foreign dependencies is only supposed to be on packages with Multi-Arch: allowed. This is for interpreters and plugins/lib bindings where the normal automatic method can't work. So maybe DAK could be made more restrictive here. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130509093918.GA31432@frosties
Re: Depends: libfoo:foreign ???
+++ Goswin von Brederlow [2013-05-09 11:39 +0200]: On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client A Depends like in this case is never right since it mixes biarch (libc6-i386) packages with multiarch (libfoo:i386). This does seem wrong, especially in this case. I can't think of a case where it makes sense offhand, but there might be one. I would say that a foreign dependency on a library is never right. That's too strong. It can make sense for cross-tools, or maybe emulators, which genuinely need a foreign-arch library to operate. But I'm not aware of other sensible usages. If the source compiles binaries for the foreign arch then the package should be build on the foreign arch directly. Period. Apart from the above exceptions, I agree. We haven't yet formulated any policy on what is/isn't going to be allowed/deemed sensible. Also, iirc, the use of foreign dependencies is only supposed to be on packages with Multi-Arch: allowed. I don't think that's relevant/correct. A foreign-arch dep is appropriate when the binary is linked against/uses said library, and a same-arch libfoo-arch-cross isn't used instead. Said library could be a perfectly normal M-A:same package. I guess it's time to have a think about this stuff and write down some guidelines/policy. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130509155927.gv2...@stoneboat.aleph1.co.uk
Re: Depends: libfoo:foreign ???
On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote: On 2013-05-09 07:56, Paul Wise wrote: On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client It appears that will block it from reaching testing: Indeed, Britney does not support those annotations (at the moment?). To avoid issues with this kind of thing, we made her consider such dependencies for unsatisfiable[1]. So for now anything using that form in Depends or Pre-Depends will not reach testing (without manual intervention from the Release team and I am not sure how likely we are to do that). Sorry for not knowing the answer to this, but does britney support :any dependencies? These don't require any cross-architecture dependency resolution, but should be satisfiable within each architecture; britney just needs to support them. This would let us finally make use of Multi-Arch: allowed in the archive. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Depends: libfoo:foreign ???
On 2013-05-09 21:00, Steve Langasek wrote: [...] Sorry for not knowing the answer to this, but does britney support :any dependencies? These don't require any cross-architecture dependency resolution, but should be satisfiable within each architecture; britney just needs to support them. This would let us finally make use of Multi-Arch: allowed in the archive. At the moment, no. We had her treat pkg:arch as a package name causing it to always fail (as no package can have colon in their name). But feel free to file bugs for it (bonus points if they include tests[1]). ~Niels [1] http://anonscm.debian.org/gitweb/?p=collab-maint/britney2-tests.git;a=summary -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518bffcf.6060...@thykier.net
Re: Depends: libfoo:foreign ???
On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote: I just noticed that we have the first amd64 package in the archive that has dependencies on :i386 qualified libraries: Package: teamspeak-client It appears that will block it from reaching testing: http://packages.qa.debian.org/t/teamspeak-client.html The proper thing to do would be to remove the amd64 package entirely and have users install the i386 version. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GeFuc6usA7r=jbznhp2fkugupwv6-fywuvxj9k2uc...@mail.gmail.com
