Am 06.12.2011 19:56, schrieb Ray Rashif:

I want to add a 'jack2-multilib' to the repo, as an equivalent to 'lib32-jack'. This would allow users to continue using or to install 'jack2' while using a package requiring a 32-bit library of 'jack'. As it is currently, some multilib users are forced to use 'jack' even if they want to use 'jack2'.

As there is no simple way to simply build in parts, 'jack2-multilib' replaces 'jack2' in a multilib installation. Even if there were, this would be the better approach since the software already contains a specific flag to build a "mixed" or hybrid jack.

In light of this, I would also like the appropriate permissions to be able to push packages to [multilib].

Can you upload PKGBUILDs and packages first?

Caveat: I'm not a multilb user.

Why are you doing it then? Are there any requests for this? Forum posts?

On 7 December 2011 05:46, Thomas Bächler wrote:

Can you upload PKGBUILDs and packages first?

Will do that once I get the green light here.

Why are you doing it then? Are there any requests for this? Forum posts?

There has been a couple of requests for this on IRC, but aside from that, first and foremost, I've noticed that users of jack2 will have a problem in a situation like the following: wine > lib32-alsa-plugins > lib32-jack Here users of jack2 cannot continue to use jack2, as it has no provision for or equivalent to lib32-jack. This example is weak now, but previously when I decided to write jack2-multilib it was like this: wine > lib32-jack So I'm sort of late in proposing this package. -- GPG/PGP ID: C0711BF1

Am 07.12.2011 06:13, schrieb Ray Rashif:

On 7 December 2011 05:46, Thomas Bächler wrote:

...

Why are you doing it then? Are there any requests for this? Forum posts?

There has been a couple of requests for this on IRC, but aside from that, first and foremost, I've noticed that users of jack2 will have a problem in a situation like the following:

wine > lib32-alsa-plugins > lib32-jack

Here users of jack2 cannot continue to use jack2, as it has no provision for or equivalent to lib32-jack. This example is weak now, but previously when I decided to write jack2-multilib it was like this:

wine > lib32-jack

So I'm sort of late in proposing this package.

I still don't understand why you can't just build a lib32 package that doesn't conflict with the usual jack/jack2 package. Also, there is no provides on jack2, why? But the most important thing: There is no makedepend on gcc-multilib or any other of the multilib build tools. How could this build a 32 bit binary?

Am 07.12.2011 15:08, schrieb Ray Rashif:

On 7 December 2011 17:13, Thomas Bächler wrote:

...

I still don't understand why you can't just build a lib32 package that doesn't conflict with the usual jack/jack2 package.

Sorry, I should've made that clear from the beginning. It is possible, but it is (a) non-trivial and (b) a hassle to maintain. There is no way to build out a 32-bit library without patching your way through the buildsystem [1] _and_ patching the existing pure 32-bit and 64-bit 'jack2' package to make way for a -lib32 one [2] (credits go to user 'speps' for demonstrating this).

Now, I'm pretty sure you would think that's a PITA, as I had thought, deciding on a replacement package instead (yes, a lib32 package was the obvious initial idea). The users also told me they would prefer a lib32 package, so it's not like I ignored that. Basically, upstream here gives you the necessary method to keep a hybrid build of their software, but does not modularise the process thinking they'd save us distributors the trouble.

Fair enough. I agree this is easier, and the explanation justifies the method. Still another idea to think about: What about going through the whole build process including --mixed, but then only packaging the 32 bit libraries? Will that work as well?

...

Also, there is no provides on jack2, why?

As you can see, the second of the splits has this provision, so that's probably an accident from the last edit I made on the PKGBUILD.

Okay.

...

But the most important thing: There is no makedepend on gcc-multilib or any other of the multilib build tools. How could this build a 32 bit binary?

