libvchan-xen debian package fails to build on a clean unstable builder

[santiagorr]

Hi,

First of all, thanks for this amazing OS :-)

I'm taking a look to the debian packaging of Qubes-OS core components, beginning with libvchan-xen.
My cowbuilder fails to build it on a debian unstable base. It seems gcc flags are not correctly configured, at least an -I flag is missing. Full build log attached, this is the relevant part:

  debian/rules build
dh build --with autotools-dev
   dh_testdir
   dh_update_autotools_config
   dh_autotools-dev_updateconfig
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/libvchan-xen-qubes-3.2.0'
(cd u2mfn; make)
make[2]: Entering directory '/build/libvchan-xen-qubes-3.2.0/u2mfn'
gcc -fPIC -Wall -g -c u2mfnlib.c
gcc -shared -o libu2mfn.so u2mfnlib.o
make[2]: Leaving directory '/build/libvchan-xen-qubes-3.2.0/u2mfn'
(cd vchan; make -f Makefile.linux)
make[2]: Entering directory '/build/libvchan-xen-qubes-3.2.0/vchan'
gcc -g -Wall -Wextra -Werror -fPIC -O2 -Wdate-time -D_FORTIFY_SOURCE=2  -c -o init.o init.c
In file included from init.c:29:0:
libvchan_private.h:25:25: fatal error: libxenvchan.h: No such file or directory
 #include <libxenvchan.h>
                         ^
compilation terminated.
<builtin>: recipe for target 'init.o' failed
make[2]: *** [init.o] Error 1

Cheers,

Santiago

libvchan-xen_3.2.0-1.log.txt

---

Related issues:

#1919

[santiagorr]

Note: this was under the current libvchan-xen git master HEAD, f988f143fb2e266cf96bf80d1ed782256abe653e

[santiagorr]

Note: this was under the current libvchan-xen git master HEAD, f988f143fb2e266cf96bf80d1ed782256abe653e

[marmarek]

Upstream Debian Xen packages lack of libxenvchan library - you need those from our repository:
https://github.com/qubesos/qubes-vmm-xen (or use apt repo at https://deb.qubes-os.org/r3.2/vm).

[marmarek]

Upstream Debian Xen packages lack of libxenvchan library - you need those from our repository:
https://github.com/qubesos/qubes-vmm-xen (or use apt repo at https://deb.qubes-os.org/r3.2/vm).

[santiagorr]

El 07/04/17 a las 05:39, Marek Marczykowski-Górecki escribió:

Upstream Debian Xen packages lack of libxenvchan library - you need those from our repository: [1]https://github.com/qubesos/qubes-vmm-xen (or use apt repo at [2]https://deb.qubes-os.org/r3.2/vm).

Thanks, that works. Maybe, have you already asked Xen Debian maintainers to include that library? I found nothing about it at https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=xen Lazy question: what changes/patches would be needed? Cheers! Santiago

[santiagorr]

El 07/04/17 a las 05:39, Marek Marczykowski-Górecki escribió:

Upstream Debian Xen packages lack of libxenvchan library - you need those from our repository: [1]https://github.com/qubesos/qubes-vmm-xen (or use apt repo at [2]https://deb.qubes-os.org/r3.2/vm).

Thanks, that works. Maybe, have you already asked Xen Debian maintainers to include that library? I found nothing about it at https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=xen Lazy question: what changes/patches would be needed? Cheers! Santiago

[marmarek]

Maybe, have you already asked Xen Debian maintainers to include that library?

@h01ger have made some effort, as part of https://wiki.debian.org/Qubes/Devel, but not sure if Xen Debian maintainer was involved. Xen Debian package is very complex (for example debian/control file is generated...), so I can't provide a patch.

Lazy question: what changes/patches would be needed?

For this case, probably just don't remove the library - it is installed by default by upstream Xen install scripts. But in more general case - see here:
https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.6/series-debian-vm.conf

And if you'd like to package also things needed in dom0, then things get even more complex - because of Debian policy "one upstream tarball, one source package" (at least I understand it this way) - stubdomain is built using multiple 3rd-party components with Xen-specific patches applied.

[marmarek]

Maybe, have you already asked Xen Debian maintainers to include that library?

