Bug#1041865: AW: Bug#1041865: debos: Output of apt action not shown when running debos in noninteractive shell
Hi Christopher, thank you very much for sharing your finding about the complete raw log! Indeed we can see the whole output of apt actions there. I think this is a satisfying workaround, especially since this seems to be an issue which needs to be fixed elsewhere. Best regards Tobias
Bug#930684: pbuilder: creation of build env fails when run inside Docker container
Am Dienstag, 18. Juni 2019, 21:10:53 CEST schrieb Thorsten Glaser:
> Tobias Junghans dixit:
> >I tried to upgrade my Docker-based pbuilder containers from stretch to
>
> Erm… why do you use chroots inside of chroots? That’s… tricky.
Simple because we use Gitlab Runners with the builtin Docker Executor
(https://docs.gitlab.com/runner/executors/docker.html) for running all kinds
of jobs in a generic manner. Depending on the project individual pre-built
Docker images (specified in the CI config) providing the desired build tools
and toolchains are used. The jobs for building Debian packages use a Docker
container with Debian and pbuilder installed.
This used to work for years but for Buster-based containers (i.e. pbuilder and
debootstrap from Buster) it doesn't any longer.
> >mount: failed to read mtab: No such file or directory
>
> This might be a container issue.
The mounts are fine before running pbuilder/debootstrap. Afterwards proc is
not mounted even in the Docker container. The state of the container and its
mounts shouldn't change when running debootstrap. I also saw Docker/container-
related changes between 1.0.89 (stretch) and buster (1.0.114) which likely
cause the misbehaviour:
https://salsa.debian.org/installer-team/debootstrap/commit/
5a0f16664066b24c42c074643a4ca178890d7af7
https://salsa.debian.org/installer-team/debootstrap/commit/
0962af1527a1ba0e996a0b442b159b4dbf164988
https://salsa.debian.org/installer-team/debootstrap/commit/
1e7549c57c0f15816c89c4f243051785ca383be9
> >mount: /proc: mount(2) system call failed: Too many levels of symbolic
> >links.
> Check if /proc outside of pbuilder but inside the container is right.
/proc in the container is fine, see first output of "cat /proc/mounts
" in by original bug report.
> But with {cow|p}builder --login --save-after-login you can
> upgrade the base to buster inside pbuilder.
It's not about the pbuilder environment itself but the Docker container used
for invoking pbuilder/debootstrap. Using a stretch-based Docker container and
debootstrapping Buster works fine.
Thanks and best regards
Tobias
Bug#930684: pbuilder: creation of build env fails when run inside Docker container
Package: pbuilder Version: 0.230.4 Severity: important Tags: upstream Hi, I tried to upgrade my Docker-based pbuilder containers from stretch to buster. However it appears that pbuilder and/or debootstrap do not work properly inside Docker containers any longer due to issues with mounting special filesystems such as proc and devpts. The issue can be reproduced easily in a Debian Buster based container: # docker run --privileged -it debian:buster /bin/bash root@d81f634fe4a0:/# cat /proc/mounts overlay / overlay rw,relatime,lowerdir=/var/lib/docker/overlay2/l/TPOD4JNRBNCTMXNHYCY5XVRBQ3:/var/lib/docker/overlay2/l/TSD62UVCIJQ2LJ4XTUHKTVEK77,upperdir=/var/lib/docker/overlay2/aa29cac2d0ebecfb12fdd71a9952845140052615f2bd746c4336daa8d7a4d533/diff,workdir=/var/lib/docker/overlay2/aa29cac2d0ebecfb12fdd71a9952845140052615f2bd746c4336daa8d7a4d533/work 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /dev tmpfs rw,nosuid,size=65536k,mode=755 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /sys/fs/cgroup tmpfs rw,nosuid,nodev,noexec,relatime,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0 cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0 mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0 /dev/sdb /etc/resolv.conf ext4 rw,noatime,nodiratime,commit=300,data=ordered 0 0 /dev/sdb /etc/hostname ext4 rw,noatime,nodiratime,commit=300,data=ordered 0 0 /dev/sdb /etc/hosts ext4 rw,noatime,nodiratime,commit=300,data=ordered 0 0 shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=65536k 0 0 devpts /dev/console devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0 root@d81f634fe4a0:/# apt-get update && apt-get -y --no-install-recommends install pbuilder [...] root@d81f634fe4a0:/# pbuilder create --distribution buster W: /root/.pbuilderrc does not exist W: cgroups are not available on the host, not using them. I: Distribution is buster. I: Current time: Tue Jun 18 13:27:34 UTC 2019 I: pbuilder-time-stamp: 1560864454 I: Building the build environment I: running debootstrap /usr/sbin/debootstrap I: Retrieving InRelease I: Checking Release signature I: Valid Release signature (key id 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC) I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Checking component main on http://deb.debian.org/debian... I: Retrieving libacl1 2.2.53-4 I: Validating libacl1 2.2.53-4 [...] W: Failure trying to run: chroot "/var/cache/pbuilder/build/489" mount -t proc proc /proc W: See /var/cache/pbuilder/build/489/debootstrap/debootstrap.log for details [...] Setting up aptitude (0.8.11-7) ... update-alternatives: using /usr/bin/aptitude-curses to provide /usr/bin/aptitude (aptitude) in auto mode Processing triggers for libc-bin (2.28-10) ... I: Copying back the cached apt archive contents I: new cache content 'aptitude-common_0.8.11-7_all.deb' added I: new cache content 'libboost-iostreams1.67.0_1.67.0-13_amd64.deb' added I: new cache content 'aptitude_0.8.11-7_amd64.deb' added I: new cache content 'libsqlite3-0_3.27.2-3_amd64.deb' added I: new cache content 'libxapian30_1.4.11-1_amd64.deb' added I: new cache content 'libcwidget3v5_0.5.17-11_amd64.deb' added I: new cache content 'libboost-system1.67.0_1.67.0-13_amd64.deb' added I: new cache content 'libsigc++-2.0-0v5_2.10.1-2_amd64.deb' added mount: failed to read mtab: No such file or directory mount: failed to read mtab: No such file or directory I: unmounting dev/pts filesystem I: unmounting dev/shm filesystem I: unmounting proc filesystem I: unmounting sys filesystem I: creating base tarball [/var/cache/pbuilder/base.tgz] mount: failed to read mtab: No such file or directory I: cleaning the build env I: removing directory /var/cache/pbuilder/build/489 and its subdirectories rm: cannot remove '/var/cache/pbuilder/build/489/dev/ptmx': Device or resource busy mount: failed to read mtab: No such file or directory I: cleaning the build env I: removing directory /var/cache/pbuilder/build/489 and its subdirectories rm: cannot remove
Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)
Hi Mike, Am Montag, 14. Januar 2019, 11:06:36 CET schrieb Mike Gabriel: > Veyon is now in Debian unstable. Perfect, thanks a lot for your work on this! > I have just uploaded 4.1.6. OK. If you want you can update to 4.1.7 which simply adds new translations and updates existing ones (no other changes for Linux in this release). > I will skip 4.1.90. When do you expect 4.2.0 do be out? Will you make > it before the Debian soft freeze (2019-02-12)? No, Veyon 4.2 will be finished not before the end of Q1/2019. Besides that I fear it initially won't be as stable as Veyon 4.1.x is now due to some major internal changes. Best regards Tobias
Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)
Hi Mike, Am Freitag, 28. Dezember 2018, 11:12:01 CET schrieb Mike Gabriel: > in some previous mail, you mentioned that you have dropped some copies > of code (or that it is possible to do that when repacking). > > Can you be more specific on that? All non-required 3rdparty files are deleted before creating the source tarball, see the strip-scripts at https://github.com/veyon/veyon/tree/ 4.1/.travis/common for details. The source tarball now only includes files required for building Veyon. Best regards Tobias
Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)
Hi Mike, Am Freitag, 7. Dezember 2018, 10:45:16 CET schrieb Mike Gabriel: > > * as of upcoming 4.1.6 release you should reconsider to not repack the > > source tarball as all unused source files (except for > > x11vnc/libvncserver) will get stripped anyway > > (https://github.com/veyon/veyon/commit/ > > cc54151fb31524bd67a6160acaac1204f55e9ccd). > > That is great news!!! When is the due date of 4.1.6. Will you make it > for Debian buster's soft freeze (midst of February)? > https://wiki.debian.org/DebianBuster FYI: 4.1.6 has been released about 1 week ago and includes most of your patches. Best regards Tobias
Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)
Hi Mike, > Uploaded 20min ago. Perfect, thanks a lot! A few questions and suggestions for future uploads though: * switch project website (https://veyon.io) to https in Homepage field * use lower-case for github group for Source field * update to 4.1.5 * replace "iTALC" with "Veyon" in copyright * why is kde-baseapps-bin recommended? Veyon is not KDE-related at all * as of upcoming 4.1.6 release you should reconsider to not repack the source tarball as all unused source files (except for x11vnc/libvncserver) will get stripped anyway (https://github.com/veyon/veyon/commit/ cc54151fb31524bd67a6160acaac1204f55e9ccd). Best regards Tobias
Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)
Hi Mike, thank you very much for your efforts! I'll try to adopt as many of the changes as possible for the 4.1.6 release. Regarding the package structure: everything looks fine so far. You could put veyon-ctl in a separate package but probably it's better to postpone this step until Veyon 4.2 has been released (where we'll rename veyon-ctl to veyon-cli which would lead to package renames and the first transitional packages). Do you plan to add transitional packages for existing iTALC installations so that users get migrated to Veyon automatically? Regarding libvncserver/libvncclient: I'm actively working with upstream to get all Veyon-specific changes merged in a generic manner so we can use an existing libvncclient library from the system. Currently the only thing left is to disable the broken (non thread-safe) IPv4 support in favor of the new (existing and generic) IPv6 code in libvncclient. Once libvncserver 0.9.12 is released and about to be packaged we could even solve this with a small Debian-specific patch. > Furthermore, here comes another request: how could we bring the Veyon > documentation files (as source files, as built Sphinx documentation) > into Debian? I'd say it makes sense having those docs packaged, so > they can be made available offline. As you probably already know the sources for the docs are available at https://github.com/veyon/docs and can be built via sphinx easily. For future releases I can create tags for the docs as well so you can simply download a tarball which can be used as source tarball for a separate veyon-docs package. Best regards Tobias
Bug#887394: Packaging Veyon (was: Re: Accepted italc 1:3.0.3+dfsg1-2 (source) into unstable)
Hi Mike, any news on packaging Veyon for Debian? We released 4.1.1 this week and it's quite a mature release which deserves being packaged for Debian before feature freeze. Best regards Tobias Am Dienstag, 6. Februar 2018, 14:21:16 CEST schrieben Sie: > Hi Tobias, > > a quick top posted mail... Can you also describe the dependency tree? > > Master needs service and libveyon-core. > Configurator? Would it work standalone? > Master should probably recommend configurator. > > Service needs Auth-Helper and Worker (they should be in the same package... > IMHO). > veyon-ctl is useful for whom? For the PC running the Master application? Or > is it more useful on the PCs running the Service? > And the Plugins? Needed on Master or on client systems running the Service? > > Thanks, Mike