There is no need to makedepend on 'gcc-multilib' as it should already be there in a multilib system, sort of analogous to the 'base-devel' group for normal systems. I had 'gcc-libs-multilib' initially (due to namcap's report), but upon noticing that a chroot build only requires 'lib32-glibc', and after a user tested the package to be working for his hybrid purpose, I removed the unnecessary dependency. The 32-bit library is there at the end of the day:

If you build in a clean chroot using devtools, it will (IIRC) install the base multilib devel packages. However, if a user were to build inside the normal system, we would only assume base-devel to be present! Even if you have multilib packages installed, you can have a system without multilib devel packages (as mine - I have lib32-glibc, lib32-gcc-libs and so on, but no gcc-multilib, no binutils-multilib, no libtool-multilib and no gcc-libs-multilib!). We have gcc-multilib as a makedepend everywhere as far as I can see, so please add it here as well.

Let me know if there's anything else that needs to be done to make this compatible with [multilib].

Alright. I'll wait until later tonight (now + 5 hours), and if nobody objects until then, I'll give you permissions to multilib (you can already check into svn-community, all you need is the right to write to the multilib ftp directory).

On Wed, 07 Dec 2011 15:37:09 +0100 Thomas Bächler wrote:

Still another idea to think about: What about going through the whole build process including --mixed, but then only packaging the 32 bit libraries? Will that work as well?

In short, nope as you intend it. I try to make clarifications on this point: The jack2 build system (based on waf) come out with a --mixed flag that does not just build the 32 bit library, but a multilib capable server too. In particular the --mixed flag adds a -DJACK_32_64 macro that enables the preprocessor in posix/JackCompilerDeps_os.h at #37: #define POST_PACKED_STRUCTURE __attribute__((__packed__)) This ensures that structures have the same size on all processors, in the way a 32 bit jack client can correctly communicate with a 64 bit server. When it was discussed on #archaudio @ freenode.net, 3 solutions come out: 1. jack2: leave as it is now jack2-multilib: build with --mixed, provides and conflicts with jack2 and lib32-jack2 2. jack2: build with --mixed for x86_64 ([ "$CARCH" = 'x86_64' ]) removing the generated 32 bit lib from the final package lib32-jack2: build with --mixed, removing all but the 32 bit lib 3. jack2: build with a patch that just adds the -DJACK_32_64 macro in the build process without building the 32 bit lib lib32-jack2: build with a patch the builds just the 32 bit lib About Pros and Cons: 1. Pros: proposed by Ray as it is the most simple to maintain, and the one that upstream suggests Cons: jack2 server is built twice 2. Pros: lib32-jack2 contains just the 32 bit lib Cons: jack2 builds the 32 bit lib and then deletes it, lib32-jack2 builds the jack server and deletes it, loss of time 3. Pros: jack2 builds and provides a 32 bit capable jack server for x86_64 lib32-jack2 builds and provides just the 32 bit lib Cons: harder to maintain since the build system needs to be patched Since Ray is the actual maintainer and solutions graves more on maintaining, he's the only one who should make the choice. The patches I wrote for the third solution would be more harder to adapt for him, on an eventual future massive change in the build system. Also, technically, a not --mixed server differs from a --mixed one for the POST_PACKED_STRUCTURE definition, even if it seems to not comport any difference on functionality nor stability. I hope I made myself clear, cheers. - speps -

On Thu, 08 Dec 2011 01:52:33 +0100 Thomas Bächler wrote:

This wouldn't work, as a pure 64 bit package must be able to build with core/gcc - that compiler cannot build 32 bit binaries.

Right, this kills the second solution.

Patching build systems is a PITA.

And this kills the concept of possibilities.

Yes, this clarifies the problem a lot. Can we add this as a huge comment in the PKGBUILD, please?

Ipse dixit is good too.

Btw, I enabled Ray's multilib access. As nobody objected so far, I am giving him a green light to implement whatever solution he sees suitable.

Well done. Thanks. Seriously, sorry for being too -vvv. - speps -