@h01ger have made some effort, as part of https://wiki.debian.org/Qubes/Devel, but not sure if Xen Debian maintainer was involved. Xen Debian package is very complex (for example debian/control file is generated...), so I can't provide a patch.

Lazy question: what changes/patches would be needed?

For this case, probably just don't remove the library - it is installed by default by upstream Xen install scripts. But in more general case - see here:
https://github.com/QubesOS/qubes-vmm-xen/blob/xen-4.6/series-debian-vm.conf

And if you'd like to package also things needed in dom0, then things get even more complex - because of Debian policy "one upstream tarball, one source package" (at least I understand it this way) - stubdomain is built using multiple 3rd-party components with Xen-specific patches applied.

[h01ger]

On Fri, Apr 07, 2017 at 07:43:02AM -0700, Marek Marczykowski-Górecki wrote: because of Debian policy "one upstream tarball, one source package" (at least I understand it this way) - stubdomain is built using multiple 3rd-party components with Xen-specific patches applied.

with debian/source format 3.0 you can have several tarballs in one source package.

…

-- cheers, Holger

[h01ger]

On Fri, Apr 07, 2017 at 07:43:02AM -0700, Marek Marczykowski-Górecki wrote: because of Debian policy "one upstream tarball, one source package" (at least I understand it this way) - stubdomain is built using multiple 3rd-party components with Xen-specific patches applied.

with debian/source format 3.0 you can have several tarballs in one source package.

…

-- cheers, Holger

[andrewdavidwong]

@santiagorr: Has your issue been resolved, or is there still something actionable here?

[andrewdavidwong]

@santiagorr: Has your issue been resolved, or is there still something actionable here?

[santiagorr]

El 07/04/17 a las 20:22, Andrew David Wong escribió:

***@***.***: Has your issue been resolved, or is there still something actionable here?

Well, if it is being able to build the qubes-core-vchan-xen package on a pure debian, my issue is still unresolved. Qubes specific changes have to be applied to the Xen package, and let me try to give you an argument why it is important to include those changes directly on Debian. I have updated my debian-8 based VM to debian-9. Now, I have two "conflicting" libxen-dev packages from different repositories: qubes' repo is version 4.6.4-26+deb9u1, that is lower than the stretch (or sid) repo's: 4.8.1~pre.2017.01.23-1, so apt prefers the latter. This is maybe out of the scope of the original issue, but from my debian user point of view, I would need to fix this first.

[santiagorr]

El 07/04/17 a las 20:22, Andrew David Wong escribió:

***@***.***: Has your issue been resolved, or is there still something actionable here?

Well, if it is being able to build the qubes-core-vchan-xen package on a pure debian, my issue is still unresolved. Qubes specific changes have to be applied to the Xen package, and let me try to give you an argument why it is important to include those changes directly on Debian. I have updated my debian-8 based VM to debian-9. Now, I have two "conflicting" libxen-dev packages from different repositories: qubes' repo is version 4.6.4-26+deb9u1, that is lower than the stretch (or sid) repo's: 4.8.1~pre.2017.01.23-1, so apt prefers the latter. This is maybe out of the scope of the original issue, but from my debian user point of view, I would need to fix this first.

[andrewdavidwong]

Well, if it is being able to build the qubes-core-vchan-xen package on a
pure debian, my issue is still unresolved.

What does "it" refer to here?

By "pure" Debian do you mean baremetal (non-Qubes) Debian?

Qubes specific changes have to be applied to the Xen package, and let me
try to give you an argument why it is important to include those changes
directly on Debian.
I have updated my debian-8 based VM to debian-9. Now, I have two
"conflicting" libxen-dev packages from different repositories:
qubes' repo is version 4.6.4-26+deb9u1, that is lower than the
stretch (or sid) repo's: 4.8.1~pre.2017.01.23-1, so apt prefers the
latter.
This is maybe out of the scope of the original issue, but from my debian
user point of view, I would need to fix this first.

So, this is a problem that arises when you upgrade a Qubes TemplateVM from Debian 8 to Debian 9, then try to build Qubes in an AppVM based on that TemplateVM?

[andrewdavidwong]

Well, if it is being able to build the qubes-core-vchan-xen package on a
pure debian, my issue is still unresolved.

