To the developers of sbuild: If sbuild is used on a desktop machine (which is running CUPS) and the package built inside sbuild has a "BuildRequires: cups-daemon" making another instance of CUPS running in sbuild's chroot, could this lead to conflicts like both CUPS daemons claiming port 631 and so the later daemon (in sbuild's chroot) not starting up correctly?
The problem of two conflicting CUPS daemons should not occur on servers as on servers CUPS is usually not running (only on print servers, and I cannot imaging that the build cluster servers are also print servers). But nevertheless we should find a fix to allow developers to use sbuild on desktop machines. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1616548 Title: Cups causes LibreOffice unittests to loop in a sbuild Status in cups package in Ubuntu: Incomplete Status in sbuild package in Ubuntu: Incomplete Bug description: When building LibreOffice 1:5.2.0-0ubuntu1 on a xenial host with a yakkety sbuild, e.g. by: sbuild -A -d yakkety-amd64 (...).dsc this loops/busy hangs with unittests. This was working ok up to 5.2.0~rc4 (=final), it is a regression by a LibreOffice dependency, most likely CUPS, which was updated. I tried to inject debug symbols by running with a: --chroot-setup- command and then run something along the lines of: apt install cups wget http://launchpadlibrarian.net/278966811/cups-dbgsym_2.2~rc1-4_amd64.ddeb wget http://launchpadlibrarian.net/278966816/libcups2-dbgsym_2.2~rc1-4_amd64.ddeb dpkg -i cups-dbgsym_2.2~rc1-4_amd64.ddeb dpkg -i libcups2-dbgsym_2.2~rc1-4_amd64.ddeb before starting the build proper, but I got only marginally better debug info. The hanging LibreOffice test processes usually have 2-4 child processes. The parent and one of the childs are busy, while the rest idle. Here is a stacktrace of the busy child: Program received signal SIGPIPE, Broken pipe. 0x00002b0a80dd615f in fgetspent (stream=0x11) at fgetspent.c:43 43 in fgetspent.c (gdb) bt #0 0x00002b0a80dd615f in fgetspent (stream=0x11) at fgetspent.c:43 #1 0x000000000000001e in ?? () #2 0x000055c4976981e0 in ?? () #3 0x00002b0a8aff8d20 in ipp_options () from /usr/lib/x86_64-linux-gnu/libcups.so.2 #4 0x0000000000004002 in ?? () #5 0x00002b0a8ada9feb in ppdCollect2 (ppd=0x2b0a8ada9bdf <cupsGetDestMediaDefault+415>, section=29, min_order=0, choices=0x2b0a8adad6f3 <cupsFileGetConf+467>) at emit.c:145 #6 0x0000000000000000 in ?? () Here is a stacktrace of the busy parent: Thread 3 "CUPSManager cup" received signal SIGPIPE, Broken pipe. 0x00002b0a80dd615f in fgetspent (stream=0x11) at fgetspent.c:43 43 in fgetspent.c (gdb) bt #0 0x00002b0a80dd615f in fgetspent (stream=0x11) at fgetspent.c:43 #1 0x000000000000001e in ?? () #2 0x000055c4976981e0 in ?? () #3 0x00002b0a8aff8d20 in ipp_options () from /usr/lib/x86_64-linux-gnu/libcups.so.2 #4 0x0000000000004002 in ?? () #5 0x00002b0a8ada9feb in ppdCollect2 (ppd=0x2b0a8ada9bdf <cupsGetDestMediaDefault+415>, section=29, min_order=0, choices=0x2b0a8adad6f3 <cupsFileGetConf+467>) at emit.c:145 #6 0x0000000000000000 in ?? () When pressing "c" in gdb to continue, both processes stop very quickly again with the SIGPIPE. Venturing a guess: Is the signal handling of CUPS b0rked? As fgetspent reads the shadow file[1], maybe there are missing permissions or other sandbox issues that CUPS doesnt handle error cases for properly? [1] http://linux.die.net/man/3/fgetspent To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1616548/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
