Bug#1029125: Please update to a 2.x version
Source: python-google-auth Version: 1.5.1-3 Severity: wishlist Hey, Version 2.0 was released well over a year ago now :). It would be great to update to a reent 2.x version -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf, arm64 Kernel: Linux 6.0.0-6-amd64 (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1028451: 2nd DisplayPort doesn't get video
Hey, On Sat, 2023-01-14 at 16:30 +0100, Salvatore Bonaccorso wrote: > Hi, > > On Thu, Jan 12, 2023 at 02:51:05PM +0100, Diederik de Haas wrote: > > On Thursday, 12 January 2023 12:03:24 CET Sjoerd Simons wrote: > > > Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked > > > upstream here: > > > https://gitlab.freedesktop.org/drm/amd/-/issues/2171 > > > > Thanks! About an hour ago the suggested fix was to revert commit > > 4d07b0bc403403438d9cf88450506240c5faf92f part of v6.1-rc1 > > > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2 > > describes a procedure to build a kernel with the proposed patch (attached). > > > > OdyX: Can you try to see whether that resolves the issue? > > Should we keep 6.1.y based kernel out of testing until this is clear? Basically this issue breaks all usage of Displayport MST on amdgpu systems. Which roughly translates to breaking external monitors for everyone using an USB-C docks with multiple display outputs (which is pretty common these days) on AMD laptops. As well as those like myself who daisy-chain display port monitors with an amdgpu using graphics card. So I would expect this impacts a lot of people :/ Which is also why there is loads of activity and duplicates on the fd.o bug now that 6.1 is trickling into distributions. > As we aim though to have 6.1.y into bookworm I would see it as more > preferable to get 6.1.4 in for testing, we will need to followup as > well soonish with another interation for e.g. for fixing > CVE-2023-0266. > > Now if it turns out that this is the same issue as the referenced > upstream, reverting I think we only should really revert the commit if > that's queued up for 6.1. There is currently some furhter discussion > on > https://lore.kernel.org/stable/dcf0612f-7d40-d607-e9aa-94599594e...@amd.com/T/#m38bdafb9c6c64b167ec94ac1bd131f1d2db66e4 > Given the size of the revert, there is as well a chance to re-break > other parts. So preferring to closely follow upstream here, whatever > the decision will be. For what it's worth; The revert as currently suggested also reverts big chunks for Intel and nvidia based GPUs, which unsurprisingly the maintainers of those aren't too thrilled about. And really i'd be amazed if it doesn't cause regressions for those systems... Unless the AMD folks pull a small/targetted fix out their hats, this is likely going to take weeks if not months before it's resolved in a way that's acceptable for 6.1.y :/ -- Sjoerd Simons
Bug#1028451: 2nd DisplayPort doesn't get video
Source: linux Followup-For: Bug #1028451 Fwiw there is a general regression with AMDGPU MST on linux 6.1; tracked upstream here: https://gitlab.freedesktop.org/drm/amd/-/issues/2171 As the original report was about a second displayport on a docking station I would guess it's the same issue. For reference i'm hit by the same issue due to using MST for daisy-chaining monitors. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf, arm64 Kernel: Linux 6.0.0-6-amd64 (SMP w/32 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1016963: Please test u-boot for rpi_4 rpi_4_32b
Hey, On Fri, 2023-01-06 at 16:36 +0100, Andreas Henriksson wrote: > On Tue, Jan 03, 2023 at 11:56:51PM +0100, Andreas Henriksson wrote: > > On Tue, Jan 03, 2023 at 11:46:31PM +0100, Andreas Henriksson wrote: > > > On Wed, Dec 28, 2022 at 04:11:04PM -0800, Vagrant Cascadian > > > wrote: > > > > rpi_4 > > > > rpi_4_32b > [...] > > Hello again, > > While I only have the earliest rpi 4B rev A0 (1.1) it has come to > my attention that apparently there's a revision C0 (1.4) that > has problems booting with u-boot. > > Apparently in 1.4 revision they changed the hardware in > an incompatible way and then cover this up by having the > proprietary firmware modify the dtb in ram to change nodes > as needed. Yes that revision has a newer version of the SoC same/similar as in the rpi 400 > The issue has been discussed on the rpi forums: > https://forums.raspberrypi.com/viewtopic.php?t=315662 > > There has been seemingly two indenpendent attempts at submitting > (very similar) patches upstream to adress this in u-boot: > https://lists.denx.de/pipermail/u-boot/2021-November/468322.html > https://lists.denx.de/pipermail/u-boot/2021-September/462020.html > ... but apparently they've never been merged. Fwiw this came up on the u-boot list again today: https://lists.denx.de/pipermail/u-boot/2023-January/504038.html Lets see if things move forward this year.. Fwiw the latest upstream attempt i saw was Antoine's patch series: https://lists.denx.de/pipermail/u-boot/2022-August/491455.html Which resent my patch + added some additional tweaks. > > NixOS are carrying patches: > https://github.com/NixOS/nixpkgs/tree/master/pkgs/misc/uboot > which includes some revision of Sjoerds patch. > > Some info on board revisions can be found at: > https://www.raspberrypi-spy.co.uk/2012/09/checking-your-raspberry-pi-board-version/ > > This issue probably deserves it's own separate bug report, > but since I don't have the hardware in question I'm leaving that > to who ever else cares and just share the info I have. > > It might be useful to consider just include NixOS/Sjoerds patch > or documenting that RPi 4B hw rev 1.4 will not work. > (Hardware revision is visible in /proc/cpuinfo under the Revision: > field.) > However it maybe best trying to find someone who has the affected > hardware revision that can confirm the problem exists and that > the patch actually resolves it. I can confirm both the problem and the patch solving it :) -- Sjoerd Simons
Bug#981153: cargo: Please package new upstream
Hey, Fwiw; MR for prepping an update to cargo 0.56 is available at: https://salsa.debian.org/rust-team/cargo/-/merge_requests/9 Full example update on my salsa repo: https://salsa.debian.org/sjoerd/cargo/-/tree/debian/experimental On Tue, Aug 10, 2021 at 11:13:05AM +0200, Sjoerd Simons wrote: > On Wed, Jan 27, 2021 at 10:52:17AM +0900, Mike Hommey wrote: > > Source: cargo > > Version: 0.47.0-3 > > Severity: wishlist > > > > Firefox now requires version 0.48, latest upstream is 0.50, and unstable > > is on 0.47. > > Fwiw; with Cargo 0.51 the new resolver feature has been stablelized [0]. I'm > starting to hit issues when building with various crates from the ecosystem as > that's starting to be adopted now. > > 0: > https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#cargos-new-feature-resolver
Bug#995432: Please blacklist expired DST Root CA X3 certificate
Hey, On Fri, 2021-10-01 at 14:12 +0200, Julien Cristau wrote: > On Fri, Oct 01, 2021 at 10:14:27AM +0200, Sjoerd Simons wrote: > > Package: ca-certificates > > Version: 20210119 > > Severity: normal > > > > This is a similar situation as #961907. The DST Root CA X3 > > certificate in > > ca-certificates has expired, which is a signer for "ISRG Root X1", > > which in > > turn i used by Letsencrypt. This causes some (older?) SSL > > implementation to > > mark letsencrypt certificates as expired even though there is a > > trusted valid > > "intermediate" > > > Which implementations are affected? I know of openssl 1.0.2, which > is > not in any supported Debian release. Are recent versions of gnutls > affected by this bug? Recent versions aren't; For the ones in Debian itself it seems this last was an issue with the gnutls version in Jessie (which is out of LTS, but in ETLS). So the issues mainly crop-up with application that have embedded (older) ssl stack but use the system certificates. Given that blacklisting the cert seems easy to do and afaik doesn't have any real downsides it's probably still a good thing to do even if it's less relevant for debian by now? -- Sjoerd Simons
Bug#995432: Please blacklist expired DST Root CA X3 certificate
Package: ca-certificates Version: 20210119 Severity: normal This is a similar situation as #961907. The DST Root CA X3 certificate in ca-certificates has expired, which is a signer for "ISRG Root X1", which in turn i used by Letsencrypt. This causes some (older?) SSL implementation to mark letsencrypt certificates as expired even though there is a trusted valid "intermediate" -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-proposed-updates'), (500, 'oldstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf, arm64 Kernel: Linux 5.14.0-1-amd64 (SMP w/32 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ca-certificates depends on: ii debconf [debconf-2.0] 1.5.77 ii openssl1.1.1l-1 ca-certificates recommends no packages. ca-certificates suggests no packages. -- debconf information excluded
Bug#981153: cargo: Please package new upstream
On Wed, Jan 27, 2021 at 10:52:17AM +0900, Mike Hommey wrote: > Source: cargo > Version: 0.47.0-3 > Severity: wishlist > > Firefox now requires version 0.48, latest upstream is 0.50, and unstable > is on 0.47. Fwiw; with Cargo 0.51 the new resolver feature has been stablelized [0]. I'm starting to hit issues when building with various crates from the ecosystem as that's starting to be adopted now. 0: https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html#cargos-new-feature-resolver
Bug#988194: node-got: package.json files not installed for some nodejs packages
Control: severity -1 serious Bumping severity up to serious; Due to this issue node-got on rebuild will not get all expected nodejs packages in the binary package, causing it to be broken. Which is obviously somewhat serious e.g. when it has to be rebuild due to a security fix or similar On Fri, May 07, 2021 at 09:08:22AM -0300, Ariel D'Alessandro wrote: > Package: node-got > Version: 11.8.1+~cs53.13.17-1 > Severity: normal > > Dear Maintainer, > > Recent versions (>=0.9.57) of pkg-js-tools are ignoring entries from > each node package's .npmignore. This is the behaviour since the > .npmignore feature was fixed: > > > https://salsa.debian.org/js-team/pkg-js-tools/-/commit/282af45151cf109315b120c90e347d5acf19a039 > > Some packages contain a .npmignore file that will ignore everything but > src/, causing installation to omit package.json files: > > > https://salsa.debian.org/js-team/node-got/-/blob/master/responselike/.npmignore > > Because of this, packages depending on node-got have reported missing > modules due to package.json files not found in these packages: > clone-response, keyv, responselike. > > The behaviour is strange because I'd expect package.json to be always > installed despite .npmignore content. Note that this is the default npm > behaviour described in the docs: > > > https://docs.npmjs.com/cli/v7/using-npm/developers#keeping-files-out-of-your-package > > A possible solution is to remove all .npmignore files from these nodejs > packages. This way, all files are installed, including package.json. > > If pkg-js-tools behaviour isn't the expected one, this bug should be > reported there and fixed properly. > > Regards, > Ariel > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE > not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages node-got depends on: > ii node-decompress-response 6.0.0-1 > ii node-get-stream 6.0.0-1 > ii node-json-buffer 3.0.1-1 > ii node-lowercase-keys 2.0.0-1 > ii node-mimic-response 3.1.0-5 > ii node-p-cancelable 2.0.0-1 > ii nodejs12.21.0~dfsg-4 > > node-got recommends no packages. > > node-got suggests no packages. > > -- no debconf information
Bug#987714: Depends/Suggests/Recommends are generate from the apt-cache avail list which is unpredictable
Package: dh-r Severity: normal Tags: ftbfs Hey, For context: we've got a debian derivative distribution that builds using open-build-system (aka OBS). Unlike the debian buildd the apt cache isn't available in the builds and if it was made available it would only be for the set of installed packages (e.g. the build-depends) not the whole distribution. However I think the underlying issues are more general and apply to Debian as well. Fundamentally the apt cache list is not deterministic regardless so the substvars end up being non-determinstic even if the same set of build-depends are installed in the build environment which is awkward. However the biggest issue is see is that package not being resolvable end up being ignored with a warning rather then failing the build, which makes it hard to detect (unexpected) issues. -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf, arm64 Kernel: Linux 5.10.0-6-amd64 (SMP w/32 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-r depends on: ii dctrl-tools 2.24-3+b1 ii debhelper13.3.4 ii libfile-which-perl 1.23-1 ii libswitch-perl 2.17-2.1 pn libwww-curl-simple-perl pn r-base-dev Versions of packages dh-r recommends: pn cme ii devscripts2.21.1 ii git-buildpackage 0.9.22 Versions of packages dh-r suggests: pn postgresql-client-common
Bug#982853:
On Wed, 2021-02-24 at 12:03 +0100, Michael Schaller wrote: > I was able to reproduce the issue on vanilla Debian testing by > purging > the `dbus-user-session` package, which is currently blocked in our > fleet for Reasons (TM). Aha that explains; From debians perspective i think the best solution is to put dbus-user-session in recommands (similar to what pulse already has). What you mention also means the cinnamon session (or gdm) doesn't set the DISPLAY env var on the systemd sessions, which would likely break anything requiring the session dbus.. > Reproduction instructions: > > 1) Install VM via the Debian stable `mini.iso` (Debian testing was > broken) with all the defaults except the `software to install` > selection was completely empty, particularly no desktop environment. > Image source was: > https://deb.debian.org/debian/dists/stable/main/installer-amd64/current/images/netboot/mini.iso > > 2) Update to Debian testing. > $ sudo sed -i 's/buster/testing/g' /etc/apt/sources.list > $ sudo sed -i '/security/d' /etc/apt/sources.list > $ sudo apt update > $ sudo DEBIAN_FRONTEND=noninteractive apt -o > Dpkg::Options::=--force-confnew -o Dpkg::Options::=--force-confdef > dist-upgrade > $ sudo reboot > > 3) Install GDM and Cinnamon > $ sudo apt install gdm3 cinnamon > $ sudo reboot > > 4) Log into Cinnamon from GDM > Note: pipewire succeeds to start. > > 5) Remove dbus-user-session > $ sudo apt purge dbus-user-session > $ sudo reboot > > 6) Log into Cinnamon from GDM > Note: pipewire fails to start. -- Sjoerd Simons
Bug#983379: Panic on startup
Package: user-mode-linux Version: 5.10um1+b1 Severity: grave On startup of uml in e.g. fakemachine it panics straight away: ``` $ fakemachine -b uml "uname -a" kmsg_dump: <5>Linux version 5.10.5 (buildd@x86-conova-01) (gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 Mon Jan 11 20:40:53 UTC 2021 <6>Zone ranges: <6> Normal [mem 0x-0xe164] <6>Movable zone start for each node <6>Early memory node ranges <6> node 0: [mem 0x-0x8164] <6>Initmem setup node 0 [mem 0x-0x8164] <7>On node 0 totalpages: 53 <7> Normal zone: 8282 pages used for memmap <7> Normal zone: 0 pages reserved <7> Normal zone: 53 pages, LIFO batch:63 <7>pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 <7>pcpu-alloc: [0] 0 <6>Built 1 zonelists, mobility grouping on. Total pages: 521718 <5>Kernel command line: mem=2048M initrd=/tmp/fakemachine-981932232/initramfs.cpio panic=-1 nosplash systemd.unit=fakemachine.service console=tty0 vec0:transport=fd,fd=3,vec=0 quiet con1=fd:0,fd:1 con0=null con=none root=98:0 <6>Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear) <6>Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear) <6>mem auto-init: stack:off, heap alloc:off, heap free:off <6>Memory: 2044088K/212K available (5830K kernel code, 1535K rwdata, 1744K rodata, 191K init, 225K bss, 75912K reserved, 0K cma-reserved) <6>SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 <6>NR_IRQS: 24 <6>clocksource: timer: mask: 0x max_cycles: 0x1cd42e205, max_idle_ns: 881590404426 ns <6>Calibrating delay loop... 4213.14 BogoMIPS (lpj=21065728) <6>pid_max: default: 32768 minimum: 301 <6>LSM: Security Framework initializing <6>Yama: disabled by default; enable with sysctl kernel.yama.* <6>SELinux: Initializing. <6>TOMOYO Linux initialized <6>Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) <6>Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear) <4> <4>Modules linked in: <6>Pid: 0, comm: swapper Not tainted 5.10.5 <6>RIP: 0033:[<604d4201>] <6>RSP: 7ffdc7521cb0 EFLAGS: 00010206 <6>RAX: RBX: 0059 RCX: 7ffdc752 <6>RDX: 0035 RSI: 60b69a71 RDI: 60d8ac3b <6>RBP: R08: 60b69a72 R09: 60d8abe2 <6>R10: 8000 R11: 3d74696e695f676e R12: 0002 <6>R13: 0005 R14: R15: 0001 <0>Kernel panic - not syncing: Segfault with no mm <4>CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.5 #1 <4>Stack: <4> 623e3d20 8000 7fd9ee013908 7fd9ee013ae5 <4> 7fd9ee4629e8 7ffdc7521cf0 0400 <4> 7fd9ee409f20 7fd9ee4629e8 Call Trace: <4> [<604d4fa3>] ? __printk_safe_enter+0x0/0x35 <4> [<604d154a>] ? arch_local_irq_save+0x0/0x22 <4> [<604d46f5>] ? vprintk_emit+0x9d/0x185 <4> [<604d49d3>] ? vprintk_deferred+0x1d/0x32 <4> [<60a26ee2>] ? printk_deferred+0x93/0x9b <4> [<6088f79f>] ? bucket_table_alloc.isra.0+0x115/0x13d <4> [<60a26e4f>] ? printk_deferred+0x0/0x9b <4> [<6049cddb>] ? set_signals+0x0/0x38 <4> [<60589588>] ? arch_local_irq_save+0x0/0x22 <4> [<6055c928>] ? kvmalloc_node+0x56/0x96 <4> [<6058d3c0>] ? __kmalloc+0x1e2/0x1f9 <4> [<608e3d32>] ? ___ratelimit+0xd0/0xde <4> [<6088f79f>] ? bucket_table_alloc.isra.0+0x115/0x13d <4> [<60901485>] ? _warn_unseeded_randomness+0x60/0x8f <4> [<6090295b>] ? get_random_u32+0x29/0x98 <4> [<6088f79f>] ? bucket_table_alloc.isra.0+0x115/0x13d <4> [<6088f68a>] ? bucket_table_alloc.isra.0+0x0/0x13d <4> [<6088ff7a>] ? rhashtable_init+0x175/0x1ca <4> [<607ef317>] ? ipc_init_ids+0x4e/0x6f <4> [<600153bd>] ? sem_init+0x17/0x45 fakemachine: error starting uml backend: ``` -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf, arm64 Kernel: Linux 5.10.0-3-amd64 (SMP w/32 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages user-mode-linux depends on: ii libc6 2.31-9 Versions of packages user-mode-linux recommends: ii uml-utilities 20070815.4-1 Versions of packages user-mode-linux suggests: ii gnome-terminal [x-terminal-emulator] 3.38.3-1 pn rootstrap ii rxvt-unicode [x-terminal-emulator]9.22-8+b1 ii slirp 1:1.0.17-11 pn user-mode-linux-doc pn vde2 ii xterm [x-terminal-emulator] 366-1 -- no debconf information
Bug#978621: pipewire: Drag and drop a file in Dolphin makes pipewire crash KDE Plasma Wayland
On Tue, Dec 29, 2020 at 11:46:22AM +0100, Silvério Santos wrote: > Package: pipewire > Version: 0.3.15-1 > Severity: normal > > Dear Maintainer, > > Since the update to KDE Plasma 5.20 Dolphin makes the whole session crash, > displaying the login screen instead of completing the following process: > 1. Grab a .ly file > 2. Drag it to a subfolder > 3. Before reaching the subfolder, the session is closed and the SDDM login > screen is displayed. This also happens when trying to drag outside of the fie > list to avoid hovering over other files. Does this still happen with newer pipewire ? But more importantly why the conclusion that this is a pipewire bug not a dolphin (or another plasma component)? Regards, Sjoerd
Bug#982853:
On Mon, Feb 15, 2021 at 02:37:53PM +0100, Michael Schaller wrote: > I've installed `xdg-desktop-portal-gtk` and rebooted but that didn't > solve the issue either. > From the timestamps it looks like `xdg-desktop-portal` isn't starting > fast enough. > > ``` > $ journalctl --user --boot --output=short-iso-precise --unit pipewire.service > -- Journal begins at Fri 2021-02-05 11:44:35 CET, ends at Mon > 2021-02-15 14:37:02 CET. -- > 2021-02-15T14:11:35.860927+0100 misch-x1v6 systemd[2659]: Started > Multimedia Service. > 2021-02-15T14:11:35.911895+0100 misch-x1v6 pipewire[2678]: Failed to > connect to system bus: Unable to autolaunch a dbus-daemon without a > $DISPLAY for X11 > 2021-02-15T14:11:35.911906+0100 misch-x1v6 pipewire[2678]: Failed to > connect to system bus The error message from pipewire is misleading here; This really means it's failing to connect to your sessions d-bus service. With the warnings above that means your session neither set the DISPLAY variable (as used for old-school autolaunching) nor is the user dbus.socket service enabled/running? Which in turns points to a setup issue of your user session really. How is your session started ? can you check the status of your users dbus.socket? Regards, Sjoerd
Bug#982796: buster-pu: package avahi/0.7-4
dns_reachable ; then
- # No unicast dns server reachable, so enable avahi
- enable_avahi
- # And blow away the dns cache, so we force a recheck when the interface comes
- # up again
- rm -f ${NS_CACHE}
- exit 0
-fi
-
-# Check if the dns needs checking..
-dns_needs_check || exit 0
-
-if dns_has_local ; then
- # .local from dns server, disabling avahi
- disable_avahi
-else
- # no .local from dns server, enabling avahi
- enable_avahi
-fi
-
-exit 0
diff -Nru avahi-0.7/debian/avahi-daemon.if-up
avahi-0.7/debian/avahi-daemon.if-up
--- avahi-0.7/debian/avahi-daemon.if-up 2018-04-27 12:59:11.0 +0200
+++ avahi-0.7/debian/avahi-daemon.if-up 1970-01-01 01:00:00.0 +0100
@@ -1,16 +0,0 @@
-#!/bin/sh
-
-# Don't run the avahi-daemon unicast local check while bringing up
-# the loopback device; it's not necessary until we bring up a real network
-# device
-[ "$IFACE" != "lo" ] || exit 0
-case "$ADDRFAM" in
- inet|inet6) ;;
- *) exit 0 ;;
-esac
-
-# If we have an unicast .local domain, we immediately disable avahi to avoid
-# conflicts with the multicast IP4LL .local domain
-if [ -x /usr/lib/avahi/avahi-daemon-check-dns.sh ] ; then
- exec /usr/lib/avahi/avahi-daemon-check-dns.sh
-fi
diff -Nru avahi-0.7/debian/avahi-daemon.links
avahi-0.7/debian/avahi-daemon.links
--- avahi-0.7/debian/avahi-daemon.links 2018-04-27 12:59:11.0 +0200
+++ avahi-0.7/debian/avahi-daemon.links 1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-etc/network/if-up.d/avahi-daemon etc/network/if-post-down.d/avahi-daemon
diff -Nru avahi-0.7/debian/avahi-daemon.maintscript
avahi-0.7/debian/avahi-daemon.maintscript
--- avahi-0.7/debian/avahi-daemon.maintscript 1970-01-01 01:00:00.0
+0100
+++ avahi-0.7/debian/avahi-daemon.maintscript 2021-02-13 20:35:49.0
+0100
@@ -0,0 +1,2 @@
+rm_conffile /etc/network/if-up.d/avahi-daemon 0.7-4+deb10u1~ avahi-daemon
+rm_conffile /etc/resolvconf/update-libc.d/avahi-daemon 0.7.-4+deb10u1~
avahi-daemon
diff -Nru avahi-0.7/debian/avahi-daemon.resolvconf
avahi-0.7/debian/avahi-daemon.resolvconf
--- avahi-0.7/debian/avahi-daemon.resolvconf2018-04-27 12:59:11.0
+0200
+++ avahi-0.7/debian/avahi-daemon.resolvconf1970-01-01 01:00:00.0
+0100
@@ -1,8 +0,0 @@
-#!/bin/sh
-#
-# If we have an unicast .local domain, we immediately disable avahi to avoid
-# conflicts with the multicast IP4LL .local domain
-
-if [ -x /usr/lib/avahi/avahi-daemon-check-dns.sh ]; then
- exec /usr/lib/avahi/avahi-daemon-check-dns.sh
-fi
diff -Nru avahi-0.7/debian/changelog avahi-0.7/debian/changelog
--- avahi-0.7/debian/changelog 2018-04-27 12:59:11.0 +0200
+++ avahi-0.7/debian/changelog 2021-02-13 20:35:49.00000 +0100
@@ -1,3 +1,15 @@
+avahi (0.7-4+deb10u1) buster; urgency=medium
+
+ [ Simon McVittie ]
+ * Remove avahi-daemon-check-dns mechanism, no longer needed.
+Thanks to Trent Lloyd, Sebastien Bacher (LP: #1870824)
+(Closes: #433945, #559927, #629509, #747895, #878586, #898038, #929010)
+
+ [ Sjoerd Simons ]
+ * Don't remove avahi-daemon postdown symlink in maintscript
+
+ -- Sjoerd Simons Sat, 13 Feb 2021 20:35:49 +0100
+
avahi (0.7-4) unstable; urgency=medium
* Team upload
diff -Nru avahi-0.7/debian/control avahi-0.7/debian/control
--- avahi-0.7/debian/control2018-04-27 12:59:11.0 +0200
+++ avahi-0.7/debian/control2021-02-13 20:35:49.0 +0100
@@ -38,7 +38,7 @@
dbus (>= 0.60),
lsb-base (>= 3.0-6),
bind9-host | host
-Recommends: libnss-mdns
+Recommends: libnss-mdns (>= 0.11),
Suggests: avahi-autoipd
Multi-Arch: foreign
Description: Avahi mDNS/DNS-SD daemon
@@ -350,7 +350,7 @@
Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends}
-Recommends: libnss-mdns
+Recommends: libnss-mdns (>= 0.11),
Pre-Depends: ${misc:Pre-Depends}
Multi-Arch: same
Description: Avahi Apple Bonjour compatibility library
diff -Nru avahi-0.7/debian/gbp.conf avahi-0.7/debian/gbp.conf
--- avahi-0.7/debian/gbp.conf 2018-04-27 12:59:11.0 +0200
+++ avahi-0.7/debian/gbp.conf 2021-02-13 20:35:49.0 +0100
@@ -1,5 +1,5 @@
[DEFAULT]
pristine-tar = True
-debian-branch = debian/master
+debian-branch = debian/buster
upstream-branch = upstream/latest
patch-numbers = False
diff -Nru avahi-0.7/debian/rules avahi-0.7/debian/rules
--- avahi-0.7/debian/rules 2018-04-27 12:59:11.0 +0200
+++ avahi-0.7/debian/rules 2021-02-13 20:35:49.0 +0100
@@ -47,10 +47,6 @@
override_dh_auto_install:
dh_auto_install
- install -D -o root -g root -m 755 debian/avahi-daemon.resolvconf \
- debian/avahi-daemon/etc/resolvconf/update-libc.d/avahi-daemon
- install -D -o root -g root -m 755 debian/avahi-daemon-check-dns.sh \
- debian/avahi-daemon/usr/lib/avahi/avahi-daemon-check-dns.sh
ifeq (linux,$(DEB_HOST_ARCH_OS))
mv debian/tmp/etc/dhcp/dhclient-exit-hooks.d/avahi-autoipd \
debian/tmp/etc/dhcp/dhclient-exit-hooks.d/zzz_avahi-autoipd
Bug#982016: [Pkg-utopia-maintainers] Bug#982016: avahi-daemon: a broken link left
On Sat, 2021-02-06 at 10:31 +0100, patrice.dur...@gmail.com wrote: > > Another small point is that this also has left an empty branch: > /etc/resolvconf/update-libc.d > Is it under any another package or dpkg control? > Because I did not found any, neither claiming /etc/resolvconf on my > systems. Testing it in docker shows: ``` Unpacking avahi-daemon (0.8-4) over (0.8-3) ... dpkg: warning: unable to delete old directory '/etc/resolvconf/update- libc.d': Directory not em pty dpkg: warning: unable to delete old directory '/etc/resolvconf': Directory not empty dpkg: warning: unable to delete old directory '/etc/network/if-up.d': Directory not empty dpkg: warning: unable to delete old directory '/etc/network/if-post- down.d': Directory not empt y dpkg: warning: unable to delete old directory '/etc/network': Directory not empty ``` the maint script helpers only remove the old config files in those directories later ; and don't seem to remove empty directories (though in practise those should be harmless ofcourse) -- Sjoerd Simons
Bug#949003: Doesn't work on 64 bit architectures
On Wed, 2020-01-15 at 22:49 +0100, Roberto Lumbreras wrote: > Hi, > > Could you please send me how to reproduce the bug? > It just works for me... but for sure my setup is different. I'm trying to use UML with slirp and it crashes before i even manage to setup a network connection :/ I can have a look at giving you a more specific reproduction method if you can't trigger it but that will probably take a few days at least; from the code it seems it somewhat wack-a-mole still though.. > On Wed, Jan 15, 2020 at 10:03 PM Sjoerd Simons > wrote: > > > Package: slirp > > Version: 1:1.0.17-9 > > Severity: important > > > > The last upload fixes slirp crashes directly on startup on amd64; > > It now > > just crashes > > when starting to use it > > > > backtrace: > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0x5567818fa30b in tcp_reass (tp=tp@entry=0x556782590610, > > ti=0x82590610, ti@entry=0x0, m=, m@entry=0x0) > > at ./tcp_input.c:210 > > 210 ./tcp_input.c: No such file or directory. > > (gdb) bt > > #0 0x5567818fa30b in tcp_reass (tp=tp@entry=0x556782590610, > > ti=0x82590610, ti@entry=0x0, m=, m@entry=0x0) > > at ./tcp_input.c:210 > > #1 0x5567818fb8c1 in tcp_input (m=0x55678258ed00, > > iphlen= > out>, inso=inso@entry=0x0) at ./tcp_input.c:1074 > > #2 0x5567818f073c in ip_input (m=) at > > ip_input.c:214 > > #3 0x5567818f86ef in sl_dispatch (ttyp=ttyp@entry=0x55678258b2 > > d0) at > > ./sl.c:127 > > #4 0x5567818f889e in sl_input (ttyp=0x55678258b2d0, > > if_bptr=0x7ffdd869e9e9 "\300\004\005\264\004\002\b\n\366KBX", > > if_n=) at ./sl.c:35 > > #5 0x5567818ef6b2 in if_input (ttyp=0x55678258b2d0) at > > ./if.c:191 > > #6 0x5567818f24a4 in main_loop () at ./main.c:1158 > > #7 0x5567818e37d7 in main (argc=1, argv=0x7ffdd869f848) at > > ./main.c:95 > > > > > > Problem now is usage of dereferences of seg_next which again is a > > pointer > > cast to a 32 bit value to cause disaster. > > > > Most likely all the usages of `#if SIZEOF_CHAR_P == 4` should be > > reviewed > > and > > fixed up to properly make slirp work on 64 bit systrms... > > > > -- System Information: > > Debian Release: bullseye/sid > > APT prefers unstable-debug > > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, > > 'testing'), (500, 'stable'), (1, 'experimental') > > Architecture: amd64 (x86_64) > > > > Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) > > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > > LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /usr/bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages slirp depends on: > > ii libc6 2.29-9 > > ii libcrypt1 1:4.4.10-10 > > > > slirp recommends no packages. > > > > slirp suggests no packages. > > > > -- no debconf information > > > >
Bug#949003: Doesn't work on 64 bit architectures
Package: slirp Version: 1:1.0.17-9 Severity: important The last upload fixes slirp crashes directly on startup on amd64; It now just crashes when starting to use it backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x5567818fa30b in tcp_reass (tp=tp@entry=0x556782590610, ti=0x82590610, ti@entry=0x0, m=, m@entry=0x0) at ./tcp_input.c:210 210 ./tcp_input.c: No such file or directory. (gdb) bt #0 0x5567818fa30b in tcp_reass (tp=tp@entry=0x556782590610, ti=0x82590610, ti@entry=0x0, m=, m@entry=0x0) at ./tcp_input.c:210 #1 0x5567818fb8c1 in tcp_input (m=0x55678258ed00, iphlen=, inso=inso@entry=0x0) at ./tcp_input.c:1074 #2 0x5567818f073c in ip_input (m=) at ip_input.c:214 #3 0x5567818f86ef in sl_dispatch (ttyp=ttyp@entry=0x55678258b2d0) at ./sl.c:127 #4 0x5567818f889e in sl_input (ttyp=0x55678258b2d0, if_bptr=0x7ffdd869e9e9 "\300\004\005\264\004\002\b\n\366KBX", if_n=) at ./sl.c:35 #5 0x5567818ef6b2 in if_input (ttyp=0x55678258b2d0) at ./if.c:191 #6 0x5567818f24a4 in main_loop () at ./main.c:1158 #7 0x5567818e37d7 in main (argc=1, argv=0x7ffdd869f848) at ./main.c:95 Problem now is usage of dereferences of seg_next which again is a pointer cast to a 32 bit value to cause disaster. Most likely all the usages of `#if SIZEOF_CHAR_P == 4` should be reviewed and fixed up to properly make slirp work on 64 bit systrms... -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages slirp depends on: ii libc6 2.29-9 ii libcrypt1 1:4.4.10-10 slirp recommends no packages. slirp suggests no packages. -- no debconf information
Bug#948268: Crashes after startup
On Mon, 2020-01-06 at 18:35 +0100, Bernhard Übelacker wrote: > Dear Maintainer, > just as a side note, a similar bug was submitted > against the basilisk2 package. > > https://bugs.debian.org/922323 > > Another user of slirp is qemu, which had some changes in > that area, which seems to have evolved into this library: > > https://gitlab.freedesktop.org/slirp/libslirp > > https://gitlab.freedesktop.org/slirp/libslirp/blob/master/src/ip.h#L214 Fwiw the reason for me hitting this was using it with user-mode-linux; Either a drop-in replacement for slirp based on libslirp (or uml being able to use libslirp directly) would probably be best for everyone as libslirp is actually maintained :) -- Sjoerd Simons
Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper
On Mon, 2020-01-06 at 16:58 +, Anton Ivanov wrote: > > On 06/01/2020 16:21, Ritesh Raj Sarraf wrote: > > Control: tag -1 +help > > > > On Mon, 2020-01-06 at 10:38 +0100, Sjoerd Simons wrote: > > > On my sid system: > > > ``` > > > $ strings /usr/bin/linux.uml | grep port-helper > > > /usr/lib//uml/port-helper > > > ``` > > > > > > So the path is still incorrect even with newer upstream kernels. > > > > I spent some time today looking at the new build but I haven't been > > able to ascertain why this isn't setting the correct path. > > It is used in a "user" side file - xterm.c > > None of these sees "CONFIG_" so it considers it undef-ed which > defaults > to 32 bit. Is there any reason why the port helper is in the weird `/usr/lib64` that seems more like a redhat-ism; On Debian if it's proper multi arch under `/usr/lib/x86_64-linux-gnu/`.. However uml-utilities can't be installed for multiple architectures on one system anyway (as it ships binaries). So there is little point in try to being multi-arch-like (or just awkward :p)... So to me the most practical and straight-forward solution would probably be to revert the broken kernel patch and change the uml- utilities package instead to always install in a single spot. > You need to use some other way to figure out what is the build or to > set > OS_LIB_PATH for this case. > > > ``` > > $ strings `which linux.uml` | grep port-helper > > /usr/lib/uml/port-helper > > ``` > > > > First, for context to the readers here, the port-helper binary is > > shipped with uml-utilities package. This package, depending on the > > architecture, installs the binary to a architecture specific > > location. > > > > https://sources.debian.org/src/uml-utilities/20070815.2-1/Makefile/#L10 > > > > Which on an amd64 machine is: /usr/lib64/uml/port-helper > > > > ``` > > $ dpkg -S /usr/lib64/uml/port-helper > > uml-utilities: /usr/lib64/uml/port-helper > > ``` > > > > The UML setup on my box always worked because long back, when I > > first > > encountered this problem, I had created a symlink of the path to > > /usr/lib/ too. And had completely forgotten about it. My apologies. > > > > > > But that said, the current problem is with the UML binary built by > > the > > kernel sources. > > Problem is that, as mentioned above and other reports too on this > > bug > > report thread, the path resolved at build time is always > > "/usr/lib/uml/". > > > > The build configuration and the code are all correct. > > > > ``` > > $ grep 64BIT .config > > CONFIG_64BIT=y > > CONFIG_64BIT_TIME=y > > CONFIG_PHYS_ADDR_T_64BIT=y > > CONFIG_ARCH_DMA_ADDR_T_64BIT=y > > ``` > > > > > > Snipped from: arch/um/include/shared/os.h > > > > ``` > > #ifdef CONFIG_64BIT > > #define OS_LIB_PATH "/usr/lib64/" > > #else > > #define OS_LIB_PATH "/usr/lib/" > > #endif > > ``` > > > > I also checked the generated include headers and they are correct > > for > > the amd64 .config file. > > > > ``` > > linux-source-5.4/include/generated$ grep 64BIT autoconf.h > > #define CONFIG_64BIT_TIME 1 > > #define CONFIG_PHYS_ADDR_T_64BIT 1 > > #define CONFIG_64BIT 1 > > #define CONFIG_ARCH_DMA_ADDR_T_64BIT 1 > > ``` > > > > I'll keep looking as time permits but if anyone else has ideas on > > what > > I may be doing wrong, please do mention. > > > > Thanks, > > Ritesh > > > > > > ___ > > linux-um mailing list > > linux...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-um > >
Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper
Package: user-mode-linux Version: 5.4-1um-2 Followup-For: Bug #928924 On my sid system: ``` $ strings /usr/bin/linux.uml | grep port-helper /usr/lib//uml/port-helper ``` So the path is still incorrect even with newer upstream kernels. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 5.4.0-1-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages user-mode-linux depends on: ii libc6 2.29-8 Versions of packages user-mode-linux recommends: ii uml-utilities 20070815.2-1+b1 Versions of packages user-mode-linux suggests: ii gnome-terminal [x-terminal-emulator] 3.34.2-1 pn rootstrap pn slirp pn user-mode-linux-doc pn vde2 ii xterm [x-terminal-emulator] 351-1 -- no debconf information
Bug#948268: Crashes after startup
Package: slirp Version: 1:1.0.17-8+b1 Severity: grave Hey; When starting slirp it crashes almost immediately; Backtrace from gdb: ``` (gdb) bt #0 ip_slowtimo () at ip_input.c:457 #1 0x55568a82 in main_loop () at ./main.c:980 #2 0x97c6 in main (argc=1, argv=0x7fffdf38) at ./main.c:95 ``` Looking at the code the ipq next/prev "pointer" fields in the ipq structure are 32 bits, which doesn't work that well on 64 bit systems. Setting to grave as most people these days run 64 bit systems on which slirp will be completely unustable. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages slirp depends on: ii libc6 2.29-8 slirp recommends no packages. slirp suggests no packages. -- no debconf information
Bug#877125: dtc: build errors with swig for python lib
Package: device-tree-compiler Version: 1.4.7-3 Followup-For: Bug #877125 This seems a bug of debians own making; debian/rulies copes the upstream Makefiles warnigns && Werror and then explicitly sets those as CFLAGS for the build. However this means that they'll get applied *both* to libfdt and pylibfdt, while when using the upstream makefile those flags only get applied to libfdt. Hence upstream never hits these issues as the warnings (treated as errors) won't be seen doing an upstream build. -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-5-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages device-tree-compiler depends on: ii libc6 2.28-10 device-tree-compiler recommends no packages. device-tree-compiler suggests no packages. -- no debconf information
Bug#930879: Please disable panfrost when moving out of experimental
Source: mesa Version: 19.1.0-1 Severity: normal Hey, Panfrost debuted in mesa 19.1.0, but it's stil really early days. Some of my collegues hacking on panfrost mentioned they'd feel quite uneasy if 19.1 with panfrost enabled made its way into testing and creating a bad image for panfrost. The hopes are that from 19.2 it will be ready for somewhat wider consumption. Sjoerd -- System Information: Debian Release: 10.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-5-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#923455: FTBS on 32 bit architectures
On Thu, 2019-02-28 at 13:45 +0100, Markus Koschany wrote: > Hi Sjoerd, > > Am 28.02.19 um 13:38 schrieb Sjoerd Simons: > > Source: netty > > Version: 4.1.33-1 > > Severity: important > > Tags: ftbfs > > Justification: fails to build from source > > > > Hey, > > > > It seems that netty fails to build on 32 bit architectures, we hit > > that in our > > rebuild on 32 bit as does the reproducible builder see e.g: > > > > https://tests.reproducible-builds.org/debian/rb-pkg/buster/armhf/netty.html > > Thanks for your reports _and_ the patches! Why don't you just join > the > team and upload them right now? That's the fastest way to get that > resolved IMO. I can drop some into salsa and do an MR if you prefer; I don't really want to join the java team though, I mostly hope to be able to forget about all these java pains asap :)
Bug#923455: FTBS on 32 bit architectures
Source: netty
Version: 4.1.33-1
Severity: important
Tags: ftbfs
Justification: fails to build from source
Hey,
It seems that netty fails to build on 32 bit architectures, we hit that in our
rebuild on 32 bit as does the reproducible builder see e.g:
https://tests.reproducible-builds.org/debian/rb-pkg/buster/armhf/netty.html
Tbh i was a bit surprised netty does some native building given it only ships
an architecture all package. In any case the issue seems to mostly be due to
building with -Werror which makes things fail on warnings. I've attached the
debdiff we used as workaround for this
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru netty-4.1.33/debian/changelog netty-4.1.33/debian/changelog
--- netty-4.1.33/debian/changelog 2019-01-22 14:06:25.0 +0100
+++ netty-4.1.33/debian/changelog 2019-02-28 11:08:13.0 +0100
@@ -1,3 +1,9 @@
+netty (1:4.1.33-1co1) apertis; urgency=medium
+
+ * Build native parts without Werror as that can cause build failures
+
+ -- Sjoerd Simons Thu, 28 Feb 2019 11:08:13
+0100
+
netty (1:4.1.33-1) unstable; urgency=medium
* Team upload.
diff -Nru netty-4.1.33/debian/patches/disable-Werror.patch
netty-4.1.33/debian/patches/disable-Werror.patch
--- netty-4.1.33/debian/patches/disable-Werror.patch1970-01-01
01:00:00.0 +0100
+++ netty-4.1.33/debian/patches/disable-Werror.patch2019-02-28
11:08:11.0 +0100
@@ -0,0 +1,58 @@
+--- a/transport-native-unix-common/pom.xml
b/transport-native-unix-common/pom.xml
+@@ -101,7 +101,7 @@
+
+
+
+-
++
+
+
+
+ .*IO_NETTY_SENDMSSG_NOT_FOUND.*
+- CFLAGS=-O3 -DIO_NETTY_SENDMMSG_NOT_FOUND
-Werror -fno-omit-frame-pointer -Wunused-variable -fvisibility=hidden
-I${unix.common.include.unpacked.dir}
++ CFLAGS=-O3 -DIO_NETTY_SENDMMSG_NOT_FOUND
-fno-omit-frame-pointer -Wunused-variable -fvisibility=hidden
-I${unix.common.include.unpacked.dir}
+ false
+
+
+@@ -281,7 +281,7 @@
+ ${jni.compiler.args.cflags}
+
+ ^((?!CFLAGS=).)*$
+- CFLAGS=-O3 -Werror -fno-omit-frame-pointer
-Wunused-variable -fvisibility=hidden
-I${unix.common.include.unpacked.dir}
++ CFLAGS=-O3 -fno-omit-frame-pointer
-Wunused-variable -fvisibility=hidden
-I${unix.common.include.unpacked.dir}
+ false
+
+
diff -Nru netty-4.1.33/debian/patches/series netty-4.1.33/debian/patches/series
--- netty-4.1.33/debian/patches/series 2019-01-22 11:10:37.0 +0100
+++ netty-4.1.33/debian/patches/series 2019-02-28 11:06:13.0 +0100
@@ -9,3 +9,4 @@
10-ignore-lzma.patch
11-ignore-protobuf-nano.patch
13-ignore-conscrypt.patch
+disable-Werror.patch
Bug#923391: Uses another classifier if build with jdk >= 9
Source: hikaricp Version: 2.7.1 Severity: important Tags: patch When rebuilding hikaricp with a jdk newer then 9 it adds a java9 classifier, which will unfortually cause it's build dependencies (e.g. libquartz2-java) to then fail. Attaching a debdiff which adds a patch to drop using the classifier so the result is consistend independent of the java version used for build -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru hikaricp-2.7.1/debian/changelog hikaricp-2.7.1/debian/changelog --- hikaricp-2.7.1/debian/changelog 2017-09-12 23:57:47.0 +0200 +++ hikaricp-2.7.1/debian/changelog 2019-02-27 14:19:28.0 +0100 @@ -1,3 +1,11 @@ +hikaricp (2.7.1-1co1) apertis; urgency=medium + + * d/p/drop-java9-classifier.patch: Added, drop the java9 classifier if build +with jdk >= 9. Prevents packages from hitting FTBS when building against +hikaricp build with jdk 9 which built fine with older hikaricp builds. + + -- Sjoerd Simons Wed, 27 Feb 2019 14:19:28 +0100 + hikaricp (2.7.1-1) unstable; urgency=medium * New upstream version 2.7.1 (Closes: #875368) diff -Nru hikaricp-2.7.1/debian/patches/drop-java9-classifier.patch hikaricp-2.7.1/debian/patches/drop-java9-classifier.patch --- hikaricp-2.7.1/debian/patches/drop-java9-classifier.patch 1970-01-01 01:00:00.0 +0100 +++ hikaricp-2.7.1/debian/patches/drop-java9-classifier.patch 2019-02-27 14:17:19.0 +0100 @@ -0,0 +1,29 @@ +--- a/pom.xml b/pom.xml +@@ -442,22 +442,26 @@ + + + ++ + ++ + + + coverage diff -Nru hikaricp-2.7.1/debian/patches/series hikaricp-2.7.1/debian/patches/series --- hikaricp-2.7.1/debian/patches/series2017-09-12 23:57:42.0 +0200 +++ hikaricp-2.7.1/debian/patches/series2019-02-27 14:12:11.0 +0100 @@ -1 +1,2 @@ skip-hibernate-prometheus-micrometer +drop-java9-classifier.patch
Bug#923364: FTBS: Can't build against bouncy-castle build with newer jdk
Package: libitext-java Version: 2.1.7-12 Severity: serious Tags: patch Hey, When rebuilding bouncy-castle the jar doesn't seem to have the same classpath built-in as older builds did; specifically comparing a rebuild with an old debian build the MANIFEST.MF has the following diff (among other bits): -Class-Path: bcprov.jar bcpkix.jar javax.mail.jar +Class-Path: /usr/share/java/javax.mail.jar This makes the build fail as it cannot find symbols provides by e.g. bcpkix.jar. The attach patch fixes that. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libitext-java depends on: ii libbcmail-java 1.60-1 ii libbcpkix-java 1.60-1 ii libbcprov-java 1.60-1 libitext-java recommends no packages. libitext-java suggests no packages. -- no debconf information diff -Nru libitext-java-2.1.7/debian/ant.properties libitext-java-2.1.7/debian/ant.properties --- libitext-java-2.1.7/debian/ant.properties 2018-03-25 18:42:52.0 +0200 +++ libitext-java-2.1.7/debian/ant.properties 2019-02-26 22:54:56.0 +0100 @@ -5,8 +5,10 @@ lib.bcmail=bcmail.jar lib.bcprov=bcprov.jar lib.bctsp=bctsp.jar +lib.bcpkix=bcpkix.jar lib.dom4j=dom4j.jar lib.pdf-renderer=pdfrenderer.jar +lib.javax.mail=javax.mail.jar itext.jar=../lib/iText.jar itext.rtf.jar=../lib/iText-rtf.jar diff -Nru libitext-java-2.1.7/debian/patches/extend-classpath.patch. libitext-java-2.1.7/debian/patches/extend-classpath.patch. --- libitext-java-2.1.7/debian/patches/extend-classpath.patch. 1970-01-01 01:00:00.0 +0100 +++ libitext-java-2.1.7/debian/patches/extend-classpath.patch. 2019-02-26 22:54:20.0 +0100 @@ -0,0 +1,11 @@ +--- a/ant/compile.xml b/ant/compile.xml +@@ -16,6 +16,8 @@ + + + ++ ++ + + + diff -Nru libitext-java-2.1.7/debian/patches/series libitext-java-2.1.7/debian/patches/series --- libitext-java-2.1.7/debian/patches/series 2018-03-25 18:42:52.0 +0200 +++ libitext-java-2.1.7/debian/patches/series 2019-02-26 22:53:50.0 +0100 @@ -3,3 +3,4 @@ 03_bouncycastle-1.51.patch 04_tibco-changes.patch encoding.patch +extend-classpath.patch.
Bug#923284: Seemingly miscompiles with jdk-11
On Tue, 2019-02-26 at 12:40 +0100, Emmanuel Bourg wrote: > Le 26/02/2019 à 12:22, Sjoerd Simons a écrit : > > > ASM7 mode seems to have been introduced in the gradle v5.x series. > > Not > > sure if it makes sense for buster to upgrade to that (I really > > don't > > know much about java, so no idea about the impact)? > > We can't upgrade to Gradle 5 unfortunately, not until Kotlin is > packaged > (#892842). This will be a key issue in the next development cycle. > > > > That said making all gradle dependencies target pre-Java > > 11 probably > > doens't scale either? > > If it's just the Gradle dependencies it's doable, and the severity of > the bug can be downgraded because the issue only appears if the > dependencies are rebuilt. If the issue also appears when project > dependencies use Java 11 this is a more important issue. Right it seems to be the following list: bsh libjaxp1.3-java xml-commons-external So not as bad as i worried; But i'm not sure more stuff may come out of the woodwork when building things that uses gradle. -- Sjoerd Simons
Bug#923284: Seemingly miscompiles with jdk-11
On Tue, 2019-02-26 at 11:35 +0100, Emmanuel Bourg wrote: > Le 26/02/2019 à 10:20, Sjoerd Simons a écrit : > > > I've atteched the output of running docker build on the DockerFile > > i > > attached to reproduce the issue; The relevant part in the gradle > > build > > seems to be: > > Thank you! The "Malformed jar" message is just a warning. The actual > issue is: > > > Caused by: java.lang.UnsupportedOperationException: This feature > > requires ASM7 > > at > > org.objectweb.asm.ClassVisitor.visitNestHost(ClassVisitor.java:150) > > at org.objectweb.asm.ClassReader.accept(ClassReader.java:541) > > at org.objectweb.asm.ClassReader.accept(ClassReader.java:391) > > at > > org.gradle.api.internal.tasks.compile.incremental.asm.ClassDependen > > ciesVisitor.analyze(ClassDependenciesVisitor.java:75) > > Most likely triggered because the recompiled bsh uses Java 11 > bytecode. > This can be fixed either by targeting a pre Java 11 release in the > bsh > build, or by patching Gradle to use Opcodes.ASM7. ASM7 mode seems to have been introduced in the gradle v5.x series. Not sure if it makes sense for buster to upgrade to that (I really don't know much about java, so no idea about the impact)? That said making all gradle dependencies target pre-Java 11 probably doens't scale either? -- Sjoerd Simons
Bug#923284: Seemingly miscompiles with jdk-11
On Mon, 2019-02-25 at 23:59 +0100, Emmanuel Bourg wrote: > Thank you for the report Sjoerd. What error did you get when > compiling > gradle with the rebuilt bsh? > > Emmanuel Bourg Btw; I tested with forcing bsh to build with openjdk-8 instead and then the issue doesn't occur while building gradle; Hence assuming it's a bsh issue not a gradle one.
Bug#923284: Seemingly miscompiles with jdk-11
Source: bsh Version: 2.0b4-19 Severity: serious When building bsh with openjdk-11 it seems that afterwards building packages using it fails e.g. after rebuilding bsh gradle fails to build. Attached is a dockerfile which nicely shows the issue -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled FROM debian:buster RUN apt-get update && \ apt-get install -y --no-install-recommends vim-tiny RUN cat /etc/apt/sources.list | sed 's,^deb,deb-src,g' > /etc/apt/sources.list.d/s.list RUN apt-get update && \ apt-get install -y build-essential devscripts RUN apt-get update && \ apt-get build-dep -y bsh gradle # builds fine RUN apt-get source gradle && \ cd gradle* && \ debuild -uc -us # Rebuild bsh RUN apt-get source bsh && \ cd bsh* && \ debuild -uc -us && \ cd .. && \ dpkg -i libbsh-java*.deb # fail :/ RUN apt-get source gradle && \ cd gradle* && \ debuild -uc -us
Bug#923228: FTBS: new symbols
Package: gringo
Version: 5.3.0
Severity: serious
Hey,
Gringo seems to FTBS in buster due to:
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see
diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols
file: see diff output below
dpkg-gensymbols: warning: debian/gringo/DEBIAN/symbols doesn't match completely
debian/symbols
--- debian/symbols (gringo_5.3.0-6_amd64)
+++ dpkg-gensymbolsj8jm57 2019-02-25 08:56:50.725562893 +
@@ -35,8 +35,8 @@
(optional=templinst|arch=amd64 arm64 hppa kfreebsd-amd64 sh4
x32|subst)_ZNSt10_HashtableI{uint64_t}{uint64_t}SaI{uint64_t}ENSt8__detail9_IdentityESt8equal_toI{uint64_t}ESt4hashI{uint64_t}ENS1_18_Mod_range_hashingENS1_20_Default_ranged_hashENS1_20_Prime_rehash_policyENS1_17_Hashtable_traitsILb0ELb1ELb1D2Ev@Base
1
#MISSING: 1#
(optional=templinst|arch=mipsel)_ZNSt11__copy_moveILb1ELb0ESt26random_access_iterator_tagE8__copy_mIPN6Gringo11IntervalSetINS3_6SymbolEE8IntervalES8_EET0_T_SA_S9_@Base
1
#MISSING: 5.3.0# (optional=templinst|arch=!alpha !amd64 !arm64 !armel !armhf
!hppa !hurd-i386 !i386 !kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc
!powerpcspe !ppc64 !ppc64el !riscv64 !s390x
!sh4)_ZNSt11unique_lockISt5mutexE6unlockEv@Base 1
-#MISSING: 5.3.0#
(optional=templinst|arch=kfreebsd-amd64)_ZNSt12__shared_ptrIjLN9__gnu_cxx12_Lock_policyE2EEC1ERKS2_@Base
1
-#MISSING: 5.3.0#
(optional=templinst|arch=kfreebsd-amd64)_ZNSt12__shared_ptrIjLN9__gnu_cxx12_Lock_policyE2EEC2ERKS2_@Base
1
+
(optional=templinst)_ZNSt12__shared_ptrIjLN9__gnu_cxx12_Lock_policyE2EEC1ERKS2_@Base
1
+
(optional=templinst)_ZNSt12__shared_ptrIjLN9__gnu_cxx12_Lock_policyE2EEC2ERKS2_@Base
1
(optional=templinst)_ZNSt13_Bvector_baseISaIbEE13_M_deallocateEv@Base 1
(optional=templinst)_ZNSt14_Function_base13_Base_managerISt5_BindIFMN5Clasp3Cli12ClaspAppBaseEFbRNS2_11ClaspFacadeEEPN6Gringo9ClingoAppESt12_PlaceholderILi1E10_M_managerERSt9_Any_dataRKSH_St18_Manager_operation@Base
1
(optional=templinst)_ZNSt14_Function_base13_Base_managerISt5_BindIFMN5Clasp3Cli12ClaspAppBaseEFbRNS2_14ProgramBuilderEEPN6Gringo9ClingoAppESt12_PlaceholderILi1E10_M_managerERSt9_Any_dataRKSH_St18_Manager_operation@Base
1
@@ -45,11 +45,11 @@
(optional=templinst)_ZNSt15__exception_ptr12__dest_thunkISt13runtime_errorEEvPv@Base
1
(optional=templinst|arch=armel
riscv64)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE10_M_releaseEv@Base
1
(optional=templinst|arch=!armel
!riscv64)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_releaseEv@Base
1
- (optional=templinst|arch=!alpha !armhf !hurd-i386 !i386 !ia64 !kfreebsd-i386
!m68k !mips !mipsel !powerpc !powerpcspe !ppc64
!s390x)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyISt13move_iteratorIPN6Gringo10CSPRelTermEES5_EET0_T_S8_S7_@Base
1
- (optional=templinst|arch=!alpha !amd64 !arm64 !armhf !hppa !hurd-i386 !i386
!kfreebsd-amd64 !kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc
!powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sh4
!x32)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyISt13move_iteratorIPN6Gringo13TheoryAtomDefEES5_EET0_T_S8_S7_@Base
5.3.0
+#MISSING: 5.3.0-6# (optional=templinst|arch=!alpha !armhf !hurd-i386 !i386
!ia64 !kfreebsd-i386 !m68k !mips !mipsel !powerpc !powerpcspe !ppc64
!s390x)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyISt13move_iteratorIPN6Gringo10CSPRelTermEES5_EET0_T_S8_S7_@Base
1
+
(optional=templinst)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyISt13move_iteratorIPN6Gringo13TheoryAtomDefEES5_EET0_T_S8_S7_@Base
5.3.0
(optional=templinst)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyISt13move_iteratorIPN6Gringo5Input10CheckLevelEES6_EET0_T_S9_S8_@Base
1
(optional=templinst)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyISt13move_iteratorIPN6Gringo5Input7CSPElemEES6_EET0_T_S9_S8_@Base
1
-#MISSING: 5.3.0# (optional=templinst|arch=!alpha !amd64 !arm64 !armel !armhf
!hppa !hurd-i386 !i386 !kfreebsd-i386 !m68k !mips !mips64el !mipsel !powerpc
!powerpcspe !ppc64 !ppc64el !riscv64 !s390x
!sh4)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyISt13move_iteratorIPSt4pairISt10unique_ptrIN6Gringo5Input7LiteralESt14default_deleteIS7_EESt6vectorISA_SaISA_SF_EET0_T_SI_SH_@Base
1
+
(optional=templinst)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyISt13move_iteratorIPSt4pairISt10unique_ptrIN6Gringo5Input7LiteralESt14default_deleteIS7_EESt6vectorISA_SaISA_SF_EET0_T_SI_SH_@Base
1
(optional=templinst)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyISt13move_iteratorIPSt4pairISt6vectorIS3_ISt10unique_ptrIN6Gringo5Input7LiteralESt14default_deleteIS8_EES4_ISB_SaISB_EEESaISE_EESD_EESI_EET0_T_SL_SK_@Base
1
(optional=templinst)_ZNSt20__uninitialized_copyILb0EE13__uninit_copyISt13move_iteratorIPSt4pairISt6vectorIS4_ISt10unique_ptrIN6Gringo5Input7LiteralESt14default_deleteIS8_EESaISB_EESaISD_EESD_EESH_EET0_T_SK_SJ_@Base
1
Bug#923185: FTBS: javadoc: error - The code being documented uses packages in the unnamed module
Source: isorelax Version: 2004-11 Severity: serious Hey, Rebuilding isorelax fails to build with: javadoc: error - The code being documented uses packages in the unnamed module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are in named modules. The reproducible build logs show a similar error: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/isorelax_2004-11.rbuild.log.gz -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#923182: FTBS: javadoc: error - The code being documented uses packages in the unnamed module, but the packages defined in file:///usr/share/doc/default-jdk/api/ are in named modules.
Source: icu4j Version: 62.1-1 Severity: serious Hey, Rebuilding icu4j sees to FTBS with: javadoc: error - The code being documented uses packages in the unnamed module, but the packages defined in file:///usr/share/doc/default-jdk/api/ are in named modules. The reproducible builds log is showing the same eror: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/icu4j_62.1-1.rbuild.log.gz -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#922831: Uninstallable build dependencies
Source: node-es6-promise Version: 4.2.5-1 Severity: serious On a buster docker image: ``` # apt-get build-dep node-es6-promise Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: builddeps:node-es6-promise : Depends: webpack but it is not going to be installed E: Unable to correct problems, you have held broken packages. ``` Reason is that there is a build-dep on both webpack and uglifyjs which indirectly end up conflicting. Seems that dropping the uglifyjs b-d still at least makes the package build -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#922677: Please consider using rng-tools >= 6
Package: rng-tools5 Severity: wishlist Hey, Filing it against this pacakge as the rng-tools seems to be in some odd transitional limbo. Looking into the entropy debacle (especially on my devboards) and how other distributions do things I noticed that e.g. fedora ships rng-tools 6.x from https://github.com/nhorman/rng-tools. One of the features that provides is jitterentropy support to generate random numbers without needing a hw rng. This is quite useful as it allows one to just install rng-tools and take advantage of either a hwrng or if not needed use software instead. Avoiding to have to install both rng-tools and either jitterentropy-rngd or haveged on generic images. -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.19.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rng-tools5 depends on: ii init-system-helpers 1.56+nmu1 ii libc62.28-7 ii libgcrypt20 1.8.4-5 rng-tools5 recommends no packages. rng-tools5 suggests no packages.
Bug#907465: [Pkg-telepathy-maintainers] Bug#907465: telepathy-idle: Please update Uploaders, Vcs-*, etc. or remove
On Tue, 2018-08-28 at 10:51 +0100, Simon McVittie wrote: > Source: telepathy-idle > Version: 0.2.0-2 > Severity: normal > > telepathy-idle still lists me and Jonny Lamb in its Uploaders; we > removed > ourselves from Uploaders in the VCS in 2014 and 2016 respectively. > The > package's metadata also still refers to Alioth, and its Standards- > Version > says it has not been checked for compliance with post-2013 Policy. > Please > update this package. > > Alternatively, since Telepathy appears to be essentially dead > upstream, > perhaps this package should be removed? (This would have to be > coordinated > with the maintainer of polari.) And this is how i do IRC; so nope please don't removed.
Bug#907463: [Pkg-telepathy-maintainers] Bug#907463: telepathy-rakia: Please update Uploaders, Vcs-*, etc. or remove
On Tue, 2018-08-28 at 10:48 +0100, Simon McVittie wrote: > Source: telepathy-rakia > Version: 0.8.0-3 > Severity: normal > > telepathy-spec still lists me and Jonny Lamb in its Uploaders; we > removed > ourselves from Uploaders in the VCS in 2014 and 2016 respectively. > The > package's metadata also still refers to Alioth, and its Standards- > Version > says it has not been checked for compliance with post-2013 Policy. > Please > update this package. > > Alternatively, since Telepathy appears to be essentially dead > upstream, > perhaps this package should be removed? Rakia is how i make daily SIP calls; so no really shouldn't be removed ;)
Bug#905831: Fails to build on armhf
Package: ne10
Version: 1.2.1-3
Severity: serious
Tags: patch
Justification: fails to build from source
As per
https://buildd.debian.org/status/fetch.php?pkg=ne10=armhf=1.2.1-3=1478897528=0
the build of ne10 fails on armhf. This is because it detects the build
environment as targetting aarch64. From the log:
-- Target architecture : aarch64
Attached is the debdiff from a derivative we hvae which fixes the issue.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf
Kernel: Linux 4.18.0-rc4-amd64 (SMP w/32 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ne10-1.2.1/debian/changelog ne10-1.2.1/debian/changelog
--- ne10-1.2.1/debian/changelog 2016-10-18 19:01:22.0 +0200
+++ ne10-1.2.1/debian/changelog 2018-08-10 12:26:58.0 +0200
@@ -1,3 +1,9 @@
+ne10 (1.2.1-3co1) apertis; urgency=medium
+
+ * Fix build on armhf
+
+ -- Sjoerd Simons Fri, 10 Aug 2018 12:26:58 +0200
+
ne10 (1.2.1-3) unstable; urgency=medium
* Update copyright file for modules/*
diff -Nru ne10-1.2.1/debian/rules ne10-1.2.1/debian/rules
--- ne10-1.2.1/debian/rules 2016-10-12 19:35:53.0 +0200
+++ ne10-1.2.1/debian/rules 2018-08-10 12:26:57.0 +0200
@@ -13,12 +13,19 @@
# package maintainers to append LDFLAGS
#export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
+ifeq ($(DEB_TARGET_GNU_CPU),arm)
+ NE10_LINUX_TARGET_ARCH = armv7
+else
+ NE10_LINUX_TARGET_ARCH = ${DEB_TARGET_GNU_CPU}
+endif
+
%:
dh $@
override_dh_auto_configure:
+
dh_auto_configure -- \
- -DNE10_LINUX_TARGET_ARCH=$(DEB_TARGET_GNU_CPU) \
+ -DNE10_LINUX_TARGET_ARCH=$(NE10_LINUX_TARGET_ARCH) \
-DGNULINUX_PLATFORM=ON \
-DNE10_BUILD_SHARED=ON
Bug#895012: Fails to install
Package: jenkins-job-builder Version: 2.0.3-1 Severity: grave Hey, installing jenkins-job-builder gives the following error: Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: python3-jenkins-job-builder The following NEW packages will be installed: jenkins-job-builder python3-jenkins-job-builder 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/193 kB of archives. After this operation, 1,135 kB of additional disk space will be used. Do you want to continue? [Y/n] Selecting previously unselected package python3-jenkins-job-builder. (Reading database ... 152457 files and directories currently installed.) Preparing to unpack .../python3-jenkins-job-builder_2.0.3-1_all.deb ... Unpacking python3-jenkins-job-builder (2.0.3-1) ... Selecting previously unselected package jenkins-job-builder. Preparing to unpack .../jenkins-job-builder_2.0.3-1_all.deb ... Unpacking jenkins-job-builder (2.0.3-1) ... Setting up python3-jenkins-job-builder (2.0.3-1) ... update-alternatives: error: alternative path /usr/bin/python3-jenkins-jobs doesn't exist dpkg: error processing package python3-jenkins-job-builder (--configure): installed python3-jenkins-job-builder package post-installation script subprocess returned error exit status 2 dpkg: dependency problems prevent configuration of jenkins-job-builder: jenkins-job-builder depends on python3-jenkins-job-builder (= 2.0.3-1); however: Package python3-jenkins-job-builder is not configured yet. dpkg: error processing package jenkins-job-builder (--configure): dependency problems - leaving unconfigured Errors were encountered while processing: python3-jenkins-job-builder E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 4.15.0-1-amd64 (SMP w/32 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages jenkins-job-builder depends on: ih python3-jenkins-job-builder 2.0.3-1 jenkins-job-builder recommends no packages. jenkins-job-builder suggests no packages. -- no debconf information
Bug#887892: qemu-arm-static: vmdebootstrap takes four times longer
Package: qemu-user-static Version: 1:2.11+dfsg-1 Followup-For: Bug #887892 Hey, I'm seeing the same when using debos for the same reasons as vmbootstrap will be slow. Both tools wrap debootstrap and for foreign architectures will run the debootstrap second stage in a chroot user qemu-user-static to do the CPU emulation. So for some reason qemu-user-static got a lot slower running the deboostrap second stabe.
Bug#890235: Please anble DRM_DP_AUX_CHARDEV
Source: linux Severity: normal Hey, The DRM_DP_AUX_CHARDEV exposes the DP aux channel to userspace, this is used by e.g. fwupmgr to allow it to upgrade firmware of Dell Type-C Docking stations. Please enable this option :) -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-rc8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#864726: Please CONFIG_PCI_HOST_GENERIC on armhf
Source: linux Version: 4.9.30-2 Severity: normal Tags: patch Hey, The qemu arm virtual machine (virt/virt-2.6/virt-2.7/virt-2.8) is a virtual ARM box with PCI devices, it's host bridge is a generic host controller. Enabling the requested option allows Debian to run on those machine (In our use-case a 32 bit ARM vm on a 64 bit arm host) -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) >From a75ae8b838d9982ae75459000741f2e08f405a42 Mon Sep 17 00:00:00 2001 From: Sjoerd Simons <sjoerd.sim...@collabora.co.uk> Date: Fri, 9 Jun 2017 11:58:07 +0200 Subject: [PATCH] [armhf] Enable CONFIG_PCI_HOST_GENERIC to support PCI in armhf vm's --- debian/config/armhf/config | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/config/armhf/config b/debian/config/armhf/config index 2fd332c97..b1997fdf7 100644 --- a/debian/config/armhf/config +++ b/debian/config/armhf/config @@ -842,6 +842,7 @@ CONFIG_PCI_DRA7XX=y CONFIG_PCI_MVEBU=y CONFIG_PCI_IMX6=y CONFIG_PCI_TEGRA=y +CONFIG_PCI_HOST_GENERIC=y ## ## file: drivers/phy/Kconfig -- 2.11.0
Bug#864718: fsdev emulation security_model=none not handling mode 000
Package: qemu-system
Version: 1:2.8+dfsg-6
Severity: normal
Hey,
For $reasons i'm exposing /boot over a filesystem share with the host system,
fsdev is setup as followed on the qemu command line:
-fsdev
local,security_model=none,id=fsdev-fs0,path=/srv/mp30-ar1-cbg-0-armhf-0-boot
Unfortunately trying to install a kernel shows dpkg getting unhappy:
[pid 26686] open("/boot/System.map-4.9.0-3-armmp-lpae.dpkg-new",
O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 000) = -1 EACCES (Permission denied)
I suspect mode 000 is confusing everything here. A similarish issue can be seen
when changing a file to mode 000 by hand:
# touch badger
# ls -l badger
-rw-r--r-- 1 64055 64055 0 Jun 13 13:58 badger
# chmod 600 badger
# chmod 700 badger
# chmod 000 badger
# chmod 700 badger
chmod: changing permissions of 'badger': Permission denied
Iotw as soon as the mode is 000 any later permission changes fail.
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64
Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages qemu-system depends on:
ii qemu-system-arm1:2.8+dfsg-6
ii qemu-system-mips 1:2.8+dfsg-6
ii qemu-system-misc 1:2.8+dfsg-6
ii qemu-system-ppc1:2.8+dfsg-6
ii qemu-system-sparc 1:2.8+dfsg-6
ii qemu-system-x861:2.8+dfsg-6
qemu-system recommends no packages.
qemu-system suggests no packages.
-- no debconf information
Bug#863254: Please pacakge jenkins-job-builder 2
Package: jenkins-job-builder Version: 1.6.1-1 Severity: wishlist Hey, Jenkins-job-builder was release a some time ago (specifically 2.0.0.0b2), among other things this features support for pipeline project types which are a very useful new feature in jenkins 2. Please consider updating the packaging (for experimental till stretch is out?) to this version. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages jenkins-job-builder depends on: ii python-jenkins-job-builder 1.6.1-1 jenkins-job-builder recommends no packages. jenkins-job-builder suggests no packages. -- no debconf information
Bug#861164: Please remove the upstart integration
Package: ifupdown Version: 0.8.19 Severity: normal Hey, Upstart is no longer in stretch/unstable, so the integration in it for ifupdown is rather pointless. Probably good to remove. Fwiw, I ran into this due to one of my ARM boards not booting as the upstart integration happened to trigger #861158 during early boot, which in turn triggered #861157 meaning the board didn't fully coldplug... 861158 should be fixed in the next upload of systemd for stretch making the potential impact be a lot smaller, but it's still a good amount of shell code that's run pointlessly on early boot. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.10.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages ifupdown depends on: ii adduser 3.115 ii init-system-helpers 1.47 ii iproute2 4.9.0-1 ii libc62.24-10 ii lsb-base 9.20161125 Versions of packages ifupdown recommends: ii isc-dhcp-client [dhcp-client] 4.3.5-3 Versions of packages ifupdown suggests: ii ppp 2.4.7-1+4 pn rdnssd
Bug#861158: init system helper trigger daemon-reload too often
Package: systemd Version: 233-5 Severity: normal Hey, The systemd helper for init-tools is trying to be nice and helpful by triggering a daemon reload iff systemd cannot find the service which includes it (e.g. due to the generator not having run yet when the lsb service is triggered) Unfortunately some non-init scripts also source init-functions, which ofcourse won't have a systemd service triggering a spurious daemon-reload. What's worse is that this can happen on boot where it both hurts performance and can actually trigger the boot to fail due to #861157 I'll push a proposed patch into pkg-systemd git in a little bit -- Package-specific info: -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.10.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-3 ii libaudit1 1:2.6.7-2 ii libblkid1 2.29.2-1 ii libc6 2.24-10 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-3 ii libgcrypt20 1.7.6-1 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-6 ii libkmod224-1 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.2+b1 ii libmount1 2.29.2-1 ii libpam0g1.1.8-3.5 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b1 ii libsystemd0 233-5 ii mount 2.29.2-1 ii util-linux 2.29.2-1 Versions of packages systemd recommends: ii dbus1.10.18-1 ii libpam-systemd 233-5 Versions of packages systemd suggests: ii policykit-10.105-17 ii systemd-container 233-5 pn systemd-ui Versions of packages systemd is related to: ii dracut 044+241-3 pn initramfs-tools ii udev 233-4 -- Configuration Files: /etc/systemd/logind.conf changed [not included] /etc/systemd/resolved.conf changed [not included] -- no debconf information
Bug#861157: Doesn't run all commands in Exec* if daemon is reloaded
Package: systemd Version: 233-5 Severity: important Tags: upstream Hey, There is a known issue in systemd that after a daemon reload it lost track of where in an Exec* sequence it was, which causes the remaining commands not to run. I ran into a pretty nasty corner-case yesterday causing one of my boards to reliably fail to boot thanks to interactions with ifupdown and the lsb init helpers (I'll open another bug this in a bit). But it's generally a bit problematic (but usually uncommon) that a (unrelated) daemon-reload can cause an unchanged service to not start as expected A fix for the issue got fixed upstream in commit e266c068 (PR: https://github.com/systemd/systemd/pull/5354). Upstream issue report: https://github.com/systemd/systemd/issues/518 -- Package-specific info: -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, arm64 Kernel: Linux 4.10.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-3 ii libaudit1 1:2.6.7-2 ii libblkid1 2.29.2-1 ii libc6 2.24-10 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-3 ii libgcrypt20 1.7.6-1 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-6 ii libkmod224-1 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.2+b1 ii libmount1 2.29.2-1 ii libpam0g1.1.8-3.5 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b1 ii libsystemd0 233-5 ii mount 2.29.2-1 ii util-linux 2.29.2-1 Versions of packages systemd recommends: ii dbus1.10.18-1 ii libpam-systemd 233-5 Versions of packages systemd suggests: ii policykit-10.105-17 ii systemd-container 233-5 pn systemd-ui Versions of packages systemd is related to: ii dracut 044+241-3 pn initramfs-tools ii udev 233-4 -- Configuration Files: /etc/systemd/logind.conf changed [not included] /etc/systemd/resolved.conf changed [not included] -- no debconf information
Bug#858302: Should ship api source subdirectory
Package: golang-github-docker-docker-dev Version: 1.13.0~ds1-1 Severity: important Hey, The opts subdir in docker now refers to packages in the api subdirectory, so that should ship as well to get things to build -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#858269: Fails to build, test try things not allowed as non-root
Package: docker.io Version: 1.13.0~ds1-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Trying to build docker.io in a pbuilder seems to fails with quite a few occurances of EPERM in the testsuite. I wonder how this could have build under fakeroot or similar (anything not running as root really). Relevant log: ---> Making bundle: test-unit (in bundles/1.13.0/test-unit) Mon Mar 20 15:45:32 CET 2017 ok github.com/docker/docker/api0.251s coverage: 87.3% of statements ? github.com/docker/docker/api/errors [no test files] ok github.com/docker/docker/api/server 0.015s coverage: 6.5% of statements ok github.com/docker/docker/api/server/httputils 0.013s coverage: 18.5% of statements ok github.com/docker/docker/api/server/middleware 0.012s coverage: 19.0% of statements ? github.com/docker/docker/api/server/router [no test files] ? github.com/docker/docker/api/server/router/build[no test files] ? github.com/docker/docker/api/server/router/checkpoint [no test files] ? github.com/docker/docker/api/server/router/container[no test files] ? github.com/docker/docker/api/server/router/image[no test files] ? github.com/docker/docker/api/server/router/network [no test files] ? github.com/docker/docker/api/server/router/plugin [no test files] ? github.com/docker/docker/api/server/router/swarm[no test files] ? github.com/docker/docker/api/server/router/system [no test files] ? github.com/docker/docker/api/server/router/volume [no test files] ? github.com/docker/docker/api/types [no test files] ? github.com/docker/docker/api/types/backend [no test files] ? github.com/docker/docker/api/types/blkiodev [no test files] ? github.com/docker/docker/api/types/container[no test files] ? github.com/docker/docker/api/types/events [no test files] ok github.com/docker/docker/api/types/filters 0.005s coverage: 96.7% of statements ? github.com/docker/docker/api/types/mount[no test files] ? github.com/docker/docker/api/types/network [no test files] ok github.com/docker/docker/api/types/reference0.009s coverage: 100.0% of statements ? github.com/docker/docker/api/types/registry [no test files] ok github.com/docker/docker/api/types/strslice 0.012s coverage: 90.0% of statements ? github.com/docker/docker/api/types/swarm[no test files] ok github.com/docker/docker/api/types/time 0.006s coverage: 100.0% of statements ok github.com/docker/docker/api/types/versions 0.012s coverage: 75.0% of statements ? github.com/docker/docker/api/types/versions/v1p19 [no test files] ? github.com/docker/docker/api/types/versions/v1p20 [no test files] ? github.com/docker/docker/api/types/volume [no test files] --- FAIL: TestMakeRemoteContext (0.01s) remote_test.go:185: Error when executing DetectContextFromRemoteURL: Error processing tar file(exit status 1): Error creating mount namespace before pivot: operation not permitted --- FAIL: TestMakeTarSumContext (0.07s) tarsum_test.go:212: Error when executing MakeTarSumContext: Error processing tar file(exit status 1): Error creating mount namespace before pivot: operation not permitted FAIL coverage: 64.2% of statements FAILgithub.com/docker/docker/builder0.093s --- FAIL: TestDispatch (0.03s) evaluator_test.go:164: Error when creating tar context: Error processing tar file(exit status 1): Error creating mount namespace before pivot: operation not permitted --- FAIL: TestEmptyDockerfile (0.01s) internals_test.go:71: Error when creating tar context: Error processing tar file(exit status 1): Error creating mount namespace before pivot: operation not permitted --- FAIL: TestSymlinkDockerfile (0.01s) internals_test.go:71: Error when creating tar context: Error processing tar file(exit status 1): Error creating mount namespace before pivot: operation not permitted --- FAIL: TestDockerfileOutsideTheBuildContext (0.01s) internals_test.go:71: Error when creating tar context: Error processing tar file(exit status 1): Error creating mount namespace before pivot: operation not permitted --- FAIL: TestNonExistingDockerfile (0.01s) internals_test.go:71: Error when creating tar context: Error processing tar file(exit status 1): Error creating mount namespace before pivot: operation not permitted FAIL coverage: 36.9% of statements FAILgithub.com/docker/docker/builder/dockerfile 0.094s ? github.com/docker/docker/builder/dockerfile/command [no test files] ok github.com/docker/docker/builder/dockerfile/parser 0.027s coverage: 82.4% of statements ? github.com/docker/docker/builder/dockerfile/parser/dumper [no test
Bug#858250: Fails to build, build-depends not strict enough
Package: runc Version: 1.0.0~rc2+git20161109.131.5137186-2 Severity: serious Justification: fails to build from source (but built successfully in the past) Hey, runc fails to build on stretch after updating the bits the build-depends require, it looks they're not strict enough for: * golang-github-opencontainers-specs * golang-github-urfave-cli After updating these two to the stretch versions things seem happy. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages runc depends on: ii libapparmor1 2.11.0-2 ii libc6 2.24-9 ii libseccomp2 2.3.1-2.1 runc recommends no packages. runc suggests no packages. -- no debconf information
Bug#858241: Dependency on golang-github-coreos-pkg not strict enough
Source: etcd Version: 3.1.2+dfsg Severity: serious Justification: fails to build from source Looks like etcd needs at least golang-github-coreos-pkg >= 3, when trying to build against an older versions (as e.g. present in stretch) the build fails iwth: src/github.com/coreos/etcd/tools/functional-tester/etcd-tester/stresser.go:26: cannot use plog (type *capnslog.PackageLogger) as type grpclog.Logger in argument to grpclog.SetLogger: *capnslog.PackageLogger does not implement grpclog.Logger (missing Fatalln method) -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#858240: build-dependency on golang-github-xiang90-probing-0.0 not strict enough
Source: etcd Version: 3.1.2+dfsg-1 Severity: normal When trying to build against the stretch version of golang-github-xiang90-probing-0.0 the following error is seen: src/github.com/coreos/etcd/rafthttp/probing_status.go:54: s.Err undefined (type probing.Status has no field or method Err) Please update the b-d to at least the required version of golang-github-xiang90-probing-0.0 -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#857842: Fails to build -- test errors
Source: etcd Version: 3.1.2+dfsg Severity: serious Justification: fails to build from source Hey, When trying to build etcd i get: okgithub.com/coreos/etcd/wal 19.322s ? github.com/coreos/etcd/wal/walpb [no test files] dh_auto_test: go test -v -p 6 -run=Test github.com/coreos/etcd github.com/coreos/etcd/alarm github.com/coreos/etcd/auth github.com/coreos/etcd/auth/authpb github.com/coreos/etcd/client github.com/coreos/etcd/client/integration github.com/coreos/etcd/clientv3 github.com/coreos/etcd/clientv3/concurrency github.com/coreos/etcd/clientv3/integration github.com/coreos/etcd/clientv3/mirror github.com/coreos/etcd/clientv3/naming github.com/coreos/etcd/compactor github.com/coreos/etcd/contrib/raftexample github.com/coreos/etcd/contrib/recipes github.com/coreos/etcd/contrib/systemd/etcd2-backup-coreos github.com/coreos/etcd/discovery github.com/coreos/etcd/e2e github.com/coreos/etcd/embed github.com/coreos/etcd/error github.com/coreos/etcd/etcdctl github.com/coreos/etcd/etcdctl/ctlv2 github.com/coreos/etcd/etcdctl/ctlv2/command github.com/coreos/etcd/etcdctl/ctlv3 github.com/coreos/etcd/etcdctl/ctlv3/command github.com/coreos/etcd/etcdmain github.com/coreos/etcd/etcdserver github.com/coreos/etcd/etcdserver/api github.com/coreos/etcd/etcdserver/api/v2http github.com/coreos/etcd/etcdserver/api/v2http/httptypes github.com/coreos/etcd/etcdserver/api/v3rpc github.com/coreos/etcd/etcdserver/api/v3rpc/rpctypes github.com/coreos/etcd/etcdserver/auth github.com/coreos/etcd/etcdserver/etcdserverpb github.com/coreos/etcd/etcdserver/membership github.com/coreos/etcd/etcdserver/stats github.com/coreos/etcd/integration github.com/coreos/etcd/lease github.com/coreos/etcd/lease/leasehttp github.com/coreos/etcd/lease/leasepb github.com/coreos/etcd/mvcc github.com/coreos/etcd/mvcc/backend github.com/coreos/etcd/mvcc/mvccpb github.com/coreos/etcd/pkg/adt github.com/coreos/etcd/pkg/contention github.com/coreos/etcd/pkg/cors github.com/coreos/etcd/pkg/cpuutil github.com/coreos/etcd/pkg/crc github.com/coreos/etcd/pkg/expect github.com/coreos/etcd/pkg/fileutil github.com/coreos/etcd/pkg/flags github.com/coreos/etcd/pkg/httputil github.com/coreos/etcd/pkg/idutil github.com/coreos/etcd/pkg/ioutil github.com/coreos/etcd/pkg/logutil github.com/coreos/etcd/pkg/mock/mockstorage github.com/coreos/etcd/pkg/mock/mockstore github.com/coreos/etcd/pkg/mock/mockwait github.com/coreos/etcd/pkg/monotime github.com/coreos/etcd/pkg/netutil github.com/coreos/etcd/pkg/osutil github.com/coreos/etcd/pkg/pathutil github.com/coreos/etcd/pkg/pbutil github.com/coreos/etcd/pkg/report github.com/coreos/etcd/pkg/runtime github.com/coreos/etcd/pkg/schedule github.com/coreos/etcd/pkg/stringutil github.com/coreos/etcd/pkg/testutil github.com/coreos/etcd/pkg/tlsutil github.com/coreos/etcd/pkg/transport github.com/coreos/etcd/pkg/types github.com/coreos/etcd/pkg/wait github.com/coreos/etcd/proxy/grpcproxy github.com/coreos/etcd/proxy/grpcproxy/cache github.com/coreos/etcd/proxy/httpproxy github.com/coreos/etcd/proxy/tcpproxy github.com/coreos/etcd/raft github.com/coreos/etcd/raft/raftpb github.com/coreos/etcd/raft/rafttest github.com/coreos/etcd/rafthttp github.com/coreos/etcd/snap github.com/coreos/etcd/snap/snappb github.com/coreos/etcd/store github.com/coreos/etcd/tools/benchmark github.com/coreos/etcd/tools/benchmark/cmd github.com/coreos/etcd/tools/etcd-dump-db github.com/coreos/etcd/tools/etcd-dump-logs github.com/coreos/etcd/tools/functional-tester/etcd-agent github.com/coreos/etcd/tools/functional-tester/etcd-agent/client github.com/coreos/etcd/tools/functional-tester/etcd-runner github.com/coreos/etcd/tools/functional-tester/etcd-runner/command github.com/coreos/etcd/tools/functional-tester/etcd-tester github.com/coreos/etcd/tools/local-tester/bridge github.com/coreos/etcd/version github.com/coreos/etcd/wal github.com/coreos/etcd/wal/walpb returned exit code 1 debian/rules:9: recipe for target 'override_dh_auto_test' failed make[1]: *** [override_dh_auto_test] Error 1 make[1]: Leaving directory '/build/etcd-3.1.2+dfsg' debian/rules:6: recipe for target 'binary' failed make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#857819: FTBS: Missing b-d on golang-golang-x-sys-dev && golang-github-docker-go-connections-dev
Package: containerd Version: 0.2.3~git20161117.78.03e5862~ds1-1 Severity: serious Justification: fails to build from source Hey, Trying to rebuild containerd went wrong, seems the build-depends on golang-golang-x-sys-dev and golang-github-docker-go-connections-dev are missing. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages containerd depends on: ii libc6 2.24-9 ii runc 1.0.0~rc2+git20161109.131.5137186-2 containerd recommends no packages. containerd suggests no packages. -- no debconf information
Bug#856478: Spurious key repeats
Package: libgtk-3-0 Version: 3.22.9-1 Severity: grave Tags: upstream Hey, In the wayland session ever since upgrading to 3.22.9 i'm getting spurious key repeats in some applications. This is likely to be https://bugzilla.gnome.org/show_bug.cgi?id=779374 -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libgtk-3-0 depends on: ii adwaita-icon-theme 3.22.0-1 ii hicolor-icon-theme 0.15-1 ii libatk-bridge2.0-0 2.22.0-1 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo-gobject2 1.14.8-1 ii libcairo2 1.14.8-1 ii libcolord2 1.3.3-2 ii libcups22.2.1-8 ii libepoxy0 1.3.1-2 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype62.6.3-3+b2 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-02.50.3-1 ii libgtk-3-common 3.22.9-1 ii libjson-glib-1.0-0 1.2.2-1+b1 ii libpango-1.0-0 1.40.4-1 ii libpangocairo-1.0-0 1.40.4-1 ii libpangoft2-1.0-0 1.40.4-1 ii librest-0.7-0 0.8.0-2 ii libsoup2.4-12.56.0-2 ii libwayland-client0 1.12.0-1 ii libwayland-cursor0 1.12.0-1 ii libwayland-egl1-mesa [libwayland-egl1] 13.0.5-1 ii libx11-62:1.6.4-3 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.14-1+b1 ii libxdamage1 1:1.1.4-2+b1 ii libxext62:1.3.3-1 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxinerama12:1.1.3-1+b1 ii libxkbcommon0 0.7.1-1 ii libxml2 2.9.4+dfsg1-2.2 ii libxrandr2 2:1.5.1-1 ii shared-mime-info1.8-1 Versions of packages libgtk-3-0 recommends: ii libgtk-3-bin 3.22.8-1 Versions of packages libgtk-3-0 suggests: ii gvfs 1.30.3-1 ii librsvg2-common 2.40.16-1+b1 -- no debconf information
Bug#855828: Can't publish repositories as dpkg-scanpackages isn't isntalled
Package: obs-server Version: 2.7.1-10 Severity: important Hey, Our publisher shows: Feb 20 13:08:00 niobium bs_publish[14097]: publish failed for home:alee:branches:apertis:16.03:development, 16.03 : dpkg-scanpackages failed: 256 And indeed dpkg-scanpackages isn't installed. obs-server should probably recommend dpkg-dev. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#855479: resolved: Fails lookup with no-signature for a private/local domain
Package: systemd Version: 232-18 Severity: important Tags: patch Hey, One of my VPNs runs dnsmasq and seems to trigger systemd-resolved to fail the lookup with dnssec errors: neon.elements: resolve call failed: DNSSEC validation failed: no-signature This got fixed upstream in 97c2ea26456f21334ac164f330426dd518067f08 (hence the patch flag). Fwiw the important is arguable, this does make resolved unusable for me in the default settings on certain VPNs, but the usage of resolved is probably uncommon. -- Package-specific info: -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libapparmor12.11.0-2 ii libaudit1 1:2.6.7-1 ii libblkid1 2.29.1-1 ii libc6 2.24-9 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-3 ii libgcrypt20 1.7.6-1 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-5 ii libkmod223-2 ii liblz4-10.0~r131-2 ii liblzma55.2.2-1.2 ii libmount1 2.29.1-1 ii libpam0g1.1.8-3.5 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3 ii libsystemd0 232-18 ii mount 2.29.1-1 ii util-linux 2.29.1-1 Versions of packages systemd recommends: ii dbus1.10.16-1 ii libpam-systemd 232-18 Versions of packages systemd suggests: ii policykit-10.105-17 ii systemd-container 232-18 pn systemd-ui Versions of packages systemd is related to: ii dracut 044+241-1 pn initramfs-tools ii udev 232-18 -- Configuration Files: /etc/systemd/logind.conf changed [not included] -- no debconf information
Bug#855103: Rendering fails on wayland/hidpi
Package: libwebkit2gtk-4.0-37 Version: 2.14.4-1 Severity: grave Hey, Both epiphany and evolution show blank output when trying to render website/e-mails. Downgrading libwebkit2gtk-4.0-37 to 2.14.3 seems to solve the issue. >From some notes on #debian-gnome this might be caused by: https://bugs.webkit.org/show_bug.cgi?id=168128 Which has just received a patch :) -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libwebkit2gtk-4.0-37 depends on: ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libegl1-mesa [libegl1-x11] 13.0.4-1 ii libenchant1c2a 1.6.0-11+b1 ii libfontconfig1 2.11.0-6.7 ii libfreetype62.6.3-3+b1 ii libgcc1 1:6.3.0-6 ii libgdk-pixbuf2.0-0 2.36.4-1 ii libgl1-mesa-glx [libgl1]13.0.4-1 ii libglib2.0-02.50.2-2 ii libgnutls30 3.5.8-3 ii libgstreamer-plugins-base1.0-0 1.10.3-1 ii libgstreamer1.0-0 1.10.3-1 ii libgtk-3-0 3.22.7-2 ii libharfbuzz-icu01.4.2-1 ii libharfbuzz0b 1.4.2-1 ii libhyphen0 2.8.8-5 ii libicu5757.1-5 ii libjavascriptcoregtk-4.0-18 2.14.4-1 ii libjpeg62-turbo 1:1.5.1-2 ii libnotify4 0.7.7-1 ii libpango-1.0-0 1.40.3-3 ii libpng16-16 1.6.28-1 ii libsecret-1-0 0.18.5-2 ii libsoup2.4-12.56.0-2 ii libsqlite3-03.16.2-2 ii libstdc++6 6.3.0-6 ii libwayland-client0 1.12.0-1 ii libwayland-egl1-mesa [libwayland-egl1] 13.0.4-1 ii libwayland-server0 1.12.0-1 ii libwebp60.5.2-1 ii libx11-62:1.6.4-3 ii libxcomposite1 1:0.4.4-2 ii libxdamage1 1:1.1.4-2+b1 ii libxml2 2.9.4+dfsg1-2.2 ii libxslt1.1 1.1.29-2 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages libwebkit2gtk-4.0-37 recommends: ii gstreamer1.0-plugins-base 1.10.3-1 ii gstreamer1.0-plugins-good 1.10.3-1 pn libwebkit2gtk-4.0-37-gtk2 libwebkit2gtk-4.0-37 suggests no packages. -- no debconf information
Bug#854563: Doesn't output the debootstrap log correctly
Package: obs-build Version: 20170201-1 Severity: normal The wrong path is used to print the debootstrap log on failure, fixed in https://github.com/openSUSE/obs-build/pull/335 -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages obs-build depends on: ii debootstrap 1.0.87 pn perl:any ii rpm 4.12.0.2+dfsg1-1 Versions of packages obs-build recommends: ii libcrypt-ssleay-perl 0.73.04-2 ii osc 0.156.0-1 ii rpm2cpio 4.12.0.2+dfsg1-1 obs-build suggests no packages. -- no debconf information
Bug#854559: debootstracp recipe leaks binfmt_misc mounts
Package: obs-build Version: 20170201-1 Severity: important Hey, Some packages trigger binfmt_misc to be mounted, which leaks if not unmounted after build. A patch for that is available at https://github.com/openSUSE/obs-build/pull/331/commits/7f0efeeba7f62a8266166f8def79ff503b7455bc -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages obs-build depends on: ii debootstrap 1.0.87 pn perl:any ii rpm 4.12.0.2+dfsg1-1 Versions of packages obs-build recommends: ii libcrypt-ssleay-perl 0.73.04-2 ii osc 0.156.0-1 ii rpm2cpio 4.12.0.2+dfsg1-1 obs-build suggests no packages. -- no debconf information
Bug#854557: Incorrect dev/shm path
Package: obs-build Version: 20170201-1 Severity: important Tags: patch the patch in the last upoad tried to mount shm on /dev/$myroot/shm which won't work. This got fixed in the last update of the PR #331 for obs-build -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages obs-build depends on: ii debootstrap 1.0.87 pn perl:any ii rpm 4.12.0.2+dfsg1-1 Versions of packages obs-build recommends: ii libcrypt-ssleay-perl 0.73.04-2 ii osc 0.156.0-1 ii rpm2cpio 4.12.0.2+dfsg1-1 obs-build suggests no packages. -- no debconf information
Bug#854558: dev/pts/ptmx isn't usable
Package: obs-build Version: 20170201-1 Severity: important the ptmx in the debootstrap chroot ended up not being usable, this breaks package builds which rely on a pts/tty. Fixed in: https://github.com/openSUSE/obs-build/pull/331/commits/fc08c45072851779ce67fa2f92e509dc39e5ed27 -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages obs-build depends on: ii debootstrap 1.0.87 pn perl:any ii rpm 4.12.0.2+dfsg1-1 Versions of packages obs-build recommends: ii libcrypt-ssleay-perl 0.73.04-2 ii osc 0.156.0-1 ii rpm2cpio 4.12.0.2+dfsg1-1 obs-build suggests no packages. -- no debconf information
Bug#853820: Please add support for the F flag
Package: binfmt-support Version: 2.1.6-2 Severity: wishlist As of linux 4.8 the binfmt format added the F flag which causes an emulators to be opened non-lazily, which means it can be used in a chroot without needing the emulator to be installed in the chroot. (Incredibly useful when chrooting in other-architecture root filesystems) Please add support for this. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages binfmt-support depends on: ii init-system-helpers 1.47 ii libc62.24-9 ii libpipeline1 1.4.1-2 ii lsb-base 9.20161125 binfmt-support recommends no packages. binfmt-support suggests no packages. -- no debconf information
Bug#853292: debootstrap build chroot not completely setup
Package: obs-build Version: 20160921-1 Severity: important When using the debootstrap recipe the build root doesn't get fully setup e.g. etc/hosts is missing as well as the virtual filesystem mounts. This causes some packages to fail. I've submitted some fixes for that upstream in: https://github.com/openSUSE/obs-build/pull/331 -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages obs-build depends on: ii debootstrap 1.0.87 pn perl:any ii rpm 4.12.0.2+dfsg1-1 Versions of packages obs-build recommends: ii libcrypt-ssleay-perl 0.73.04-2 ii osc 0.156.0-1 ii rpm2cpio 4.12.0.2+dfsg1-1 obs-build suggests no packages. -- no debconf information
Bug#853164: Default tasks max seems too low
Package: obs-worker Version: 2.7.1-9 Severity: normal While doing a test build of quite a few diferent package, I'm running into an issues like: [ 25s] /srv/obs/run/worker/1/build/init_buildsystem: fork: retry: Resource temporarily unavailable Starting from systemd v231 each service gets 15% of the maximum amount of tasks of the system. Which should be enough for most services, but when running a set of worker instances this can spike up during some builds and dos others. A reasonable fix would probalby to add a systemd override to the package to bump this to say 75% by default? -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#853161: All workers run as one systemd unit
Package: obs-worker Version: 2.7.1-9 Severity: normal obs-worker is a, well, not very nice init script which runs all the worker instances (under screen of all things). This means that all systemd's functionality applies to all instances together rather then specific ones, e.g. this means resource that one instance cna cause other to hit resource control limits, restarting can't work per instance etc. obs-worker should really either be a generator or a simple template systemd service. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#853145: Leaks devpts mounts
Package: obs-build Version: 20160921-1 Severity: important Tags: upstream The obs-build version in debian, at least when used with the debootstrap recip seems to leak devpts mounts (3 are present during the build, only one seems to get unmounted after the build, leaking 2). Upstream cleaned up mountpoint handling quite a bit in current git. Testing todays git indeed reveals no more leaking mountpoints, so a newer snapshot might be a reasonable way to fix this. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages obs-build depends on: ii debootstrap 1.0.87 pn perl:any ii rpm 4.12.0.2+dfsg1-1 Versions of packages obs-build recommends: ii libcrypt-ssleay-perl 0.73.04-2 ii osc 0.156.0-1 ii rpm2cpio 4.12.0.2+dfsg1-1 obs-build suggests no packages. -- no debconf information
Bug#853144: debootstrap recipe fails when building for xenial
Package: obs-build Version: 20160921-1 Severity: important Tags: upstream patch The dpkg-dev version present in xenial has a bug where it'll fail iff there are symlinks present under the path it's pointed to. This causes the debian debootstrap recipe to fail when building for xenial. Fixes for this are available in: https://github.com/openSUSE/obs-build/pull/329 -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages obs-build depends on: ii debootstrap 1.0.87 pn perl:any ii rpm 4.12.0.2+dfsg1-1 Versions of packages obs-build recommends: ii libcrypt-ssleay-perl 0.73.04-2 ii osc 0.156.0-1 ii rpm2cpio 4.12.0.2+dfsg1-1 obs-build suggests no packages. -- no debconf information
Bug#852043: Init script uses non-existing obsrun user
Package: obs-worker Version: 2.7.1-9 Severity: grave The package creates an obsworker user on install, however the init scripts tries to chown some files to the non-existing obs-run user causing it to fail. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#849237: Can't use /srv/tftp in tftpd-hpa
Package: lava-dispatcher
Version: 2016.12-1
Severity: normal
According to the installing on debian documentation, when only using V2 one can
leave the default tftp (/srv/tftp) directory as the one configured for
tftpd-hpa, however this doesn't work giving the following error in the log.
- {"dt": "2016-12-23T22:52:11.658332", "lvl": "exception", "msg": "Invalid job
data: ['tftpd directory is not configured correctly, see
/etc/default/tftpd-hpa']\n"}
It looks like this broke in upstream commit 18bb6b9895a
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel
Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lava-dispatcher depends on:
ii file 1:5.29-2
ii lava-tool 0.14-2
ii lsb-base 9.20161125
ii parted3.2-17
ii python-configglue 1.0-1
ii python-configobj 5.0.6-2
ii python-daemon 2.1.1-1
ii python-guestfs1:1.34.3-5
ii python-json-schema-validator 2.3.1-3
ii python-lzma 0.5.3-3
ii python-netifaces 0.10.4-0.1+b2
ii python-nose 1.3.7-2
ii python-pexpect4.2.1-1
ii python-pyudev 0.21.0-1
ii python-requests 2.12.4-1
ii python-serial 3.2.1-1
ii python-setuptools 32.0.0-1
ii python-yaml 3.12-1
ii python-zmq16.0.2-2
ii python2.7 2.7.13-1
pn python:any
pn ser2net
ii sudo 1.8.19-1
ii tar 1.29b-1.1
ii telnet0.17-41
Versions of packages lava-dispatcher recommends:
ii bridge-utils 1.5-10
ii git 1:2.11.0-1
ii kpartx 0.6.4-1
ii libguestfs-tools 1:1.34.3-5
ii lxc 1:2.0.6-1
ii nfs-kernel-server1:1.3.4-2
ii ntp 1:4.2.8p9+dfsg-2
ii openbsd-inetd0.20140418-2
ii python-setproctitle 1.1.10-1
ii qemu-system-x86 1:2.7+dfsg-3+b1
ii rpcbind 0.2.3-0.5
ii rsync3.1.2-1
ii sshfs2.8-1
pn tftpd-hpa
ii u-boot-tools 2016.11+dfsg1-3
ii unzip6.0-21
ii xz-utils 5.2.2-1.2
Versions of packages lava-dispatcher suggests:
ii bzr 2.7.0+bzr6619-4
-- no debconf information
Bug#849229: Unneeded dependency on ser2net
Package: lava-dispatcher Version: 2016.12-1 Severity: normal Lava dispatcher has a dependency on ser2net, but this is only needed if usng ser2net to provide serial for DUTs. Please downgrade ser2net dependency to a recommends -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lava-dispatcher depends on: ii file 1:5.29-2 ii lava-tool 0.14-2 ii lsb-base 9.20161125 ii parted3.2-17 ii python-configglue 1.0-1 ii python-configobj 5.0.6-2 ii python-daemon 2.1.1-1 ii python-guestfs1:1.34.3-5 ii python-json-schema-validator 2.3.1-3 ii python-lzma 0.5.3-3 ii python-netifaces 0.10.4-0.1+b2 ii python-nose 1.3.7-2 ii python-pexpect4.2.1-1 ii python-pyudev 0.21.0-1 ii python-requests 2.12.4-1 ii python-serial 3.2.1-1 ii python-setuptools 32.0.0-1 ii python-yaml 3.12-1 ii python-zmq16.0.2-2 ii python2.7 2.7.13-1 pn python:any pn ser2net ii sudo 1.8.19-1 ii tar 1.29b-1.1 ii telnet0.17-41 Versions of packages lava-dispatcher recommends: ii bridge-utils 1.5-10 ii git 1:2.11.0-1 ii kpartx 0.6.4-1 ii libguestfs-tools 1:1.34.3-5 ii lxc 1:2.0.6-1 ii nfs-kernel-server1:1.3.4-2 ii ntp 1:4.2.8p9+dfsg-2 ii openbsd-inetd0.20140418-2 ii python-setproctitle 1.1.10-1 ii qemu-system-x86 1:2.7+dfsg-3+b1 ii rpcbind 0.2.3-0.5 ii rsync3.1.2-1 ii sshfs2.8-1 pn tftpd-hpa ii u-boot-tools 2016.11+dfsg1-3 ii unzip6.0-21 ii xz-utils 5.2.2-1.2 Versions of packages lava-dispatcher suggests: ii bzr 2.7.0+bzr6619-4 -- no debconf information
Bug#831655: copying from https location is broken
Package: bmap-tools Version: 3.2-4 Severity: important Hey, Since 3.2-2 copying from a http location is broken: $ bmaptool copy https://images.apertis.org/daily/16.06/images/target/amd64-uefi/20160718.0/apertis-16.06-target-amd64-uefi_20160718.0-collabora.btrfs.img.gz /tmp/test.img bmaptool: info: discovered bmap file 'https://images.apertis.org/daily/16.06/images/target/amd64-uefi/20160718.0/apertis-16.06-target-amd64-uefi_20160718.0-collabora.btrfs.img.bmap' bmaptool: info: block map format version 2.0 bmaptool: info: 3662336 blocks of size 4096 (14.0 GiB), mapped 378913 blocks (1.4 GiB or 10.3%) bmaptool: info: copying image 'apertis-16.06-target-amd64-uefi_20160718.0-collabora.btrfs.img.gz' to file 'test.img' using bmap file 'apertis-16.06-target-amd64-uefi_20160718.0-collabora.btrfs.img.bmap' bmaptool: ERROR: wrote 0 blocks from image 'https://images.apertis.org/daily/16.06/images/target/amd64-uefi/20160718.0/apertis-16.06-target-amd64-uefi_20160718.0-collabora.btrfs.img.gz' to 'test.img', but should have 378913 - bmap file 'https://images.apertis.org/daily/16.06/images/target/amd64-uefi/20160718.0/apertis-16.06-target-amd64-uefi_20160718.0-collabora.btrfs.img.bmap' does not belong to this image Dropping 0004-TransRead-try-to-have-the-child-process-read-the-com.patch makes things work again. -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-rc4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages bmap-tools depends on: ii python 2.7.11-2 pn python:any Versions of packages bmap-tools recommends: ii bzip2 1.0.6-8 ii lzop 1.03-4 ii python-gpgme 0.3-1.1+b1 ii xz-utils 5.1.1alpha+20120614-2.1 Versions of packages bmap-tools suggests: ii pbzip2 1.1.9-1 pn pigz -- no debconf information
Bug#826623: Please build apitrace with waffle support
Package: apitrace Version: 7.1+git20160531.2d78bef0+repack-1 Severity: wishlist apitrace Retracers like e.g. egltrace can currently only use X11 as the window system. For more modular window system support, apitrace has support for using the waffle library (e.g. libwaffle-dev and friends). Please enable support for this in the package. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apitrace depends on: ii apitrace-tracers 7.1+git20160531.2d78bef0+repack-1 ii libbsd0 0.8.3-1 ii libc6 2.22-10 ii libgcc1 1:6.1.1-4 ii libpng16-16 1.6.21-5 ii libprocps52:3.3.11-3 ii libsnappy1v5 1.1.3-3 ii libstdc++66.1.1-4 ii libx11-6 2:1.6.3-1 ii python2.7.11-1 ii python-imaging3.2.0-2 ii zlib1g1:1.2.8.dfsg-2+b1 apitrace recommends no packages. apitrace suggests no packages. -- no debconf information
Bug#823834: Please update apitrace to a current git snapshot
Package: apitrace Version: 6.1+git20150626.62ad71c6+repack-1.1+b1 Severity: wishlist Hey, The apitrace git snapshot is ~11 months old by now, it would be great to see a newer version in Debian. Specfically eglSwapBuffersWithDamage was implemented last week, which is required to trace programs using that extension such as the wayland example. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apitrace depends on: ii apitrace-tracers 6.1+git20150626.62ad71c6+repack-1.1+b1 ii libbsd0 0.8.3-1 ii libc6 2.22-7 ii libgcc1 1:6.1.1-1 ii libpng16-16 1.6.21-4 ii libprocps52:3.3.11-3 ii libsnappy1v5 1.1.3-3 ii libstdc++66.1.1-1 ii libx11-6 2:1.6.3-1 ii python2.7.11-1 ii python-imaging3.2.0-2 ii zlib1g1:1.2.8.dfsg-2+b1 apitrace recommends no packages. apitrace suggests no packages. -- no debconf information
Bug#735377: 3.0 (native) silently ignores many binary files by default.
On Thu, Jan 16, 2014 at 08:44:14AM +0100, Raphael Hertzog wrote:
> Control: retitle -1 document how to un-ignore files ignored by default in
> "3.0 (native)" and "3.0 (quilt)"
>
> On Wed, 15 Jan 2014, peter green wrote:
> > When attempting to build such a package using the 3.0 native format
> > the source package build and binary package builds will succeed, but
> > the "source" package won't actually contain the binaries that were
> > in the source tree and so when someone comes to unpack said source
> > package again to make a change they will find it is incomple.
> >
> > IMO silently ignoring such files is a crazy default, either the
> > files should be included or source package build should scream and
> > die (thus prompting the packager that they need to either fix thier
> > clean target or override something).
>
> It doesn't silently ignore random binary files, it ignores the files
> that are on its default ignore list and which are documented
> in dpkg-source --help:
>
> -I[]filter out files when building tarballs
> (defaults to: -I*.a -I*.la -I*.o -I*.so -I.*.sw?
> -I*/*~ -I,,* -I.[#~]* -I.arch-ids -I.arch-inventory -I.be -I.bzr
> -I.bzr.backup -I.bzr.tags -I.bzrignore -I.cvsignore -I.deps -I.git
> -I.gitattributes -I.gitignore -I.gitmodules -I.hg -I.hgignore -I.hgsigs
> -I.hgtags -I.shelf -I.svn -ICVS -IDEADJOE -IRCS -I_MTN -I_darcs -I{arch}).
>
> So yes, *.a, *.la, *.o and *.so are ignored by default in native source
> package
> and this is is so for as long as I can remember.
>
> If you are unhappy with the default, please change it for your package
> with debian/source/options:
>
> tar-ignore=.git
> tar-ignore=.gitignore
>
> As soon as you start being explicit about the ignore rules, the default
> ignore rules are no longer used but you can put the default ignore rule
> back with a single "tar-ignore" (i.e. without value).
I tried this, dpkg-buildpackage then starts complaining:
dpkg-source: warning: --tar-ignore= is not a valid option for
Dpkg::Source::Package::V3::Native
This solution does work when switching back to source format 1 though
--
Neutrinos have bad breadth.
Bug#806715: [jenkins-job-builder] Publish over SSH xml broken when used as publisher
Package: jenkins-job-builder Version: 1.3.0+2015.12.15.git136.959eb4b909-1 Followup-For: Bug #806715 This has been broken by the following patch: debian/patches/patches/0005-builders-add-publish-over-ssh-support-as-a-build-ste.patch This patch hasn't been merged upstream and the review comments also point out it breaks existing situations (ditto the automated checks): https://review.openstack.org/#/c/98437/ Please drop this patch form the package until it gets fixed -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages jenkins-job-builder depends on: ii python-jenkins-job-builder 1.3.0+2015.12.15.git136.959eb4b909-1 jenkins-job-builder recommends no packages. jenkins-job-builder suggests no packages. -- no debconf information
Bug#810085: Please enable CONFIG_GPIO_SYSFS on x86/am64
Source: linux Severity: wishlist Hey, In current debian kernels CONFIG_GPIO_SYSFS is only set for ARM kernels. This options allows userspace to directly tinker with GPIO (if they're not bound by a driver). Which is quite useful on development boards with GPIO extension headers to tinker with electronics without having to write a full kernel driver. With the appearance of embedded/development based on Intel chips like e.g. the Minnowboard, this is also useful on x86/amd64. (Actually if you use some of the Minnowboard howto's/tutorials it's the suggested way for playing with GPIO there). So as the subject says, please enable CONFIG_GPIO_SYSFS on at least the x86 architectures as well. Though it might be useful to generally enable it (e.g. at least mips has some devboards as well, probably others too). -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#774903: Please add a python3 packge (and run tests at build-time)
Package: python-git
Version: 1.0.1+git137-gc8b8379-2
Followup-For: Bug #774903
Ping.
Attached is an update patch for adding the python3 package to the last versin
of python-git. I've kept Mattia in the changelog as he's really done all the
work.
Also this is just adding the new package, not switching to pybuild and tweaking
other bits. Running wrap-and-sort is probably still recommended though .
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel
Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages python-git depends on:
ii git [git-core] 1:2.6.2-1
ii git-core1:2.6.2-1
ii libjs-jquery1.11.3+dfsg-4
ii python 2.7.9-1
ii python-gitdb0.6.4-3
python-git recommends no packages.
Versions of packages python-git suggests:
ii python-smmap 0.9.0-2
-- no debconf information
diff --git a/debian/changelog b/debian/changelog
index 0ffed44..27c2e8b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+python-git (1.0.1+git137-gc8b8379-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+
+ -- Sjoerd Simons <sjo...@debian.org> Wed, 02 Dec 2015 20:14:07 +0100
+
python-git (1.0.1+git137-gc8b8379-2) unstable; urgency=medium
[ SVN-Git Migration ]
diff --git a/debian/control b/debian/control
index 75d5410..3914b1d 100644
--- a/debian/control
+++ b/debian/control
@@ -3,11 +3,24 @@ Section: python
Priority: optional
Maintainer: Debian Python Modules Team <python-modules-t...@lists.alioth.debian.org>
Uploaders: Vincent Bernat <ber...@debian.org>,
- TANIGUCHI Takaki <tak...@debian.org>
-Build-Depends: debhelper (>= 7.0.50~), python, python-setuptools (>= 0.6a9),
- python-sphinx,
- python-nose, python-smmap (>= 0.8.3~), python-gitdb (>= 0.6.4), python-mock,
- git,
+ TANIGUCHI Takaki <tak...@debian.org>
+Build-Depends: debhelper (>= 7.0.50~),
+ dh-python,
+ git,
+ python,
+ python-gitdb (>= 0.6.4),
+ python-mock,
+ python-nose,
+ python-setuptools (>= 0.6a9),
+ python-smmap (>= 0.8.3~),
+ python-sphinx,
+ python3,
+ python3-gitdb (>= 0.6.4),
+ python3-mock,
+ python3-nose,
+ python3-setuptools (>= 0.6a9),
+ python3-smmap (>= 0.8.3~),
+ python3-sphinx
Standards-Version: 3.9.6
Homepage: https://github.com/gitpython-developers/GitPython
X-Python-Version: >= 2.7
@@ -16,15 +29,31 @@ Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/python-git.
Package: python-git
Architecture: all
-Depends: ${python:Depends},
- git (>= 1:1.7) | git-core (>= 1:1.5.3.7),
- ${misc:Depends},
- libjs-jquery,
- python-gitdb (>= 0.6.4)
-Suggests:
- python-smmap
+Depends: git (>= 1:1.7) | git-core (>= 1:1.5.3.7),
+ libjs-jquery,
+ python-gitdb (>= 0.6.4),
+ ${misc:Depends},
+ ${python:Depends}
+Suggests: python-smmap
+XB-Python-Version: ${python:Versions}
Description: Python library to interact with Git repositories
python-git provides object model access to a Git repository, so Python can be
used to manipulate it. Repository objects can be opened or created, which can
then be traversed to find parent commit(s), trees, blobs, etc.
-XB-Python-Version: ${python:Versions}
+ .
+ This package provides the python2 build.
+
+Package: python3-git
+Architecture: all
+Depends: git (>= 1:1.7) | git-core (>= 1:1.5.3.7),
+ libjs-jquery,
+ python3-gitdb (>= 0.6.4),
+ ${misc:Depends},
+ ${python3:Depends}
+XB-Python-Version: ${python3:Versions}
+Description: Python library to interact with Git repositories - python3 package
+ python-git provides object model access to a Git repository, so Python can be
+ used to manipulate it. Repository objects can be opened or created, which can
+ then be traversed to find parent commit(s), trees, blobs, etc.
+ .
+ This package provides the python3 build.
Bug#806780: --foreign/--second-stage breaks with multiple components
Package: debootstrap
Version: 1.0.75
Severity: normal
Tags: patch
When passing multiple components to --second-stage things fail as debootstrap
tries to open debootstrap.invalid_dists_badger_snake|mushroom-armhf.Packages
rather then seperate Packages file for snake and mushroom.
Fixed in attached patch
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel
Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages debootstrap depends on:
ii wget 1.17-1
Versions of packages debootstrap recommends:
ii debian-archive-keyring 2014.3
ii gnupg 1.4.19-6
debootstrap suggests no packages.
-- no debconf information
>From 6621d8304cb79dcc6e07098caaf6eaa56fe8594a Mon Sep 17 00:00:00 2001
From: Sjoerd Simons <sjoerd.sim...@collabora.co.uk>
Date: Tue, 1 Dec 2015 09:09:07 +0100
Subject: [PATCH] Fix multiple components usage for --foreign
commit e24e4b006736734e, bug #757819 made resolve_deps and
setup_available in the --foreign case. However this only worked when
using just one component as the USE_COMPONENTS variable is | delimited.
Translate the USE_COMPONENTS variable on the fly from | delimited to
space delimeted to allow multiple components to work again.
Signed-off-by: Sjoerd Simons <sjoerd.sim...@collabora.co.uk>
---
functions | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/functions b/functions
index 8bef5e6..64d76e4 100644
--- a/functions
+++ b/functions
@@ -1256,14 +1256,14 @@ resolve_deps () {
local ALLPKGS2="";
while [ "$PKGS" != "" ]; do
local NEWPKGS=""
- for c in ${COMPONENTS:-$USE_COMPONENTS}; do
+ for c in ${COMPONENTS:-$(echo ${USE_COMPONENTS} | tr '|' ' ')}; do
local path="dists/$SUITE/$c/binary-$ARCH/Packages"
local pkgdest="$TARGET/$($DLDEST pkg "$SUITE" "$c" "$ARCH" "$m1" "$path")"
NEWPKGS="$NEWPKGS $("$PKGDETAILS" GETDEPS "$pkgdest" $PKGS)"
done
PKGS=$(echo "$PKGS $NEWPKGS" | tr ' ' '\n' | sort | uniq)
local REALPKGS=""
- for c in ${COMPONENTS:-$USE_COMPONENTS}; do
+ for c in ${COMPONENTS:-$(echo ${USE_COMPONENTS} | tr '|' ' ')}; do
local path="dists/$SUITE/$c/binary-$ARCH/Packages"
local pkgdest="$TARGET/$($DLDEST pkg "$SUITE" "$c" "$ARCH" "$m1" "$path")"
REALPKGS="$REALPKGS $("$PKGDETAILS" PKGS REAL "$pkgdest" $PKGS | sed -n 's/ .*REAL.*$//p')"
@@ -1279,7 +1279,7 @@ resolve_deps () {
setup_available () {
local m1="${MIRRORS%% *}"
- for c in ${COMPONENTS:-$USE_COMPONENTS}; do
+ for c in ${COMPONENTS:-$(echo ${USE_COMPONENTS} | tr '|' ' ')}; do
local path="dists/$SUITE/$c/binary-$ARCH/Packages"
local pkgdest="$TARGET/$($DLDEST pkg "$SUITE" "$c" "$ARCH" "$m1" "$path")"
# XXX: What if a package is in more than one component?
--
2.6.2
Bug#806782: Should pass --components to the second stage debootstrap
Source: live-build
Version: 5.0~a11-2
Severity: normal
Tags: patch
Commit e24e4b in debootstrap fixed setup_available to work in the
--foreign case (iotw at the second stage). Unfortunately this breaks
things if components aren't passed to the second stage _and_ your main
component isn't called main.
Attached patch fixes this by passing --components to both the first and second
stage debootstrap when needed.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel
Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 6c01323d32b4daafe55213c61ec0d85947bca5cd Mon Sep 17 00:00:00 2001
From: Sjoerd Simons <sjoerd.sim...@collabora.co.uk>
Date: Tue, 1 Dec 2015 09:45:54 +0100
Subject: [PATCH] Pass components to debootstrap --second-stage
Commit e24e4b in debootstrap fixed setup_available to work in the
--foreign case (iotw at the second stage). Unfortunately this breaks
things if components aren't passed to the second stage _and_ your main
component isn't called main.
To fix this, pass --components to both the first and second stage
debootstrap when needed.
Signed-off-by: Sjoerd Simons <sjoerd.sim...@collabora.co.uk>
---
scripts/build/bootstrap_debootstrap | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/build/bootstrap_debootstrap b/scripts/build/bootstrap_debootstrap
index d79f670..26f9228 100755
--- a/scripts/build/bootstrap_debootstrap
+++ b/scripts/build/bootstrap_debootstrap
@@ -62,6 +62,7 @@ if [ "${LB_ARCHIVE_AREAS}" != "main" ]
then
# Modify archive areas to remove leading/trailing whitespaces and replace other whitepspace with commas
DEBOOTSTRAP_OPTIONS="${DEBOOTSTRAP_OPTIONS} --components=$(echo ${LB_ARCHIVE_AREAS} | sed -e 's| |,|g')"
+ FOREIGN_DEBOOTSTRAP_OPTIONS="--components=$(echo ${LB_ARCHIVE_AREAS} | sed -e 's| |,|g')"
fi
if [ "${_VERBOSE}" = "true" ]
@@ -112,7 +113,7 @@ then
Echo_message "Running debootstrap second stage under QEMU"
cp ${LB_BOOTSTRAP_QEMU_STATIC} chroot/usr/bin
- Chroot chroot /bin/sh /debootstrap/debootstrap --second-stage
+ Chroot chroot /bin/sh /debootstrap/debootstrap --second-stage ${FOREIGN_DEBOOTSTRAP_OPTIONS}
else
debootstrap ${DEBOOTSTRAP_OPTIONS} "${LB_PARENT_DISTRIBUTION}" chroot "${LB_PARENT_MIRROR_BOOTSTRAP}" "${DEBOOTSTRAP_SCRIPT}"
fi
--
2.6.2
Bug#803166: u-boot: enable rockchip platforms
On Tue, 2015-10-27 at 10:20 -0700, Vagrant Cascadian wrote: > On 2015-10-27, Emilio Pozuelo Monfort wrote: > > The attached patch creates a rockchip package and enables the > > firefly-rk3288 platform. > > Thanks! > > > > rock2-rk3288 and rock2-sd-rk3288 are commented out for now as those > > are not upstreamed yet. > > I'd rather leave them out entirely until they're supported. Yes please leave those out, I don't intend to upstream them as-is. This was more a quick short-cut to make it easy to build those in the kernel u-boot package for some of the bits we're working on currently :). Eventually the rock2 support should land upstream as a seperate DTB from the firefly, which can be build using the same config. It's just that debians packaging can't do alternate device-trees just yet. Well that and nobody figured out how to determine what storage the SPL got loaded from on Rockchip so you currently need different configuration when booting from EMMC vs. SD. > > Sjoerd (Cc'ed) is working upstream on this, and has volunteered > > to keep this working / test new versions. I will be happy to do > > that too, so long as I still have the hardware. > > Great! > > > > diff -ruNp -x '*patch' u-boot-2015.10~rc4+dfsg1/debian/rules u- > > boot-2015.10+dfsg1/debian/rules > > --- u-boot-2015.10~rc4+dfsg1/debian/rules 2015-09-29 > > 01:02:28.0 +0200 > > +++ u-boot-2015.10+dfsg1/debian/rules 2015-10-27 > > 13:36:03.145766654 +0100 > > @@ -56,6 +56,11 @@ override_dh_auto_build: > > echo $$builddir/$$target > > /usr/lib/u-boot/$$platform/ \ > > >> > > debian/build/targets.$$subarch; \ > > done ;; \ > > + rockchip) \ > > + echo $$builddir/spl/u-boot-spl-dtb.rksd > > /usr/lib/u-boot/$$platform/ \ > > + >> debian/build/targets.$$subarch; > > \ > > + echo $$builddir >> debian/build/rksd; \ > > + ;; \ > > esac; \ > > done > > > > @@ -79,6 +84,10 @@ override_dh_auto_build: > > $(CROSS_COMPILE)strip --remove-section=.comment > > $(TOOLSDIR)/tools/kwboot > > $(CROSS_COMPILE)strip --remove-section=.comment > > $(TOOLSDIR)/tools/mksunxiboot > > > > + set -e; for platform in `cat debian/build/rksd`; do \ > > + $(TOOLSDIR)/tools/mkimage -T rksd -d > > $$platform/spl/u-boot-spl-dtb.bin $$platform/spl/u-boot-spl- > > dtb.rksd; \ > > + done > > + > > override_dh_auto_test: > > # skip tests. > > > > Unfortunately, the patch FTBFS for me: > > arm-linux-gnueabihf-strip --remove-section=.comment > debian/build/tools/tools/kwboot > arm-linux-gnueabihf-strip --remove-section=.comment > debian/build/tools/tools/mksunxiboot > set -e; for platform in `cat debian/build/rksd`; do \ > debian/build/tools/tools/mkimage -T rksd -d > $platform/spl/u-boot-spl-dtb..bin $platform/spl/u-boot-spl-dtb.rksd; > \ > done > /bin/sh: 2: debian/build/tools/tools/mkimage: not found > make[1]: *** [override_dh_auto_build] Error 127 > debian/rules:30: recipe for target 'override_dh_auto_build' failed > make[1]: Leaving directory '/«BUILDDIR»/u-boot-2015.10+dfsg1' > make: *** [build] Error 2 > > > I'm wondering if it wouldn't be cleaner to add support to upstream's > Makefile to build u-boot-spl-dtb.rksd images, rather than muck around > in > debian/rules? Something i've been thinking about but didn't have the time for, that should solve your issue with cross-building indeed. > Or simply document the process to generate the rksd images > in README.Debian? Personally I think the less runes are needed for people to update u- boot on their devices the better. But that should work fine as a temporary measure at least :) -- Sjoerd Simons <sjo...@debian.org>
Bug#800440: Please include BCM4339 SDIO firmware
Package: firmware-brcm80211 Version: 0.44 Severity: wishlist BCM4339 SDIO has been added to the upstream linux-firmware git repository earlier this year, please including it in the firmware-brcm80211 package. For reference this is the brcm/brcmfmac4339-sdio.bin file -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 4.2.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) firmware-brcm80211 depends on no packages. firmware-brcm80211 recommends no packages. Versions of packages firmware-brcm80211 suggests: ii initramfs-tools 0.120 -- no debconf information
Bug#791651: Does not run chroot hooks
On Wed, 2015-07-08 at 08:11 +0200, Daniel Baumann wrote: On 07/08/2015 08:09 AM, Sjoerd Simons wrote: That's weird, that patch is against git HEAD of the deiban branch on git://live-systems.org/git/live-build.git, am i looking at the wrong git repository/git branch or did you not push it just yet ? see README in the master branch, we use debian-next for development. Great thanks for clarifying, i never looked at the README in the master branch as the debian one was the default repository. However your type fixes patch is incomplete, it still looks in the wrong path to non-splitup path to determine whether there are hooks to run... -- Sjoerd Simons sjo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791651: Does not run chroot hooks
On Tue, 2015-07-07 at 18:59 +0200, Daniel Baumann wrote: Hi, this is already fixed in git, i didn't manage to upload a new version yet though, sorry about that. That's weird, that patch is against git HEAD of the deiban branch on git://live-systems.org/git/live-build.git, am i looking at the wrong git repository/git branch or did you not push it just yet ? -- Sjoerd Simons sjo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791651: Does not run chroot hooks
Package: live-build
Version: 5.0~a9-1
Severity: important
Tags: patch
Hey,
Seems like git commit 50794b1de broke running the chroot hooks.. Fixed in
attached patch
-- Package-specific info:
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel
Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages live-build depends on:
ii debootstrap 1.0.70
Versions of packages live-build recommends:
ii apt-utils 1.0.9.10
ii cpio2.11+dfsg-4.1
ii live-boot-doc 5.0~a4-1
ii live-config-doc 5.0~a3-1
ii live-manual-html [live-manual] 1:5.0~a1-1
ii wget1.16.3-3
Versions of packages live-build suggests:
ii debian-keyring 2015.06.19
ii gpgv1.4.19-3
-- no debconf information
From 03b5bb93dba75bafb3c41a20bdab30bc984aa7d2 Mon Sep 17 00:00:00 2001
From: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Date: Tue, 7 Jul 2015 10:35:44 +0200
Subject: [PATCH] Fix running of local hooks
Commit 50794b1de broke running any local chroot hooks as it's both
looking in the wrong spot to see if there are any hooks and if it would
look in the right spot it tries to run the wrong type of hooks (binary
rather then chroot)...
Fix this to make hooks work again
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
scripts/build/chroot_hooks | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/build/chroot_hooks b/scripts/build/chroot_hooks
index d202260..4fbacdb 100755
--- a/scripts/build/chroot_hooks
+++ b/scripts/build/chroot_hooks
@@ -78,12 +78,12 @@ then
fi
## Processing local hooks
-if ls config/hooks/*.chroot /dev/null 21
+if ls config/hooks/normal/*.chroot config/hooks/live/*.chroot /dev/null 21
then
# Restoring cache
Restore_cache cache/packages.chroot
- for HOOK in config/hooks/normal/*.binary config/hooks/live/*.binary
+ for HOOK in config/hooks/normal/*.chroot config/hooks/live/*.chroot
do
if [ ! -e ${HOOK} ]
then
--
2.1.4
Bug#790033: Allow custom configuration of the debootstrap script to use
Package: live-build
Version: 5.0~a9-1
Severity: wishlist
Tags: patch
Debootstrap likes using specific scripts for each distribution it builds,
however for derivates that don't have their own script in debootstrap it's
quite convenient to use the existing Debian script if possible. Attached patch
adds support to live-build to specify this.
-- Package-specific info:
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel
Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages live-build depends on:
ii debootstrap 1.0.70
Versions of packages live-build recommends:
ii apt-utils 1.0.9.10
ii cpio2.11+dfsg-4.1
ii live-boot-doc 5.0~a4-1
ii live-config-doc 5.0~a3-1
ii live-manual-html [live-manual] 1:5.0~a1-1
ii wget1.16.3-3
Versions of packages live-build suggests:
ii debian-keyring 2015.06.19
ii gpgv1.4.19-3
-- no debconf information
From 8807f764683bbec3d00d8a5a1d1d75a28317ea68 Mon Sep 17 00:00:00 2001
From: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Date: Fri, 26 Jun 2015 15:10:30 +0200
Subject: [PATCH] Add an internal debootstrap-script option
Similar to the debootstrap-options, this allows one to set the
debootstrap script debootstrap will use. This is useful for building
derivatives that don't have debootstrap scripts available in debians
debootstrap package
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
scripts/build/bootstrap_debootstrap | 6 +++---
scripts/build/config| 8 +++-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/scripts/build/bootstrap_debootstrap b/scripts/build/bootstrap_debootstrap
index bd646ff..d79f670 100755
--- a/scripts/build/bootstrap_debootstrap
+++ b/scripts/build/bootstrap_debootstrap
@@ -87,7 +87,7 @@ then
fi
Echo_breakage Running debootstrap (download-only)...
- debootstrap ${DEBOOTSTRAP_OPTIONS} --download-only ${LB_PARENT_DISTRIBUTION} chroot ${LB_PARENT_MIRROR_BOOTSTRAP}
+ debootstrap ${DEBOOTSTRAP_OPTIONS} --download-only ${LB_PARENT_DISTRIBUTION} chroot ${LB_PARENT_MIRROR_BOOTSTRAP} ${DEBOOTSTRAP_SCRIPT}
# Removing old cache
rm -f cache/packages.bootstrap/*.deb
@@ -108,13 +108,13 @@ then
fi
Echo_message Bootstrap will be foreign
- debootstrap ${DEBOOTSTRAP_OPTIONS} --foreign ${LB_PARENT_DISTRIBUTION} chroot ${LB_PARENT_MIRROR_BOOTSTRAP}
+ debootstrap ${DEBOOTSTRAP_OPTIONS} --foreign ${LB_PARENT_DISTRIBUTION} chroot ${LB_PARENT_MIRROR_BOOTSTRAP} ${DEBOOTSTRAP_SCRIPT}
Echo_message Running debootstrap second stage under QEMU
cp ${LB_BOOTSTRAP_QEMU_STATIC} chroot/usr/bin
Chroot chroot /bin/sh /debootstrap/debootstrap --second-stage
else
- debootstrap ${DEBOOTSTRAP_OPTIONS} ${LB_PARENT_DISTRIBUTION} chroot ${LB_PARENT_MIRROR_BOOTSTRAP}
+ debootstrap ${DEBOOTSTRAP_OPTIONS} ${LB_PARENT_DISTRIBUTION} chroot ${LB_PARENT_MIRROR_BOOTSTRAP} ${DEBOOTSTRAP_SCRIPT}
fi
# Deconfiguring debootstrap configurations
diff --git a/scripts/build/config b/scripts/build/config
index 66bf64f..d0e8cf4 100755
--- a/scripts/build/config
+++ b/scripts/build/config
@@ -125,7 +125,7 @@ USAGE=${PROGRAM} [--apt apt|aptitude]\n\
Local_arguments ()
{
- LONG_OPTIONS=apt:,apt-ftp-proxy:,apt-http-proxy:,apt-options:,aptitude-options:,debootstrap-options:,
+ LONG_OPTIONS=apt:,apt-ftp-proxy:,apt-http-proxy:,apt-options:,aptitude-options:,debootstrap-options:,debootstrap-script:,
apt-pipeline:,apt-recommends:,apt-secure:,apt-source-archives:,bootstrap:,cache:,cache-indices:,cache-packages:,
cache-stages:,debconf-frontend:,debconf-priority:,dump,
initramfs:,initramfs-compression:,initsystem:,fdisk:,losetup:,mode:,system:,tasksel:,
@@ -258,6 +258,11 @@ Local_arguments ()
shift 2
;;
+ --debootstrap-script)
+DEBOOTSTRAP_SCRIPT=${2}
+shift 2
+;;
+
--cache)
LB_CACHE=${2}
shift 2
@@ -990,6 +995,7 @@ _QUIET=${_QUIET}
APT_OPTIONS=${APT_OPTIONS}
APTITUDE_OPTIONS=${APTITUDE_OPTIONS}
DEBOOTSTRAP_OPTIONS=${DEBOOTSTRAP_OPTIONS}
+DEBOOTSTRAP_SCRIPT=${DEBOOTSTRAP_SCRIPT}
GZIP_OPTIONS=${GZIP_OPTIONS}
ISOHYBRID_OPTIONS=${ISOHYBRID_OPTIONS}
EOF
--
2.1.4
Bug#789760: arc diff fails with a conduit error
Package: arcanist
Version: 0~git20150613-1
Severity: important
In current unstable arc diff fails with:
Exception
ERR-CONDUIT-CORE: Invalid parameter information was passed to method
'differential.query', could not decode JSON serialization. Data:
{authors:[PHID-USER-tiexds33yvgetrvgglxc],status:status-open,ids%3
Which makes it seems like only part of the data gets sent to the server.. It
appears that downgrading libcurl3 to the jessie version fixes it, however i'm
not sure if the root cause is a bug in curl or arcenist/php's usage of it so
filing the bug against arcanist.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (101,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel
Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages arcanist depends on:
ii libphutil 0~git20150613-1
ii php5-cli 5.6.9+dfsg-1
ii php5-curl 5.6.9+dfsg-1
arcanist recommends no packages.
Versions of packages arcanist suggests:
ii python 2.7.9-1
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784432: FTBS when build under /usr
On Fri, 2015-05-08 at 19:09 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: On Wednesday 06 May 2015 11:52:32 Sjoerd Simons wrote: [snip] dir being the full path to the source files, basedir /usr, when dir doesn't start with /usr this is a noop, but if it is the /usr part gets replaced and things break... Thanks for the analysis! Patch attached to fix this Sadly I can't take that one easily. If the line is there it's with a purpose. I really should ask upstream why that line is there. By all means, make sure it's the right solution. But even there there is not much gain with this fix: we are retiring this source package in stretch [0]. Do you have a very good reason to fix this considering the above? We do small debian derivaties/rebuilds for some customers, this issue breaks us rebuilding Jessie every time (iotw we have to patch it to build jessie fully from source) (and rebuilding stretch as long as the source pacakge sticks around). So it would be great to see it fixed. -- Sjoerd Simons sjo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784432: FTBS when build under /usr
Source: qtwebkit
Version: 2.3.4.dfsg-3
Severity: normal
Tags: patch
Hey,
When building qtwebkit in a directory under /usr (e.g. /usr/src) the following
compiler error occurs:
In file included from
/usr/src/packages/BUILD/qtwebkit-2.3.4.dfsg/Source/WebKit/qt/declarative/qdeclarativewebview_p.h:29:0,
from
/usr/src/packages/BUILD/qtwebkit-2.3.4.dfsg/Source/WebKit/qt/declarative/qdeclarativewebview.cpp:21:
../../../../include/QtWebKit/qgraphicswebview.h:1:81: fatal error:
../../../../../../../../../../Source/WebKit/qt/Api/qgraphicswebview.h: No such
file or directory
#include
../../../../../../../../../../Source/WebKit/qt/Api/qgraphicswebview.h
^
compilation terminated.
This turns out to be because syncqt-4.8 generated incorrect relative paths due
to this section of code:
sub fixPaths {
my ($file, $dir) = @_;
$dir =~ s=^$quoted_basedir/=$out_basedir/= if(!($basedir eq
$out_basedir));
dir being the full path to the source files, basedir /usr, when dir doesn't
start with /usr this is a noop, but if it is the /usr part gets replaced and
things break...
Patch attached to fix this
--- a/Tools/qmake/syncqt-4.8
+++ b/Tools/qmake/syncqt-4.8
@@ -353,7 +353,6 @@
##
sub fixPaths {
my ($file, $dir) = @_;
-$dir =~ s=^$quoted_basedir/=$out_basedir/= if(!($basedir eq $out_basedir));
$file =~ s=\\=/=g;
$dir =~ s=\\=/=g;
Bug#770734: systemd: FTBFS in environment with all packages rebuilt locally
On Sat, Apr 04, 2015 at 07:48:28AM -0700, Daniel Schepler wrote: On Wed, Jan 21, 2015 at 8:04 AM, Michael Biebl bi...@debian.org wrote: Hi Daniel, Am 23.11.2014 um 19:02 schrieb Daniel Schepler: I can't reproduce this with a vanilla pbuilder setup, so I'm not sure what's causing the difference between the two builds. Can you provide any steps how we can reproduce the issue? Does this problem happen with a fresh checkout of the sources, i.e. when you run apt-get source -b systemd? I finally tracked down a simple way to reproduce the build failure (all in a pbuilder login session with the sources line uncommented in /etc/apt/sources.list): 1. mkdir /tmp/intltool; cd /tmp/intltool; apt-get build-dep intltool --no-install-recommends; apt-get source -b intltool 2. dpkg -i intltool_*.deb; apt-get -f install --no-install-recommends 3. mkdir /tmp/systemd; cd /tmp/systemd; apt-get build-dep systemd --no-install-recommends; apt-get source -b systemd The strange thing is: the file contents of the newly built intltool package and the official intltool package are identical. About the only difference I can see between them is in the file timestamps. I've just hit the issue on a rebuild we're doing for a derivative. The problem isn't intltool, it's that autools want to rebuild org.freedesktop.hostname1.policy due to intltool-merge now being more recent then the policy file in the source tarball. Remaking the policy file fails because there is no src/hostname directory in the out-of-tree build... In turn the reason there isn't a src/hostname directory is because we configure with --disable-dependency-tracking (dh_auto_configure default as it's meant to speed up one-time builds).. Lovely. I'm having a look whether i can fix upstreams autofoo to make this work properly. Sjoerd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770734: systemd: FTBFS in environment with all packages rebuilt locally
tag 770734 - moreinfo unreproducible tag 770734 + patch thanks On Fri, May 01, 2015 at 09:43:31AM +0200, Sjoerd Simons wrote: Remaking the policy file fails because there is no src/hostname directory in the out-of-tree build... In turn the reason there isn't a src/hostname directory is because we configure with --disable-dependency-tracking (dh_auto_configure default as it's meant to speed up one-time builds).. Lovely. Further investigation makes me believe fixing it in intltools autofoo is better, attached patch ensures the target directory always exists. Note the previous patch suggested in this bug, to make the target not depend on intltool-merge, only works around the symptom not the problem -- At ebb tide I wrote a line upon the sand, and gave it all my heart and all my soul. At flood tide I returned to read what I had inscribed and found my ignorance upon the shore. -- Kahlil Gibran --- a/intltool.m4 +++ b/intltool.m4 @@ -27,6 +27,7 @@ AC_DEFUN([IT_PROG_INTLTOOL], [ AC_PREREQ([2.50])dnl AC_REQUIRE([AM_NLS])dnl +AC_REQUIRE([AC_PROG_MKDIR_P])dnl case $am__api_version in 1.[01234]) @@ -72,29 +73,29 @@ AC_SUBST(intltool__v_merge_options_) AC_SUBST(intltool__v_merge_options_0) - INTLTOOL_DESKTOP_RULE='%.desktop: %.desktop.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -d -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' -INTLTOOL_DIRECTORY_RULE='%.directory: %.directory.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -d -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' - INTLTOOL_KEYS_RULE='%.keys: %.keys.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -k -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' - INTLTOOL_PROP_RULE='%.prop: %.prop.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -d -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' - INTLTOOL_OAF_RULE='%.oaf: %.oaf.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -o -p $(top_srcdir)/po $ [$]@' - INTLTOOL_PONG_RULE='%.pong: %.pong.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -x -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' - INTLTOOL_SERVER_RULE='%.server:%.server.in$(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -o -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' -INTLTOOL_SHEET_RULE='%.sheet: %.sheet.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -x -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' -INTLTOOL_SOUNDLIST_RULE='%.soundlist: %.soundlist.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -d -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' - INTLTOOL_UI_RULE='%.ui:%.ui.in$(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -x -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' - INTLTOOL_XML_RULE='%.xml: %.xml.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -x -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' + INTLTOOL_DESKTOP_RULE='%.desktop: %.desktop.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)$(MKDIR_P) $(@D) LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -d -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' +INTLTOOL_DIRECTORY_RULE='%.directory: %.directory.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)$(MKDIR_P) $(@D) LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -d -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' + INTLTOOL_KEYS_RULE='%.keys: %.keys.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir)/po/*.po) ; $(INTLTOOL_V_MERGE)$(MKDIR_P) $(@D) LC_ALL=C $(INTLTOOL_MERGE) $(INTLTOOL_V_MERGE_OPTIONS) -k -u -c $(top_builddir)/po/.intltool-merge-cache $(top_srcdir)/po $ [$]@' + INTLTOOL_PROP_RULE='%.prop: %.prop.in $(INTLTOOL_MERGE) $(wildcard $(top_srcdir
Bug#781999: Please install device-tree blobs in /boot
Package: linux Severity: wishlist Hey, The ARM linux image packages install DTB files in /usr/lib/kernel version/, as a DTB is required to boot most modern arm systems typically the right file has to be copied to a bootloader accessible filesystem before usage (e.g. /boot). On current Debian systems this tends to be done by flash-kernel. This ofcourse works fine for device-specific images, however for generic ARM images that's pretty nasty. I've recently started using the newish u-boot generic distro support on my boards[0], which among other things allows one to simply specify a directory containing the DTB files and u-boot will pick the right one based on the board it's booting on.. Allowing generic images to be booted on boards where u-boot is in e.g. flash. Ofcourse, this means all potentially used dtb files should be on a boot-loader accessible partition, not just one specific board. As such the request to install dtb files in /boot, which also follows the convention in the upstream build system. For reference when using linux-image-3.19.0-trunk-armmp this would add ~8 mbyte of dtb files to /boot, current linux-next's multi_v7 configuration generates around ~11 mbyte of dtb files. 0: http://git.denx.de/?p=u-boot.git;a=blob_plain;f=doc/README.distro;hb=HEAD -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf, armel Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761306: Bug#771101: Bug#761306: Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
On Thu, Nov 27, 2014 at 05:48:45PM +0100, Michael Biebl wrote: Am 27.11.2014 um 16:41 schrieb Michael Biebl: Am 27.11.2014 um 15:59 schrieb Michael Biebl: I would have expected, that the socket does *not* exist before systemd is re-execd, but apparently I had a file there: srw-rw-rw- 1 root root 0 Oct 10 10:41 /run/systemd/notify and no process listening on it. (don't worry about the date, it was run in a VM with a busted clock). *Some* process is triggering the creation of the notification socket and it also seems to have the wrong permissions (should be srwxrwxrwx). It's actually a bit simpler: v44 *did* already use /run/systemd/notify (with permissions srw-rw-rw-), then it was changed to use an abstract namespace and it was changed back and forth a couple of times. Maybe a simple chmod will do when upgrading from v44. Will test. Sjoerd, you mentioned in your bug report, that you upgraded from v208-v215 v208 uses an abstract socket though, so I'm not sure if it's actually the same issue. Did you maybe first upgrade from v44 to v208 and then did the dist-upgrade to v215? No pretty sure it was from v208 directly. I was just re-reading the code of upstream system again it it looks like upstream now removes the old socket file right before calling bind: f0e62e89970b8c38eb07a9beebd277ce13a5fcc2 We probably should backport that one, which should solve both issues. -- Fill what's empty, empty what's full, scratch where it itches. -- Alice Roosevelt Longworth -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770404: systemd: breaks lightdm, does not start anymore
On Mon, 2014-11-24 at 09:31 +0100, Didier Roche wrote: Le 21/11/2014 22:46, Sjoerd Simons a écrit : reassign 770404 lxdm thanks On Fri, Nov 21, 2014 at 08:01:50PM +, Simon McVittie wrote: This looks wrong. I think it might be caused by this in lxdm.service: [Install] Alias=display-manager.service Neither gdm3 nor lightdm have that, which suggests that it isn't meant to be necessary. I think what's happening is that when you install lxdm, that Alias directive causes the debhelper snippets in its postinst[1] to break the mechanism that is meant to arbitrate who owns display-manager.service: the part of its postinst headed # set default-display-manager systemd service link is correct, but then the #DEBHELPER# snippet runs systemctl enable lxdm which sees the Alias, obeys it, and overwrites the display-manager.service symlink with an incorrect target. Correct, that Alias= breaks our current mechanism for arbitrating the DM to use (that is, the sylink and the config file go out of sync). See also Martin pitt's comment for lightdm way back when: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733220#25 Actually, we revisited that with Martin and we can use Alias in relation to the correct postinst scripts to achieve this in a clean way. See the snippet I proposed on bug #764607. Adding Bigon and Joss to the CC for their GDM perspective ;) Interesting. Your postinst (patch from the bug you mentioned) seems a bit brute-force though (it tries to (re)enable the default display manager regardless of whether it, itself, is the default). But at least that means things stay in sync :p However I guess that still breaks things if the user enables a non-default DM by hand ? (iotw the DM gets enabled but will bail resulting in no DM being started if the user doesn't also update the etc file) -- Sjoerd Simons sjo...@luon.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#770404: systemd: breaks lightdm, does not start anymore
reassign 770404 lxdm thanks On Fri, Nov 21, 2014 at 08:01:50PM +, Simon McVittie wrote: This looks wrong. I think it might be caused by this in lxdm.service: [Install] Alias=display-manager.service Neither gdm3 nor lightdm have that, which suggests that it isn't meant to be necessary. I think what's happening is that when you install lxdm, that Alias directive causes the debhelper snippets in its postinst[1] to break the mechanism that is meant to arbitrate who owns display-manager.service: the part of its postinst headed # set default-display-manager systemd service link is correct, but then the #DEBHELPER# snippet runs systemctl enable lxdm which sees the Alias, obeys it, and overwrites the display-manager.service symlink with an incorrect target. Correct, that Alias= breaks our current mechanism for arbitrating the DM to use (that is, the sylink and the config file go out of sync). See also Martin pitt's comment for lightdm way back when: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733220#25 systemd maintainers: do you agree with my reasoning, and that that bit of lxdm.service is wrong? If so, please reassign this to lxdm (which is conveniently not a blocker for jessie, since it is only in unstable). reassigning :) -- All men know the utility of useful things; but they do not know the utility of futility. -- Chuang-tzu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766771: udev rules are reloaded on any event due to incomplete debian patch
Martin, I suspect this bug has been fixed due:
* Replace our Debian hwdb.bin location patch with what got committed
upstream. Run hwdb update with the new --usr option to keep current
behaviour.
Could you verify that ?
On Sun, Oct 26, 2014 at 03:52:16AM +1100, kittyofthebox wrote:
Package: udev
Version: 215-5+b1
Severity: important
Tags: patch
Hi,
Due to an incomplete debian patch udev rules are reloaded everytime an event
occurs
instead of only when udev rules change. After some dicussion in the
#debian-systemd
chat room this patch fixes the problem.
Kitty
-- Package-specific info:
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (750, 'testing'), (700, 'testing'), (650, 'stable'), (600,
'stable'), (450, 'oldstable'), (400, 'oldstable'), (300, 'unstable'), (200,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages udev depends on:
ii adduser3.113+nmu3
ii debconf [debconf-2.0] 1.5.53
ii libacl12.2.52-2
ii libblkid1 2.25.1-5
ii libc6 2.19-11
ii libkmod2 18-3
ii libselinux12.3-2
ii libudev1 215-5+b1
ii lsb-base 4.1+Debian13
ii procps 2:3.3.9-8
ii util-linux 2.25.1-5
udev recommends no packages.
udev suggests no packages.
--- a/src/libudev/libudev-hwdb.c
+++ b/src/libudev/libudev-hwdb.c
@@ -358,7 +358,7 @@ bool udev_hwdb_validate(struct udev_hwdb *hwdb) {
return false;
if (!hwdb-f)
return false;
-if (stat(/etc/udev/hwdb.bin, st) 0)
+if (stat(UDEVLIBEXECDIR /hwdb.bin, st) 0)
return true;
if (timespec_load(hwdb-st.st_mtim) != timespec_load(st.st_mtim))
return true;
--
Air pollution is really making us pay through the nose.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765870: systemd-logind brings system to knees with RAM consumption
Hey John, On Sun, Nov 09, 2014 at 06:13:30PM -0600, John Goerzen wrote: I will try this. It is a bit complicated because the system in question is also running ZFS and there are some bugs with that boot, but I think I have worked them out enough. It may take me a few days to find the time, however. Did you find the time to get this system booting with systemd? Would be great to further narrow it down. On 11/03/2014 08:43 PM, Michael Biebl wrote: Am 18.10.2014 um 21:49 schrieb John Goerzen: Package: systemd Version: 215-5+b1 Severity: grave Justification: renders package unusable On investigating why my 8GB system, which was suddenly running extremely slow and maxed out on swap, I discovered numerous systemd-logind processes hogging RAM. Specifically, 41 processes using 4278148KB (or roughly 4GB) of RAM. Here is some output from top: As John told me on IRC: He is running systemd-logind under systemd-shim on this particular system. On other systems, where systemd is PID 1 he does not experience this issue. I told him to find out the current running systemd-logind process which owns the org.freedesktop.login1 D-Bus name via dbus-send --system --dest=org.freedesktop.DBus --print-reply /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID string:org.freedesktop.login1 and monitor that process via strace while periodically checking with the above command, when logind drops off the bus. So we can eventually see from the strace what happens at that time. Unfortunately, when stracing the process, John is no longer able to reproduce the issue, as he told on IRC. John, to narrow down the problem, could you please boot with init=/bin/systemd to verify if this issue is indeed related to systemd-shim. -- After an instrument has been assembled, extra components will be found on the bench. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769069: systemd: Failed to start Login Service
On Sat, Nov 15, 2014 at 01:16:36AM +0100, Paul Menzel wrote: Am Freitag, den 14.11.2014, 10:18 + schrieb Simon McVittie: signal 15, shutting down normally. Nov 11 07:46:16 asrock-e350m1 avahi-daemon[929]: Got SIGTERM, quitting. ... Nov 11 07:46:52 asrock-e350m1 NetworkManager[942]: info startup complete Nov 11 07:46:52 asrock-e350m1 NetworkManager[942]: info exiting (success) Any idea why these might have happened? They both use libdbus, so getting disconnected from D-Bus with exit-on-disconnect enabled would cause an _exit(1) rather than the raise(SIGTERM) you'd get from GDBus. It looks vaguely as though *everything* on the system bus might have been failing to connect to it? Did you / do you have any unusual systemd or dbus configuration in use? Not that I know of. I am using the packaged configuration. Yes this indeed looks like nothing can connect to the systemd bus. If you can't reproduce this, then I don't think we'll be able to work out what is going on from that log, sorry. It happened again, but I forgot to add the systemd debug stuff. It stopped for a while after the start message of D-Bus and then continued until the point where the “Logind failed to start” messages were shown. One thing stood out: Nov 14 23:39:05 asrock-e350m1 systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway. The dbus system socket is in unix:path=/var/run/dbus/system_bus_socket. So one possible explanation might be that your just mounted a file system over the /var/run dbus got its socket put in.. In principle this should not occur, but lets first work out if my theory is correct. Could you: 0: Check where your final /var/run/ is pointing to (should a symlink to /run) 1: If it isn't a symlink, can you check whats in both the /var/run of your /var partition *and* the var of your / partition (to see if you masked out the dbus socket in any way) -- When you know absolutely nothing about the topic, make your forecast by asking a carefully selected probability sample of 300 others who don't know the answer either. -- Edgar R. Fiedler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