What does "it" refer to here?

By "pure" Debian do you mean baremetal (non-Qubes) Debian?

Qubes specific changes have to be applied to the Xen package, and let me
try to give you an argument why it is important to include those changes
directly on Debian.
I have updated my debian-8 based VM to debian-9. Now, I have two
"conflicting" libxen-dev packages from different repositories:
qubes' repo is version 4.6.4-26+deb9u1, that is lower than the
stretch (or sid) repo's: 4.8.1~pre.2017.01.23-1, so apt prefers the
latter.
This is maybe out of the scope of the original issue, but from my debian
user point of view, I would need to fix this first.

So, this is a problem that arises when you upgrade a Qubes TemplateVM from Debian 8 to Debian 9, then try to build Qubes in an AppVM based on that TemplateVM?

[santiagorr]

El 10/04/17 a las 06:15, Andrew David Wong escribió:

Well, if it is being able to build the qubes-core-vchan-xen package on a pure debian, my issue is still unresolved. What does "it" refer to here?

The issue. Sorry if my writing is not clear.

By "pure" Debian do you mean baremetal (non-Qubes) Debian?

Yes. To be precise, on the cowbuilder chroot that I use to build packages to be uploaded to Debian.

Qubes specific changes have to be applied to the Xen package, and let me try to give you an argument why it is important to include those changes directly on Debian. I have updated my debian-8 based VM to debian-9. Now, I have two "conflicting" libxen-dev packages from different repositories: qubes' repo is version 4.6.4-26+deb9u1, that is lower than the stretch (or sid) repo's: 4.8.1~pre.2017.01.23-1, so apt prefers the latter. This is maybe out of the scope of the original issue, but from my debian user point of view, I would need to fix this first. So, this is a problem that arises when you upgrade a Qubes TemplateVM from Debian 8 to Debian 9, then try to build Qubes in an AppVM based on that TemplateVM?

It seems I am mixing different things here. I reported this issue after looking at how to close the Intend To Package (ITP) Debian bug for the Qubes vchan libraries: https://bugs.debian.org/837905 which means uploading the package to Debian. To answer your question: no, it is not a problem that arises on my upgraded vm. At least, it is no longer the case. It was maybe a bad example, that I am not able to re-reproduce right now (apt does take into account the 2001 version epoch). So, forget about it :-P I was trying to give reasons for including the qubes-specific changes into the Xen Debian package, needed to build qubes-core-vchan-xen.

[santiagorr]

El 10/04/17 a las 06:15, Andrew David Wong escribió:

Well, if it is being able to build the qubes-core-vchan-xen package on a pure debian, my issue is still unresolved. What does "it" refer to here?

The issue. Sorry if my writing is not clear.

By "pure" Debian do you mean baremetal (non-Qubes) Debian?

Yes. To be precise, on the cowbuilder chroot that I use to build packages to be uploaded to Debian.

Qubes specific changes have to be applied to the Xen package, and let me try to give you an argument why it is important to include those changes directly on Debian. I have updated my debian-8 based VM to debian-9. Now, I have two "conflicting" libxen-dev packages from different repositories: qubes' repo is version 4.6.4-26+deb9u1, that is lower than the stretch (or sid) repo's: 4.8.1~pre.2017.01.23-1, so apt prefers the latter. This is maybe out of the scope of the original issue, but from my debian user point of view, I would need to fix this first. So, this is a problem that arises when you upgrade a Qubes TemplateVM from Debian 8 to Debian 9, then try to build Qubes in an AppVM based on that TemplateVM?

It seems I am mixing different things here. I reported this issue after looking at how to close the Intend To Package (ITP) Debian bug for the Qubes vchan libraries: https://bugs.debian.org/837905 which means uploading the package to Debian. To answer your question: no, it is not a problem that arises on my upgraded vm. At least, it is no longer the case. It was maybe a bad example, that I am not able to re-reproduce right now (apt does take into account the 2001 version epoch). So, forget about it :-P I was trying to give reasons for including the qubes-specific changes into the Xen Debian package, needed to build qubes-core-vchan-xen.

[andrewdavidwong]

Ok, thanks!

[andrewdavidwong]

Ok, thanks!