Bug#1070832: option to add an RFC822 apt source
Package: debootstrap Version: 1.0.128+nmu2+deb12u1 Severity: wishlist X-Debbugs-Cc: s...@debian.org Hi, it would be nice to allow specifying RFC822-style apt sources from local files, both as a main mirror and as additional package sources. For example, I have a local mirror that uses a different signing key (because I import packages from Debian, and add a few of my own), and I'd like to debootstrap using debootstrap bookworm /tmp/bookworm my-mirror.sources which would provide both the URL and the signing key to verify. In the same vein, I have a few extra packages that use regular Debian as a base, but have additional build dependencies that are also only in my repository, for those I'd like to use something like debootstrap --othermirror my-packages.sources bookworm /tmp/bookworm And, last but not least, I sometimes need to combine these. In either case, the signing key for that source is provided inline in the .sources file. Simon -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debootstrap depends on: ii wget 1.21.3-1+b2 Versions of packages debootstrap recommends: ii arch-test 0.20-1 ii debian-archive-keyring 2023.3+deb12u1 ii gnupg 2.2.40-1.1 Versions of packages debootstrap suggests: ii binutils2.40-2 pn squid-deb-proxy-client pn ubuntu-archive-keyring ii xz-utils5.4.1-0.2 ii zstd1.5.4+dfsg2-5 -- no debconf information
Bug#1068505: RFH: reprepro -- Move experimental multi-version feature to unstable
Hi, On 4/6/24 22:22, Bastian Germann wrote: As many in the Debian world depend on reprepro to manage their repositories, I would like to ask for help because I did not have the capacity in the last two years (and probably not in the remaining year to come during the trixy cycle) to give those bugs the attention that they deserve. I don't have the capacity either, but I have added it to my list of things I should be looking into. Simon
Bug#1065482: dselect-upgrade does not convert pre-depends on virtual package to automatic installation
Package: apt Version: 2.6.1 Severity: minor X-Debbugs-Cc: s...@debian.org Hi, testing in docker: $ docker run --rm -it debian root@239c2646db6b:/# apt-get update Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB] Get:2 http://deb.debian.org/debian bookworm-updates InRelease [55.4 kB] Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0 kB] Get:4 http://deb.debian.org/debian bookworm/main amd64 Packages [8786 kB] Get:5 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [12.7 kB] Get:6 http://deb.debian.org/debian-security bookworm-security/main amd64 Packages [144 kB] Fetched 9197 kB in 1s (8973 kB/s) Reading package lists... Done root@239c2646db6b:/# apt-cache dumpavail | dpkg --update-avail Replacing available packages info, using -. Information about 63465 packages was updated. root@239c2646db6b:/# dpkg --clear-selections root@239c2646db6b:/# dpkg --set-selections < apt install > e2fsprogs install > tzdata install > mount install > usr-is-merged install > EOF root@239c2646db6b:/# apt-get dselect-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages have unmet dependencies: base-files : PreDepends: awk E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. E: Internal error, problem resolver broke stuff If I add "mawk install" to the list, the dselect-upgrade becomes a no-op, and all packages (including mawk) are marked as automatically installed. If I add "vim install" to the list, vim and its dependencies are installed in addition, and vim is the only package marked manually installed. This is very close to the desired behaviour, where I'd like to specify as few packages as possible in the dpkg selection, and have apt find a valid solution that has as many packages marked auto-installed as possible. Since mawk is already installed at this point, the PreDepends should also behave like a normal Depends, and simply pull in the existing package that provides awk (and ideally keep the behaviour where awk is marked auto-installed, since it is not explicitly requested). Presumably, the auto flag on mawk is deduced because it is pulled in by an essential package, that makes sense and should probably stay that way. Simon -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.134 ii debian-archive-keyring 2023.3+deb12u1 ii gpgv2.2.40-1.1 ii libapt-pkg6.0 2.6.1 ii libc6 2.36-9+deb12u4 ii libgcc-s1 12.2.0-14 ii libgnutls30 3.7.9-2+deb12u2 ii libseccomp2 2.5.4-1+b3 ii libstdc++6 12.2.0-14 ii libsystemd0 252.22-1~deb12u1 Versions of packages apt recommends: ii ca-certificates 20230311 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.13-5 ii dpkg-dev1.21.22 ii gnupg 2.2.40-1.1 pn powermgmt-base -- no debconf information
Bug#1064969: apt: can't upgrade with aptitude
Hi,
On 2/28/24 23:49, Vincent Lefevre wrote:
# aptitude install apt
The following packages will be upgraded:
apt{b} apt-doc
2 packages upgraded, 0 newly installed, 0 to remove and 180 not upgraded.
Need to get 1622 kB of archives. After unpacking 0 B will be used.
The following packages have unmet dependencies:
apt : Depends: libapt-pkg6.0t64 (>= 2.7.12+nmu1) but it is not going to be
installed
apt-utils : Depends: apt (= 2.7.12) but 2.7.12+nmu1 is to be installed
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) apt [2.7.12 (now, testing)]
That is a valid possible resolution. Presumably, if you reject this
resolution, it will instead propose to upgrade apt-utils, install
libapt-pkg6.0t64 and remove libapt-pkg6.0.
Since that is a larger change, the conservative proposal comes first.
apt-utils has a versioned dependency on apt, which means upgrading apt
alone (which you requested) breaks another "unrelated" package. There
has been some debate that resolvers should favour upgrading all binaries
that are built from the same source together, but that has not been
implemented yet, and it is unclear if that would have changed anything here.
So, I suppose that this is also the case for aptitude: if aptitude
cannot upgrade just because of a rename, then this is a problem in
the involved packages.
Note that you haven't requested an "upgrade" (which would likely have
worked, because it would have switched both apt and apt-utils to the new
version, and the remaining involved packages were automatically
installed as dependencies of the packages being upgraded).
Simon
Bug#1035707: command to (re)sign currently installed modules
Hi, On 12/6/23 07:11, Andreas Beckmann wrote: it would be cool to have a command to run all installed modules through the signing process again, for example after changes to the MOK, or simply because the signing key was unavailable during installation of a module. Would it be sufficient if dpkg-reconfigure linux-headers-6.5.0-5-amd64 would rebuild, resign and reinstall all dkms modules currently installed for linux-image-6.5.0-5-amd64? For the most part, "dpkg-reconfigure linux-image-6.5.0-5-amd64" already works, but it'd be great to have a front-end command in dkms directly, because that's something easy to tell users. There are a few problems with the current implementation: - if the MOK is passphrase protected, and the passphrase is unavailable, installation succeeds and is never reattempted, even though the resulting modules cannot be loaded. - to understand when the passphrase is needed, you need to understand how the kernel works, so it's not something easily explained to end users. - the only "safe" approach is to always provide the passphrase for every apt invocation, which is 面倒くさい. Having a single entry point for "I am not sure all modules are properly signed with the current MOK, please fix" would be great, because it can at least provide a path to repairing an installation that doesn't require users to find out which kernel they are running. Longer term, we probably also need a mechanism to know *before* an action whether the MOK is going to be needed, and a fallback if it is not available -- a dbus interface to interactively ask on-demand would solve the problem for desktop users, but is likely difficult to use for server operation. In either case if the passphrase is unavailable at this point, the system might be in a state that the user cannot easily recover from if they were to reboot now. This is made worse by the nV drivers that occasionally kill the X server during upgrades, so we're losing the user session at this point. None of these can be fixed without larger changes though -- hence a "limited scope" wishlist bug for a "dkms sign" or similar command that will go through all installed modules (for all kernels) and make sure they have a signature with the currently installed MOK. It would also be nice to have a line in the post-installation summary report and/or a command that indicates via exit status if rebooting is currently safe. Simon
Bug#1015871: Enabling PCI_P2PDMA for distro kernels?
Hi, On 10/26/23 02:11, Lukas Wunner wrote: This has recently been brought up internally at Intel and nobody could understand why there's a whitelist in the first place. A long-time PCI architect told me that Intel silicon validation has been testing P2PDMA at least since the Lindenhurst days, i.e. since 2005. My PCIe test box generates URE completions in the root complex when I try to address iGPU BARs from an FPGA, and texture fetches from the iGPU that use BAR addresses on the FPGA do not get forwarded (so I venture that is an URE as well). CPU: i3-3225 CPU @ 3.30GHz (fam: 06, model: 3a, stepping: 09) pci :00:00.0: [8086:0150] type 00 class 0x06 pci :00:01.0: [8086:0151] type 01 class 0x060400 pci :00:02.0: [8086:0162] type 00 class 0x03 pci :00:14.0: [8086:1e31] type 00 class 0x0c0330 pci :00:16.0: [8086:1e3a] type 00 class 0x078000 pci :00:1a.0: [8086:1e2d] type 00 class 0x0c0320 pci :00:1b.0: [8086:1e20] type 00 class 0x040300 pci :00:1c.0: [8086:1e10] type 01 class 0x060400 pci :00:1c.4: [8086:1e18] type 01 class 0x060400 pci :00:1d.0: [8086:1e26] type 00 class 0x0c0320 pci :00:1f.0: [8086:1e4a] type 00 class 0x060100 pci :00:1f.2: [8086:1e00] type 00 class 0x01018f pci :00:1f.3: [8086:1e22] type 00 class 0x0c0500 pci :00:1f.5: [8086:1e08] type 00 class 0x010185 pci :01:00.0: [1172:1337] type 00 class 0xff pci :03:00.0: [10ec:8168] type 00 class 0x02 So there is at least one configuration that doesn't work. :P Simon
Bug#1015871: Please enable CONFIG_PCI_P2PDMA
Hi, On 10/25/23 03:29, Emanuele Rocca wrote: I hesitate to actually enable it because I don't understand PCI good enough to judge it's a safe choice for the Debian kernel. There is a kernel API for "return the physical address of a BAR mapping on another PCI device, as seen from the point of view of this device." With the P2PDMA option disabled, that API always returns "no peer-to-peer capable path exists", which requires drivers to fall back to allocating a buffer. If the option is enabled, a driver exporting a DMA buffer (such as a video capture device or a GPU) can provide an address that is part of one of its BAR mappings. The driver importing the DMA buffer will then use the physical address it was given in DMA requests, which routes the requests directly and avoids passing through the root complex. I have successfully used this to make an nVidia GPU generate PCIe requests for textures that were answered by an FPGA card. :> The driver importing the buffer needs no special support. There is no generic mechanism to use peer-to-peer transfers if not at least one side is aware of that mechanism, as it essentially requires the exporting device to implement full support for prefetchable BAR mappings. Im principle, all platforms that support PCIe can benefit from this, as it allows peer-to-peer transfers even when the root complex does not support this, as long as all bridges on the path between the involved devices do. In practice, most transfers will happen between a GPU (in a slot directly connected to a root bridge) and some data capture device, so the benefit on platforms other than amd64 and ppc64le will be limited -- although these will just fall back to the current behaviour, and the only code paths affected are slow paths that usually end in TLB flushes for CPU and IO MMUs. Simon
Bug#1053551: ftbfs on amd64 when building binary-arch
Hi, On 13.10.23 18:55, Simon Richter wrote: There are a few dependency rules in the file that seem to do the same thing, but use the wrong target name, so they are ignored, and this doesn't seem to be a complete set anyway. I'm trying with the same addition of an order-only dependency that the gcc-13 commit does, if that fixes it, that should be good enough for now. Okay, further debugging: The Modula2 tree uses $(generated_files) as a dependency to make sure the insn-*.h are generated before frontend files are built. This variable is set below the include directive in gcc/Makefile that pulls in the language fragments, so at the point where the rules are defined it is still empty, and since rule definitions evaluate the variables immediately, that is not revisited later, so all the Modula2 .o files are missing those dependencies. I'm trying what happens if you set M2_OBJS = $(GM2_OBJS), so these .o files end up a) in normal dependency tracking, and b) to add the order-only dependency on $(generated_files) at the end of gcc/Makefiles to those objects as well. The order-only dependency should be enough for the first build, and after that, normal dependency tracking takes over anyway, not that anyone cares. Am I right in assuming that this is only a Debian problem because no one but us is gluing the M2 frontend onto gcc 12 anymore? Simon OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1053551: ftbfs on amd64 when building binary-arch
Hi, On 10/13/23 03:03, Simon Richter wrote: makes the problem reproducible even when building with -j2, and regardless of whether building _all packages in the same build or not. I'll check tomorrow about gcc 13 and if that also happens upstream. gcc 13 is okay, because of 0bfc503c [1]. This patch does not apply cleanly to gcc-12, because gm2 is a separate archive there, and the file looks a bit different. There are a few dependency rules in the file that seem to do the same thing, but use the wrong target name, so they are ignored, and this doesn't seem to be a complete set anyway. I'm trying with the same addition of an order-only dependency that the gcc-13 commit does, if that fixes it, that should be good enough for now. Is the separate Modula2 tree still maintained? For us, the one-line fix should probably be sufficient, but from an upstream perspective, this should be looked at properly (but might be moot after the merge into gcc-13). Simon [1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=00bfc503cc3b3e8f354afeac9b482649418fb70f
Bug#1053551: ftbfs on amd64 when building binary-arch
Hi, On 10/12/23 19:14, Simon Richter wrote: I cannot reproduce this, and I would rather not investigate time into that. Please check if you see this with gcc-13 as well. I suspect it's a missing dependency, so the failure is more dependent on "number of threads", and that it succeeds for -b might be coincidence. I'll try adding a sleep statement to the rule generating this file and see if I can get it to reproduce always. Confirmed: --- a/src/gcc/Makefile.in.orig 2023-10-12 12:20:46.349633453 +0200 +++ b/src/gcc/Makefile.in 2023-10-12 12:21:08.087623131 +0200 @@ -2431,6 +2431,7 @@ $(simple_generated_h:insn-%.h=s-%): s-%: build/gen%$(build_exeext) $(RUN_GEN) build/gen$*$(build_exeext) $(md_file) \ $(filter insn-conditions.md,$^) > tmp-$*.h + if test "$*" = "attr-common"; then sleep 300; fi $(SHELL) $(srcdir)/../move-if-change tmp-$*.h insn-$*.h $(STAMP) s-$* makes the problem reproducible even when building with -j2, and regardless of whether building _all packages in the same build or not. I'll check tomorrow about gcc 13 and if that also happens upstream. Simon
Bug#1053551: ftbfs on amd64 when building binary-arch
Hi, On 10/12/23 15:17, Matthias Klose wrote: I cannot reproduce this, and I would rather not investigate time into that. Please check if you see this with gcc-13 as well. I suspect it's a missing dependency, so the failure is more dependent on "number of threads", and that it succeeds for -b might be coincidence. I'll try adding a sleep statement to the rule generating this file and see if I can get it to reproduce always. Simon
Bug#1053519: Fix available upstream
Hi, this bug is known upstream, and a patch already exists. Would it be possible to apply this so ghdl can be compiled on arm64? Simon
Bug#1053553: please remove me from Uploaders
Package: clinfo Version: 3.0.23.01.25-1 Severity: wishlist X-Debbugs-Cc: s...@debian.org Hi, as the last copy of the clinfo program that I wrote years ago has left the archive and I've not been involved with packaging the replacement, I think there is no good reason for me to stay on the Uploaders list. Simon -- Package-specific info: Installed ICDs: /etc/OpenCL/vendors/: total 4 -rw-r--r-- 1 root root 22 Mar 29 2023 nvidia.icd -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages clinfo depends on: ii libc62.36-9+deb12u3 ii ocl-icd-libopencl1 [libopencl1] 2.3.1-1 clinfo recommends no packages. clinfo suggests no packages. Versions of packages clinfo is related to: ii nvidia-opencl-icd [opencl-icd] 525.125.06-1~deb12u1 -- no debconf information
Bug#1053551: ftbfs on amd64 when building binary-arch
Package: gcc-12 Version: 12.3.0-9 Severity: normal Tags: ftbfs X-Debbugs-Cc: s...@debian.org Hi, I just built arch:all and arch:amd64 packages separately in pbuilder, and got a reproducible build failure while building amd64 with --binary-arch. Normal severity because building both arch-dependent and arch-independent packages together works fine. /build/gcc-12-12.3.0/build/./prev-gcc/xg++ -B/build/gcc-12-12.3.0/build/./prev-gcc/ -B/usr/x86_64-linux-gnu/bin/ -nostdinc++ -B/build/gc c-12-12.3.0/build/prev-x86_64-linux-gnu/libstdc++-v3/src/.libs -B/build/gcc-12-12.3.0/build/prev-x86_64-linux-gnu/libstdc++-v3/libsupc++ /.libs -I/build/gcc-12-12.3.0/build/prev-x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu -I/build/gcc-12-12.3.0/build/prev-x86_ 64-linux-gnu/libstdc++-v3/include -I/build/gcc-12-12.3.0/src/libstdc++-v3/libsupc++ -L/build/gcc-12-12.3.0/build/prev-x86_64-linux-gnu/ libstdc++-v3/src/.libs -L/build/gcc-12-12.3.0/build/prev-x86_64-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -g -O2 -fno-che cking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -DHAVE_CONFIG_H -I. -Im2/gm2-gcc -I../../src/gcc -I../../src/gcc/m2/gm2-gcc -I../../src/gcc/../include -I../../src/gcc/../libcpp/inclu de -I../../src/gcc/../libcody -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/bid -I../libdecnumber -I../../src/gcc/../ libbacktrace -I. -Im2/gm2-gcc -I../../src/gcc -I../../src/gcc/m2/gm2-gcc -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libcody -I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/bid -I../libdecnumber -I../../src/gcc/../lib backtrace ../../src/gcc/m2/gm2-gcc/m2type.cc -o m2/gm2-gcc/m2type.o [...] In file included from ./tm.h:26, from ../../src/gcc/backend.h:28, from ../../src/gcc/m2/gm2-gcc/gcc-consolidation.h:26, from ../../src/gcc/m2/gm2-gcc/m2type.cc:22: ../../src/gcc/config/i386/i386.h:2374:10: fatal error: insn-attr-common.h: No such file or directory 2374 | #include "insn-attr-common.h" | ^~~~ compilation terminated. A lot of the other M2 sources are also affected. Simon -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gcc-12 depends on: ii binutils 2.40-2 ii cpp-12 12.2.0-14 ii gcc-12-base12.2.0-14 ii libc6 2.36-9+deb12u3 ii libcc1-0 12.2.0-14 ii libgcc-12-dev 12.2.0-14 ii libgcc-s1 12.2.0-14 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libisl23 0.25-1 ii libmpc31.3.1-1 ii libmpfr6 4.2.0-1 ii libstdc++6 12.2.0-14 ii libzstd1 1.5.4+dfsg2-5 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages gcc-12 recommends: ii libc6-dev 2.36-9+deb12u3 Versions of packages gcc-12 suggests: pn gcc-12-doc pn gcc-12-locales pn gcc-12-multilib -- no debconf information
Bug#1053519: gcc-12: ICE when compiling ghdl 3.0.0 on arm64
Package: gcc-12 Version: 12.3.0-9 Severity: normal Tags: upstream Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111704 X-Debbugs-Cc: s...@debian.org Control: affects -1 = ghdl -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, GHDL steps on an ICE while compiling GHDL 3.0.0 on arm64: aarch64-linux-gnu-gcc-12 -c -I./ -I../../src -I../../src/vhdl -I../../src/synth -I../../src/grt -I../../src/psl -I../../src/vhdl/translate -I../../src/ghdldrv -I../../src/ortho -I../../src/ortho/llvm6 -I../../src/synth -I../../src/ghdldrv -gnat12 -gnaty3befhkmr -g -gnatwa -gnatwC -gnatf -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -mbranch-protection=standard -gno-record-gcc-switches -gnata -I- /<>/src/synth/synth-disp_vhdl.adb /<>/src/ghdldrv/ghdldrv.adb: In function ‘Ghdldrv.Gen_Makefile’: /<>/src/ghdldrv/ghdldrv.adb:2022:8: error: unrecognizable insn: (insn 1387 147 204 13 (parallel [ (set (mem/c:SI (plus:DI (reg/f:DI 29 x29) (const_int -260 [0xfefc])) [36 files_it+4 S4 A32]) (reg:SI 2 x2 [244])) (set (mem/c:SI (plus:DI (reg/f:DI 29 x29) (const_int -256 [0xff00])) [36 files_it+8 S4 A64]) (reg:SI 1 x1 [604])) ]) "/<>/src/ghdldrv/ghdldrv.adb":1926:19 -1 (expr_list:REG_DEAD (reg:SI 2 x2 [244]) (expr_list:REG_DEAD (reg:SI 1 x1 [604]) (nil during RTL pass: cprop_hardreg Full build log is at https://buildd.debian.org/status/fetch.php?pkg=ghdl=arm64=3.0.0%2Bdfsg2-1=1696130520=0 I have already reported this to the GCC Bugzilla. Simon - -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages gcc-12 depends on: ii binutils 2.40-2 ii cpp-12 12.2.0-14 ii gcc-12-base12.2.0-14 ii libc6 2.36-9+deb12u3 ii libcc1-0 12.2.0-14 ii libgcc-12-dev 12.2.0-14 ii libgcc-s1 12.2.0-14 ii libgmp10 2:6.2.1+dfsg1-1.1 ii libisl23 0.25-1 ii libmpc31.3.1-1 ii libmpfr6 4.2.0-1 ii libstdc++6 12.2.0-14 ii libzstd1 1.5.4+dfsg2-5 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages gcc-12 recommends: ii libc6-dev 2.36-9+deb12u3 Versions of packages gcc-12 suggests: pn gcc-12-doc pn gcc-12-locales pn gcc-12-multilib - -- no debconf information -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmUexsEACgkQfr04e7CZ CBHkYggArUJUHU/RlpTocoJ13EqLsENnfQGVlLuwcyX1lSEZRA06WGZk4HXa8Q85 V6TZNDtY1wjUdMQq/AWGPxyXJH/KqZRXHyx95L1fh7LY6BiI52/uajkzTQm0+V9M HgUMDM2XrH23ocFNU/91vNmH4RH0bjYaV215ES4XHt+RV+YJpjjo9zFmjCYy99O/ PYFdq3XkIDKgNrFc7aN4hdPf94Xx0dFRZQ0JUA9X+y3Bzx5OIH7yUZkGEP4zrhv5 twIKAN0rdI6t89CCW/WhtIDaP2CYfraiB+vdMBtGdaOKCE09D8dVjpHB85CFqYyy /MD/PclgY7KNaQvGj4fdk6AgWEIFPg== =ijpm -END PGP SIGNATURE-
Bug#1052598: RFA: sisl -- SINTEF Spline Library
Package: wnpp Severity: normal X-Debbugs-Cc: s...@packages.debian.org, s...@debian.org Control: affects -1 + src:sisl Hi, I packaged the SINTEF Spline Library a while ago because a prerelease version of KiCad depended on it. Since none of the release versions did, this package is probably not used by many people. That said, it also hasn't had any new upstream releases in ten years, so both users (popcon count: 2) are probably fine with the situation as it is. If there is someone who actively uses this package, and wants to become maintainer, I'd be happy to hand it over. The package description is: The SINTEF Spline Library is a comprehensive NURBS library for the modeling and interrogation of curves and surfaces. . It is implemented in C and has been under continuous development for over two decades. Simon
Bug#1052464: x11-apps: [xwd] cannot capture Steam windows
Package: x11-apps Version: 7.7+9 Severity: normal Tags: upstream Hi, Using xwd -out steam.xwd and clicking on any window opened by Steam gives X Error of failed request: BadColor (invalid Colormap parameter) Major opcode of failed request: 91 (X_QueryColors) Resource id in failed request: 0x0 Serial number of failed request: 271 Current serial number in output stream: 271 The resulting file is empty. This also happens when -icmap is specified. Simon -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages x11-apps depends on: ii libc62.36-9+deb12u1 ii libpng16-16 1.6.39-2 ii libsm6 2:1.2.3-1 ii libx11-6 2:1.8.4-2+deb12u1 ii libx11-xcb1 2:1.8.4-2+deb12u1 ii libxaw7 2:1.0.14-1 ii libxcb-damage0 1.15-1 ii libxcb-present0 1.15-1 ii libxcb-xfixes0 1.15-1 ii libxcb1 1.15-1 ii libxcursor1 1:1.2.1-1 ii libxext6 2:1.3.4-1+b1 ii libxft2 2.3.6-1 ii libxi6 2:1.8-1+b1 ii libxkbfile1 1:1.1.0-1 ii libxmu6 2:1.1.3-3 ii libxmuu1 2:1.1.3-3 ii libxrender1 1:0.9.10-1.1 ii libxt6 1:1.2.1-1.1 ii man-db 2.11.2-2 Versions of packages x11-apps recommends: ii xbitmaps 1.1.1-2.2 Versions of packages x11-apps suggests: ii mesa-utils 8.5.0-1 -- no debconf information
Bug#1052046: RM: Time to remove from unstable too?
Hi, On 9/17/23 00:04, Ben Tris wrote: Package: mutextrace This package was removed from testing in 2016. No vcs or website to be found. Clear "maybe." The main reason it's not in testing is that the test suite fails in exactly 5% of cases, a phenomenon I have been unable to explain so far. Other than that, it could still be a useful tool. I guess I'll have a topic for a weekend hacking session. Simon
Bug#910377: System-critical package management
Hi,
On 18.09.23 19:38, Julian Andres Klode wrote:
I'm not sure how that works because you'd need to respawn yourself
with systemd-inhibit, whereas the API essentially gives you a file
descriptor over dbus that you keep open until it is safe to reboot.
popen("systemd-inhibit ... cat", "w");
should work.
Simon
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1037506: Bug#1037306: ITP: apycula -- Tools to generate Gowin FPGA bitstreams
Hi Daniel, On 06.09.23 17:50, Daniel Gröber wrote: I've pushed apycula 0.9.0 to https://salsa.debian.org/electronics-team/apycula/ FYI: prjtrellis is also waiting for another upload to appease ftp-master review https://salsa.debian.org/electronics-team/prjtrellis/ I've uploaded both, and made a test build with nextpnr as well, seems good. Simon OpenPGP_signature Description: OpenPGP digital signature
Bug#1037506: Bug#1037306: ITP: apycula -- Tools to generate Gowin FPGA bitstreams
Hi Daniel, On 9/6/23 17:50, Daniel Gröber wrote: I've pushed apycula 0.9.0 to https://salsa.debian.org/electronics-team/apycula/ This will have to wait until the weekend, I'm fairly busy at work. Simon
Bug#1037306: ITP: apycula -- Tools to generate Gowin FPGA bitstreams
Hi Daniel, On 7/25/23 22:53, Daniel Gröber wrote: FYI: It seems you didn't do a source-only upload for apycula so it's BLOCKED from migrating to testing now. We have to do another source-only upload to get it unstuck. Yes, known problem. I dimly remember that NEW uploads require binaries for some reason. Also a reminder on pushing the tags if you could: Right, I'll have to learn how to do that, I seldom use git-buildpackage, and I verify packages by building them in pbuilder. Hopefully I can get around to that tonight when I get home. Did you make any changes either of the the packages? If so don't forget to commit and push to salsa please. You should have push access to electronics-team, right? No changes, IIRC. I'm not sure if I have push access, I will have to check at home. BTW, I have ghdl 3.0.0 packages at https://deb.simonrichter.eu/ and am successfully using the ghdl yosys plugin with those, this might be another goal for the next months. Simon
Bug#1037306: ITP: apycula -- Tools to generate Gowin FPGA bitstreams
Hi, On 11.06.23 06:03, Daniel Gröber wrote: We need this to enable nextpnr support for Gowin FPGAs in Debian. I'm intending to maintain this within the Debian Electronics Team like the similar fpga-icestorm package. I'd be interested in sponsoring nextpnr related packages. Simon OpenPGP_signature Description: OpenPGP digital signature
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi, On 5/12/23 02:51, Luca Boccassi wrote: Or alternatively, we can establish that a documentation/post-facto approach is enough for derivatives, and then that's valid for all changes and transitions. For the context of this bug, the notice *is* the after-the-fact documentation of an interface change, i.e. the bare minimum. It would have been better to get input from derived distributions about this interface change before it happened, but given that the interface change was not caused by a change in dpkg code, but by the introduction of the usrmerge package, there was not much of a remedy available then. Simon
Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Hi, On 5/11/23 10:59, Sean Whitton wrote: Dear ctte, please consider overruling the dpkg maintainer to include the patch from #994388[1]. Currently dpkg contains code to emit the merged-/usr warning, that's dead code on Debian, but which becomes active when packages from the Debian archive are copied unmodified into derivatives. The way I see it (but I'm not a dpkg maintainer), the current implementation is correct, as dpkg does not support aliased directories, but Debian has decided to use it in such an environment nonetheless. The tech-ctte decision not to roll back usrmerge accepts responsibility for this decision, so silencing the warning on Debian is correct, but no one has accepted that responsibility for derived distributions. Any derived distribution can easily go on record and request inclusion in the list of distributions where this warning is suppressed, by typing the phrase "Yes, I understand that this is a bad idea." into an email client. dpkg has an upstream existence that's independent of Debian, and it's perfectly legitimate for that version of dpkg to emit the warning. The problem here might be caused by how the Debian archive is implicitly being used to distribute upstream dpkg. I'm skeptical about splitting development and packaging, though, especially in this context, because we'd need to clarify how far we'd want upstream dpkg and Debian dpkg to deviate. Basically, non-native dpkg has two scenarios: either it is maintained by the same people as now, which causes them extra work for no clear benefit, or we find maintainers willing to deal with complex bug reports that upstream is fully entitled to reject because Debian brought this onto themselves by deciding that one upstream project's "unsupported configuration" needs to be avoided by moving to another upstream project's "unsupported configuration." Those same people who would volunteer to maintain such a package could spend their energy finding a solution that can be merged into "upstream" dpkg, that would be more productive. Simon
Bug#1035707: command to (re)sign currently installed modules
Package: dkms Version: 3.0.10-8 Severity: wishlist X-Debbugs-Cc: s...@debian.org Hi, it would be cool to have a command to run all installed modules through the signing process again, for example after changes to the MOK, or simply because the signing key was unavailable during installation of a module. Simon -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages dkms depends on: ii build-essential 12.9 ii dpkg-dev 1.21.21 ii gcc [c-compiler] 4:12.2.0-3 ii gcc-12 [c-compiler] 12.2.0-14 ii kmod 30+20221128-1 ii lsb-release 12.0-1 ii make 4.3-4.1 ii patch2.7.6-7 Versions of packages dkms recommends: ii fakeroot 1.31-1.2 ii linux-headers-amd64 [linux-headers-generic] 6.1.20-2 ii sudo 1.9.13p3-1 Versions of packages dkms suggests: ii e2fsprogs 1.47.0-2 ii menu 2.1.49 -- Configuration Files: /etc/dkms/framework.conf changed [not included] -- no debconf information
Bug#1035338: please split off API client
Package: docker.io Version: 20.10.24+dfsg1-1+b2 Severity: wishlist X-Debbugs-Cc: s...@debian.org Hi, I have several containers that are allowed to address the docker instance they are running on to start additional containers, without ever having a need to run the docker daemon themselves. Since Docker has quite an extensive list of dependencies, it would be nice if the client could be installed separately. Simon -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages docker.io depends on: ii adduser3.132 ii containerd 1.6.20~ds1-1+b1 ii init-system-helpers1.65.2 ii iptables 1.8.9-2 ii libc6 2.36-9 ii libdevmapper1.02.1 2:1.02.185-2 ii libelogind0 [libsystemd0] 246.10-1debian1 ii runc 1.1.5+ds1-1+b1 ii sysvinit-utils [lsb-base] 3.06-4 ii tini 0.19.0-1 Versions of packages docker.io recommends: ii apparmor 3.0.8-3 ii ca-certificates 20230311 ii cgroupfs-mount 1.4 ii git 1:2.39.2-1.1 ii needrestart 3.6-3 ii xz-utils 5.4.1-0.2 Versions of packages docker.io suggests: pn aufs-tools pn btrfs-progs pn debootstrap pn docker-doc ii e2fsprogs 1.47.0-2 pn rinse pn rootlesskit pn xfsprogs pn zfs-fuse | zfsutils-linux -- no debconf information
Bug#1034904: ImportError: cannot import name 'util' from 'distutils' (/usr/lib/python3.11/distutils/__init__.py)
Package: diffuse Version: 0.7.7-1 Severity: normal X-Debbugs-Cc: s...@debian.org Hi, diffuse fails to start for me, with Traceback (most recent call last): File "/usr/bin/diffuse", line 36, in from diffuse import main File "/usr/share/diffuse/diffuse/main.py", line 33, in from diffuse import utils File "/usr/share/diffuse/diffuse/utils.py", line 32, in from diffuse.resources import theResources File "/usr/share/diffuse/diffuse/resources.py", line 33, in from distutils import util ImportError: cannot import name 'util' from 'distutils' (/usr/lib/python3.11/distutils/__init__.py) There might be an incompatibility with Python 3.11. Simon -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/20 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages diffuse depends on: ii gir1.2-gtk-3.03.24.37-2 ii gnome-icon-theme 3.12.0-5 ii python3 3.11.2-1+b1 ii python3-gi3.42.2-3+b1 ii python3-gi-cairo 3.42.2-3+b1 diffuse recommends no packages. Versions of packages diffuse suggests: pn desktop-file-utils -- no debconf information
Bug#1031256: decrementing 2**64 gives wrong result
Package: vim Version: 2:9.0.1000-4 Severity: minor Tags: upstream X-Debbugs-Cc: s...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, if I have the value 18446744073709551616 in a file and decrement it using Ctrl-X, I get 18446744073709551614. Verified to happen with both 8.2.2434 and 9.0.1000, and without any rc files. Simon - -- Package-specific info: - --- real paths of main Vim binaries --- /usr/bin/vi is /usr/bin/vim.basic /usr/bin/vim is /usr/bin/vim.basic - -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'stable-debug'), (500, 'proposed-updates-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages vim depends on: ii libacl1 2.2.53-10 ii libc62.31-13+deb11u5 ii libgpm2 1.20.7-8 ii libselinux1 3.1-3 ii libtinfo66.2+20201114-2 ii vim-common 2:8.2.2434-3+deb11u1 ii vim-runtime 2:8.2.2434-3+deb11u1 vim recommends no packages. Versions of packages vim suggests: ii exuberant-ctags [ctags] 1:5.9~svn20110310-14 pn vim-doc pn vim-scripts - -- no debconf information -BEGIN PGP SIGNATURE- iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmPrCV0PHHNqckBkZWJp YW4ub3JnAAoJEH69OHuwmQgRDuMH/iKmPb2FduVwcYEiS273hn0c/Iawx58I5DFK wf/4X8KxsI+at27Gv9mxGfT9S635tMCllvWKaCuPNCxzBd4PMqUgud+e8f78hIs1 t+VK9aOF/Bv5jHCCjKqHKSQgaof4a8/oRwSwGBeYGxSDLchVuU5Md6N5mB9L7sLU 9eHAyc/4cqGd+V2KZawtQGzF6eX3CyHxavvs4aXiJhLPVdRnnPGYpWHTFTiBygzp gBc2LYgaSc8aFe7N5y+apauZ83KiSiPutkPA/Y6xVwuLIJYUXxYag0y5DIEMb5UW O3mo4hjvFeZbiYlj+KeULw3N9Tfrg3jxW6Ecr5SUgcn1bQlo6+E= =N89d -END PGP SIGNATURE-
Bug#1031040: Build dependency on sip-tools too loose
Source: wxpython4.0 Version: 4.2.0+dfsg-1 Severity: normal X-Debbugs-Cc: s...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, if I have a backport of sip6 available in a repo that is marked NotAutomatic: yes, and try to build wxpython there, the build dependencies will pull in sip-tools 5 and python3-sipbuild 6, which is inconsistent. Can you add the save version requirement to sip-tools to improve the chance to get a consistent set? Simon - -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'stable-debug'), (500, 'proposed-updates-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmPmetgPHHNqckBkZWJp YW4ub3JnAAoJEH69OHuwmQgRPd0H/R19i4nW3WpR5adV2rJkcuakvpq/ZWTWfRl3 s9Cnw4sWUw2UE/NXPxXdWhLAiR0fiRmd4uZO2P9QSZzLY0Bw18dhIa/9nf4yHUxu IBsxrsEtElWuSV206mAHxtbs5q1qzeOx1PeYc56M4F9RODjLcg0Mc2Tkuc+4MLOm pnr1Z6W3+irCfuR9gd37a51VU99N2eDAuOuReUMrhq4h6sq3iCUy5EgFyXyrri4k 1WkSE0Lo0KaPDPVQ6nV4mOCpPh0Q6l5edoBQTRT/C6MpRuBekRmYWaIk8m76LZte jeYVdy2Vzg1GPNbQzorhgG2doKFyT+g4T5nlg1o33RVwNKwFmYY= =jDTg -END PGP SIGNATURE-
Bug#1028431: shows "note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5" with -Wno-psabi
Package: g++-10 Version: 10.2.1-6 Severity: minor Tags: upstream X-Debbugs-Cc: s...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I have a lot of /usr/include/wx-3.2/wx/window.h: In member function ‘virtual wxSize wxWindowBase::GetMinSize() const’: /usr/include/wx-3.2/wx/window.h:485:78: note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5 in my build output. In principle this should be inhibited with -Wno-psabi, and passing this flag reduces output clutter, but apparently one of the places where this note is emitted is not tagged properly. Simon - -- System Information: Debian Release: 11.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 5.10.0-20-powerpc64le (SMP w/64 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages g++-10 depends on: ii gcc-1010.2.1-6 ii gcc-10-base 10.2.1-6 ii libc6 2.31-13+deb11u5 ii libgmp10 2:6.2.1+dfsg-1+deb11u1 ii libisl23 0.23-1 ii libmpc3 1.2.0-1 ii libmpfr6 4.1.0-3 ii libstdc++-10-dev 10.2.1-6 ii libzstd1 1.4.8+dfsg-2.1 ii zlib1g1:1.2.11.dfsg-2+deb11u2 g++-10 recommends no packages. Versions of packages g++-10 suggests: pn gcc-10-doc - -- no debconf information -BEGIN PGP SIGNATURE- iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmO95R0PHHNqckBkZWJp YW4ub3JnAAoJEH69OHuwmQgRw/8H/0fsuTjUjeYcOWOz4JkWeBIavCXMHUiwNZWL 9ijCiucO4gjgrujcZUJbkf+JftuOBlLEHrCJTsTXBH24S37egYG5y+g8/DyctG6r EARK7Ns5GPrZb8IrLuTw9c0aZMIR/bYmnFGbygn7bCo1qMwsgGEgwStyN9hHWid9 sM7xdMamON9X3kxxrOtFAJH87LhV+yUEyjCZzFKskl6yLBsFynowg1M552byp8Ki BBaJfqcH8AjUUdwq8kM9tzRg5jbP1RES3zwBKJR571xeZOfwzYdvDMaiEm+yvuVb sC4KAkE70+n/1fxoIgXayp+QmvcB7T9173AoOvMxnr3+3Iy6WAQ= =/it8 -END PGP SIGNATURE-
Bug#1028427: libwx_gtk3u_gl-3.2.so.0.1.0 moved, needs Replaces
Package: libwxgtk-gl3.2-1 Version: 3.2.1+dfsg-4 Severity: normal X-Debbugs-Cc: s...@debian.org Hi, while trying to install libwxgtk-gl3.2-1, I get dpkg: error processing archive libwxgtk-gl3.2-1_3.2.1+dfsg-4_ppc64el.deb (--install): trying to overwrite '/usr/lib/powerpc64le-linux-gnu/libwx_gtk3u_gl-3.2.so.0.1.0', which is also in package libwxgtk3.2-0:ppc64el 3.2.1+dfsg-1 I think this could benefit from a Replaces. Severity normal because 3.2.1+dfsg-1 is in testing. Simon -- System Information: Debian Release: 11.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 5.10.0-20-powerpc64le (SMP w/64 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libwxgtk-gl3.2-1 depends on: ii libc6 2.31-13+deb11u5 ii libgcc-s1 10.2.1-6 ii libgl1 1.3.2-1 ii libglib2.0-02.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libstdc++6 10.2.1-6 ii libwxbase3.2-1 3.2.1+dfsg-4~bpo11+1 ii libwxgtk3.2-1 3.2.1+dfsg-4~bpo11+1 ii libx11-62:1.7.2-1 libwxgtk-gl3.2-1 recommends no packages. libwxgtk-gl3.2-1 suggests no packages. -- no debconf information
Bug#1015871: Please enable CONFIG_PCI_P2PDMA
Source: linux-config-5.18 Severity: wishlist X-Debbugs-Cc: s...@debian.org Hi, would it be possible to enable this option to allow PCIe devices to do direct data transfers? Simon -- System Information: Debian Release: 11.4 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'stable-debug'), (500, 'proposed-updates-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled
Bug#1011164: rtcwake: time without date defaulting to "today" is useless
Package: util-linux Version: 2.36.1-8+deb11u1 Severity: wishlist Tags: upstream X-Debbugs-Cc: s...@debian.org Hi, the rtcwake command accepts a time without a date as an argument to --date, interprets it as meaning "today", then complains that the RTC doesn't go backwards. The string "tomorrow" can only stand alone and means midnight. This makes it difficult to specify "tomorrow 9:00" without date calculation code, like rtcwake -t `date +%s -d "tomorrow 9:00"`. Since it is clear that the desired time cannot be in the past, it would be nice to interpret a time without a date as either today or tomorrow, similar to how at(1) handles it. Simon -- System Information: Debian Release: 11.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-13-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii libaudit1 1:3.0-2 ii libblkid1 2.36.1-8+deb11u1 ii libc6 2.31-13+deb11u3 ii libcap-ng0 0.7.9-2.2+b1 ii libcrypt1 1:4.4.18-4 ii libmount1 2.36.1-8+deb11u1 ii libpam0g 1.4.0-9+deb11u1 ii libselinux13.1-3 ii libsmartcols1 2.36.1-8+deb11u1 ii libsystemd0247.3-7 ii libtinfo6 6.2+20201114-2 ii libudev1 247.3-7 ii libuuid1 2.36.1-8+deb11u1 ii login 1:4.8.1-1 ii zlib1g 1:1.2.11.dfsg-2 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.2-1 ii kbd 2.3.0-3 ii util-linux-locales 2.36.1-8+deb11u1 -- no debconf information
Bug#1004352: vcd2fst converts 'H' and 'L' to 'U'
Package: gtkwave Version: 3.3.104-2 Severity: normal Tags: upstream X-Debbugs-Cc: s...@debian.org Hi, I have a design that uses weakly driven signals for simulating a board that has pull-up resistors on an I²C bus. The VCD file contains a 'H' signal for the times none of the components actively drives the bus, and gtkwave displays this correctly. When I convert the VCD to FST for better performance, the weakly driven signals are converted to 'U', and the signal is shown as a red bar instead. Simon -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages gtkwave depends on: ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii libbz2-1.0 1.0.8-4 ii libc62.31-13+deb11u2 ii libgcc-s110.2.1-6 ii libgdk-pixbuf2.0-0 2.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk2.0-0 2.24.33-2 ii libjudydebian1 1.0.5-5+b2 ii liblzma5 5.2.5-2 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libtcl8.68.6.11+dfsg-1 ii libtk8.6 8.6.11-2 ii zlib1g 1:1.2.11.dfsg-2 gtkwave recommends no packages. gtkwave suggests no packages. -- no debconf information
Bug#1003729: packages.debian.org: missing buster-backports-sloppy suite
Package: www.debian.org Severity: normal X-Debbugs-Cc: s...@debian.org Hi, the "buster-backports-sloppy" suite is missing from the package search. Simon
Bug#1003232: dependency fix for backports
Package: kicad Version: 6.0.0-0~bpo11+1 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, I had to apply this patch to fix the dependencies for backported packages; otherwise the main kicad package would depend on a later version of itself (because the Upstream-Version generated by dpkg-makeshlibs is greater than the backport version). The fix is to apply the -X arguments for the internal libraries during makeshlibs, not during shlibdeps; this also means that libraries used by the private libraries are pulled in correctly (so this fix should go into the proper 6.0.0 release packages, not just into backports). Simon - -- System Information: Debian Release: 10.11 APT prefers oldstable APT policy: (990, 'oldstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-18-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) LSM: AppArmor: enabled Versions of packages kicad depends on: iu kicad6.0.0-0~bpo11+1 ii libc62.31-13+deb11u2 ii libcairo21.16.0-4+deb10u1 ii libcurl4 7.64.0-4+deb10u2 ii libgcc-s110.2.1-6 ii libgl1 1.1.0-1 ii libglew2.1 2.1.0-4 ii libglib2.0-0 2.66.8-1 ii libglu1-mesa [libglu1] 9.0.0-2.1+b3 ii libgtk-3-0 3.24.5-1 ii libngspice0 30.2-1 ii libocct-data-exchange-7.57.5.1+dfsg1-2 ii libocct-foundation-7.5 7.5.1+dfsg1-2 ii libocct-modeling-algorithms-7.5 7.5.1+dfsg1-2 ii libocct-modeling-data-7.57.5.1+dfsg1-2 ii libocct-ocaf-7.5 7.5.1+dfsg1-2 ii libpixman-1-00.36.0-1 ii libpython3.9 3.9.2-1 ii libstdc++6 10.2.1-6 ii libwxbase3.0-0v5 3.0.5.1+dfsg-2 ii libwxgtk3.0-gtk3-0v5 3.0.5.1+dfsg-2 ii python3 3.9.2-3 ii python3-wxgtk4.0 4.0.7+dfsg-10 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages kicad recommends: ii kicad-demos 5.1.9+dfsg1-1 ii kicad-libraries 5.1.9+dfsg1-1 ii xsltproc 1.1.32-2.2~deb10u1 Versions of packages kicad suggests: pn extra-xdg-menus pn kicad-doc-ca | kicad-doc-de | kicad-doc-en | kicad-doc-es | kicad- ii kicad-packages3d5.1.7-1 - -- no debconf information -BEGIN PGP SIGNATURE- iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmHXK64PHHNqckBkZWJp YW4ub3JnAAoJEH69OHuwmQgRIxQH/iWCcIE72J0cusE4OiIOanK+TVl2EekKKEQp LphLZ+hlF0gtCGyJzuz4IUSPnkzT1ZPuCYTttQhyu4lI85EQAWff8aub+t+G5Ogy dq90wMtALsTR5AZO00pZQ+kKZD4oBC3PFRrdw9MIlA3LDpP9fNqXo7hGmGR8CWnf u1AYfMVyK/oBlRWVsoO1yn/kfkFqeDqVQmJHjqmJX1hNeqyrjVlN/hj4vB1cHfgt qZjrzxGQ/YGIX+frRKN5jo7suZQ8F3yCKGiZd6ILMMudH8YEZgN3nR6cX+hOl/j8 ZFOaWpLSEqONjD7Ujp6tHOHk5pfiiB85ViIWGgL1UDxs22V8mlI= =QA2s -END PGP SIGNATURE- --- kicad-6.0.0/debian/rules2021-12-27 20:41:19.0 +0100 +++ kicad-6.0.0/debian/rules2021-12-27 21:08:37.0 +0100 @@ -151,9 +151,10 @@ # strip unneeded symbols from the kicad specific libraries in /usr/lib/kicad/ strip --strip-unneeded --remove-section=.comment $(CURDIR)/debian/kicad/usr/lib/kicad/_*.kiface -override_dh_shlibdeps: - dh_shlibdeps -a -l $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH) \ +override_dh_makeshlibs: + dh_makeshlibs -a \ -Xlibkicad_3dsg \ -Xlibs3d_plugin_idf \ + -Xlibs3d_plugin_oce \ -Xlibs3d_plugin_vrml \ -X_pcbnew.$(DEB_HOST_MULTIARCH)
Bug#1003124: Segmentation fault when querying surface Segmentation fault querying physical device surface support for remote display
Hi, the missing example code is attached here. Simon vkload-b0rked.tar.gz Description: application/gzip
Bug#1003116: NULL pointer dereference getting Vulkan surface properties if DISPLAY points to remote X server
Package: libnvidia-eglcore Version: 460.91.03-1 Severity: important File: /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.460.91.03 Tags: upstream X-Debbugs-Cc: s...@debian.org Hi, I have a small test Vulkan application that just opens an X11 window and then asks the installed Vulkan ICDs if they are capable of using this window as a presentation surface. When logged in over SSH, $DISPLAY points to a remote server, so my expectation would be for the nV driver to graciously decline when asked if this is a valid render target. Instead, I get ==30443== Warning: invalid file descriptor -1 in syscall close() ==30443== Warning: unimplemented fcntl command: 1033 ==30443== Jump to the invalid address stated on the next line ==30443==at 0x0: ??? ==30443==by 0x123B284E: ??? (in /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.460.91.03) ==30443==by 0x123A601B: ??? (in /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.460.91.03) ==30443==by 0x123B2D82: ??? (in /usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.460.91.03) ==30443==by 0x1457033D: vulkan_layer_chassis::GetPhysicalDeviceSurfaceCapabilitiesKHR(VkPhysicalDevice_T*, VkSurfaceKHR_T*, VkSurfaceCapabilitiesKHR*) (chassis.cpp:4703) ==30443==by 0x1098C0: vulkan_setup (vulkan_setup.c:211) ==30443==by 0x109319: main (vkload.c:27) ==30443== Address 0x0 is not stack'd, malloc'd or (recently) free'd In the same way, calling vulkaninfo gives ERROR at /build/vulkan-tools-oFB8Ns/vulkan-tools-1.2.162.0+dfsg1/vulkaninfo/vulkaninfo.h:248:vkGetPhysicalDeviceSurfaceFormats2KHR failed with ERROR_INITIALIZATION_FAILED with DISPLAY unset, vulkaninfo shows both my GTK980 and the llvmpipe driver as normal, with no presentable surfaces. Simon -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libnvidia-eglcore:amd64 depends on: ii libc6 2.31-13+deb11u2 libnvidia-eglcore:amd64 recommends no packages. libnvidia-eglcore:amd64 suggests no packages. -- no debconf information
Bug#1002981: leaves callback registered after unload
Package: libxext6
Version: 2:1.3.3-1.1
Severity: minor
Tags: upstream
X-Debbugs-Cc: s...@debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
I have a very basic Vulkan app that uses libXext only indirectly through
the Vulkan X11 extension, so my program is not linked against libXext
directly (and can be linked only with --no-as-needed).
During shutdown, the program crashes with a segmentation fault, during
63 for (ext = dpy->ext_procs; ext; ext = ext->next) {
64 if (ext->close_display)
65 (*ext->close_display)(dpy, >codes);
from src/ClDisplay.c in libX11. According to gdb,
*ext = {next = 0x558d0ee0, codes = {extension = 2, major_opcode = 128,
first_event = 0, first_error = 0}, create_GC = 0x0, copy_GC = 0x0,
flush_GC = 0x0, free_GC = 0x0, create_Font = 0x0, free_Font = 0x0,
close_display = 0x7fffed9c6ce0, error = 0x0, error_string = 0x0,
name = 0x558d0ec0 "Generic Event Extension", error_values = 0x0,
before_flush = 0x0, next_flush = 0x0}
The address for close_display refers to
0x7fffed9bd3d0 0x7fffed9c74ff Yes (*)
/lib/x86_64-linux-gnu/libXext.so.6
which has been unloaded at this point, together with the Vulkan driver.
It seems that libXext expects that it will remain loaded until
CloseDisplay() time, which is difficult to do here: I need to dismantle
Vulkan before closing the display connection, and libXext is only used
by an extension module that is loaded with dlopen(), so libXext will be
unloaded during Vulkan stack teardown.
I could reproduce this with both Intel and nVidia GPUs, using the source
attached. The problem goes away if I configure with
./configure LIBS='-Wl,--no-as-needed,-lXext'
to force link the application against libXext.
Simon
- -- System Information:
Debian Release: 11.2
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'),
(500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages libxext6 depends on:
ii libc6 2.31-13+deb11u2
ii libx11-6 2:1.7.2-1
libxext6 recommends no packages.
libxext6 suggests no packages.
- -- no debconf information
-BEGIN PGP SIGNATURE-
iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmHRPB4PHHNqckBkZWJp
YW4ub3JnAAoJEH69OHuwmQgRhVcH/395wMUzc6/q2MPTES2qNGiLqdbvy2prlgLy
MFRhvuhNGYFIxOhjaDPP9XKpjQ7FnZo54mVNq9FhSipbzCkTscj27s8bOVkcQ3Sz
wIi2NRkNuUOsrHdylxnqH9+tDOd4LhcpWONf3ch65a4siXrw6VjQ4+tdgayBdVgD
DzF0Ax2aXUyO/cAiUCoq4rbd1gaXkiAPSL6sprzklpf2H/Jqj475fr0cxAEJh/Mc
QvtV1hh26Cl1AIIkAM8EcD49fHCWXxIWscZDv5Ubw9ROCs1fUbLdMwczzeC4H8im
pFpf3TphQyB3LaZ6qSqDR3kQOv3jGcHhCPYFoc7U6dCpTmblz8Q=
=SA2i
-END PGP SIGNATURE-
vkload-0.0.20211229.tar.gz
Description: application/gzip
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi, On 10.09.21 01:46, Paul Wise wrote: Another important argument is that it creates a dependency on third-party commercial CDNs, and their *continued* sponsorship. This dependency on external providers is unavoidable, Debian definitely cannot afford to run our own CDN at the scale needed to support our existing userbase. For example the security mirrors struggled with Linux kernel security updates, so security.d.o switched to a commercial CDN. Also, we are dependent on continued sponsorship for all of our infrastructure, paying for all of our hosting is likely not feasible. Yes -- and mirrors have traditionally been provided by third parties. What is new about the CDNs is that there are rather few of those, and this centralization aspect is what worries me. Personally I'd like to see a larger variety of Debian delivery mechanisms; copy Debian/snapshot to archive.org, create a multi-distro FLOSS CDN, bring back httpredir, DebTorrent and apt-p2p, add an i2p mirror, use IPFS and content oriented networking etc. Michael Stone's apt://debian idea seems like a good way to move in that direction while adding protocol agility. Yes, absolutely -- and we especially want to have a better solution for containers, because my expectation is that a large fraction of our traffic is just people not bothering to set up caching. Simon
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi, On 04.09.21 22:12, Hideki Yamane wrote: The TLS layer is not part of the security model, so we'd be teaching users to look for the wrong thing, kind of like the "encrypted with SSL" badges on web pages in the 90ies. Is there any strong reason to use HTTP than HTTPS now? The strongest reason (IMO) in favor of unencrypted transmission is that it doesn't introduce a policy decision. The package "ca-certificates" must be installed and a checkmark set for the "mozilla/ISRG_Root_X1.crt" certificate, otherwise updates will break. If we want to have HTTPS as default, we need additional logic to make sure certificates are installed and cannot be deinstalled (so Essential or a strong dependency chain from an Essential package) and that the certificate cannot be deactivated, or apt needs its own repository of trusted certificates. With the current Docker images: $ docker run --rm -it debian:bullseye root@32529bf86cd3:/# sed -i -e s/http/https/ /etc/apt/sources.list root@32529bf86cd3:/# apt update Err:1 https://deb.debian.org/debian bullseye InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 199.232.138.132 443] Err:2 https://security.debian.org/debian-security bullseye-security InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 151.101.66.132 443] Err:3 https://deb.debian.org/debian bullseye-updates InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 199.232.138.132 443] So changing the default is not sufficient here, we'd need a lot of additional work and testing to ensure this works for everyone, not just the desktop users. Another important argument is that it creates a dependency on third-party commercial CDNs, and their *continued* sponsorship. Debian is very conservative when spending money and generally shies away from recurring expenses because we do not want to find us in a situation where we are dependent on an external entity making a timely donation in order to keep operations running, so I wonder why we are that accepting of it in one of our core services, and I certainly don't think we should be adding additional roadblocks should we ever need to find an alternative. We have a (crude) load-balancing framework in infrastructure we control that can point requests towards a set of untrusted mirrors, and while it's nice that we don't *need* to use this fallback plan, it is reassuring it is there. Should we teach all our users (including non-tech) about "Secure APT" mechanism? If they ask why we're not using HTTPS, yes: it helps clear up the misconception that anything with an "s" in it is secure and can be trusted. Anyone who configures an additional source needs to know how the authentication mechanism works anyway, so we're not gaining anything there either. Simon OpenPGP_signature Description: OpenPGP digital signature
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi, On 02.09.21 23:02, Ansgar wrote: As it is now, I can install a Debian system where no X.509 certificate authorities are trusted. That doesn't change with the proposal? - If I deselect all CAs in the configuration dialog of the ca-certificates package, what mechanism will allow apt to work? If people intentionally detrust them, they have to deal with the fallout. So this introduces a policy that users need to mark X.509 CAs as trusted? People can also detrust Debian's OpenPGP signing keys; it's not much different. The Debian signing keys have separate trust setup, and are trusted for nothing but APT updates. If we wanted the same for X.509, we'd need /etc/apt/ca-certificates or something such, and apt to configure the list of accepted CAs explicitly in the TLS layer rather than using the default settings. Accessing www.debian.org will also not work on such systems (and unlike deb.d.o that does not even offer non-https). It's not Debian's problem. There are a lot of systems out there that have no need to access www.debian.org, but do need to access deb.debian.org. - Do we want to pin the certificate provider for Debian mirrors, in the knowledge that we want to be bound to this provider for several years, do we want any "root" CA to be able to provide a trust anchor? Probably not? So what do we want then? A list of root CAs that users have to mark as trusted, possibly with an "are you sure?" dialog in ca-certificates? This isn't a simple change of default, because this simple change pulls in a lot of dependencies. That users can override the default means adding another work step for users, either a manual step that needs to be performed after a manual installation, or an automated step that needs to be integrated into users' deployment processes. - Is there a revocation mechanism by which we can mark "root" CAs as untrustworthy? If we don't have one, shouldn't we worry more about that given the widespread use of TLS? We have a big hammer, shipping a new ca-certificates package. If we want something that only affects apt, but not other packages, that mechanism doesn't exist yet. Do we have a revocation mechanism by which we can mark OpenPGP signing keys as untrustworthy (say for apt)? Yes, by shipping an update. - do we have a contingency plan if deb.debian.org hosting on Fastly is no longer feasible? As far as I know there is also at least https://cdn-aws.deb.debian.org/ if you don't like Fastly. It's not about what I like, but on what external services we want to depend. Simon OpenPGP_signature Description: OpenPGP digital signature
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi, On 02.09.21 03:22, Hideki Yamane wrote: Providing "default secure setting" is good message to users. The TLS layer is not part of the security model, so we'd be teaching users to look for the wrong thing, kind of like the "encrypted with SSL" badges on web pages in the 90ies. We have our own PKI that is decoupled from the X.509 certificate infrastructure, and neither ascribes any trust in them nor depends on the availability of an external service. As it is now, I can install a Debian system where no X.509 certificate authorities are trusted. - If I deselect all CAs in the configuration dialog of the ca-certificates package, what mechanism will allow apt to work? - Do we want to pin the certificate provider for Debian mirrors, in the knowledge that we want to be bound to this provider for several years, do we want any "root" CA to be able to provide a trust anchor? - Is there a revocation mechanism by which we can mark "root" CAs as untrustworthy? - What does the UI look like if OSCP verification fails? - How do mirror operators get a signed certificate? I think we're adding a lot of complexity and external dependencies to the system here, which adds a lot of burden to mirror operators that aren't large CDNs. That may be acceptable for an entity like Ubuntu, who aren't dependent on donations, but we would be tied to the goodwill of CDN operators here, so: - do we wish to communicate that the existing mirrors outside deb.debian.org are somehow less "secure"? - do we have a contingency plan if deb.debian.org hosting on Fastly is no longer feasible? Simon
Bug#991611: unblock: libudev0-shim/200-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please unblock package libudev0-shim This fixes upgrades from wheezy and earlier (#991605). No changes in the package, just a version bump to satisfy version ordering requirements between releases. - --- libudev0-shim-1/debian/changelog2020-10-27 23:46:48.0 +0100 +++ libudev0-shim-200/debian/changelog 2021-07-28 16:56:09.0 +0200 @@ -1,3 +1,9 @@ +libudev0-shim (200-1) unstable; urgency=medium + + * Bump version to facilitate upgrades (Closes: #991605) + + -- Simon Richter Wed, 28 Jul 2021 16:56:09 +0200 + libudev0-shim (1-3) unstable; urgency=medium * Limit to Linux architectures, as libudev is not available on BSD and unblock libudev0-shim/200-1 - -- System Information: Debian Release: 10.10 APT prefers stable APT policy: (990, 'stable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-17-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) LSM: AppArmor: enabled -BEGIN PGP SIGNATURE- iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAmEBcjIPHHNqckBkZWJp YW4ub3JnAAoJEH69OHuwmQgRsiQH/0oU3SM846ngI6CD/LkRyxyinpwU/KaGnf/D MBaZvQlWPyLkcZ0Wg7W9HGk2FY0ZDG+4UZd2zimK7sOQthjDEG482Wq4wHIQRcek fgJZbToIvw7VlZjOiv9gCu4YiOVUTXeMuGWqVXaQ8iXhiwTrxK9rb8ogpkpfmmwo 1yEu8tY9g75VioGTg31FmnrOW+UjWtZzAoEQBR3PySD7VWB3gasnL74X5dSVdoIW +MxCD0InjnoK8CKzIb3Vc5mznpdtOgoFVVe3Vrp+jwQG42nihmriCPS5EbJJuPHL YbjTVvkD1gx+OPuNRVaR0b8AkXTMYBofQoW4dOb2hVhI+wn39ho= =qeOg -END PGP SIGNATURE-
Bug#991605: libudev0: wheezy had libudev0 175-7.2 from src:udev
Hi Andreas, On 7/28/21 1:50 PM, Andreas Beckmann wrote: Therefore you cannot re-introduce the binary package with a lower version. Please bump the version, add an epoch or do something else to not violate version ordering constraints. I'm not sure that is an actual problem. In the old days, I believe we supported skipping one release during upgrades, and I've been told several times that this has been relaxed to "upgrades can be assumed not to skip releases" to allow upgrade code to be dropped from maintainer scripts. Simon OpenPGP_signature Description: OpenPGP digital signature
Bug#990118: show packages that are not from the default release
Package: aptitude Version: 0.8.11-7 Severity: wishlist Hi, it would be nice if there was a way to find packages whose local version is higher than the version from the archive that would be selected, possibly as a new toplevel group "Downgradeable Packages". Benefits: - quickly assessing whether unstable/experimental packages are installed. - making sure that the entire "Installed Packages" group can be reinstalled. Simon
Bug#989078: several SIGABRT in containers
Hi Michael, On Tue, May 25, 2021 at 11:39:35PM +0200, Michael Biebl wrote: > Am 25.05.21 um 15:29 schrieb Simon Richter: > >To reproduce, build the Debian systemd package inside a docker container, > >e.g. using > > FROM debian:buster > > RUN echo "deb-srchttp://deb.debian.org/debian/ buster main" > > >>/etc/apt/sources.list > > RUN apt-get update > > RUN apt-get -y install build-essential > > RUN apt-get -y build-dep systemd > > RUN apt-get -y source systemd > > RUN apt-get -y -b source systemd > Running this on a Debian sid system, the build completes > successfully (log attached). Interesting, for me the build stopped during dh_auto_test -- but your log contains several test failures where programs stopped with SIGABRT, just apparently not enough to fail the build. To run systemd-detect-virt, I have to install the systemd package inside the container (the "debian" image does not contain an init system at all). systemd-detect-virt reports "microsoft", even inside the container. Explicitly asking for the container gives "none". Should that make a difference for libudev? Simon
Bug#989078: several SIGABRT in containers
Hi Michael, > >To reproduce, build the Debian systemd package inside a docker container, > >e.g. using > Is this specific to docker containers / your docker setup? It seems to be happening under Docker specifically, it runs fine on bare metal and inside KVM, but that's not where I can run CI builds. The Docker setup is "apt install docker.io" inside KVM, that shouldn't be too exotic. I can retry with Docker on bare metal if you believe that helps. > docker doesn't often play nice when it comes to systemd, so I > wouldn't be too surprised, if there are some hickups regarding > running systemd inside docker. I'm not running systemd itself inside the container -- this is just an application querying libudev for a list of devices, and glibc running into an assertion because it is given a wrong pointer in a realloc(). In my stacktrace, the oldmem parameter to realloc is 0x7f242583b378, which is in the area behind the mapping for libudev1.so (you can see the addresses of the libudev functions are around 0x7f24256_), so it seems a pointer into the BSS area of libudev1 is given to realloc() here. So this seems to be a weakness in the sysfs parser in libudev1, or one of the utility functions it uses, that is exposed when run under Docker. Simon
Bug#989078: several SIGABRT in containers
Package: systemd
Version: 241-7~deb10u7
Severity: important
Tags: upstream
Hi,
I have a Docker container where I compile FPGA images using the QuartusII
toolchain, but this fails with
realloc(): invalid pointer
Aborted
Investigating this, I got a backtrace from gdb:
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x7f242ac38535 in __GI_abort () at abort.c:79
#2 0x7f242ac8f508 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f242ad9a28d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3 0x7f242ac95c1a in malloc_printerr (str=str@entry=0x7f242ad98587
"realloc(): invalid pointer") at malloc.c:5341
#4 0x7f242ac9ae4a in __GI___libc_realloc (oldmem=0x7f242583b378,
bytes=9) at malloc.c:3166
#5 0x7f24256afaf5 in strextend_with_separator
(x=x@entry=0x7ffe16aeaba0, separator=0x0, separator=0x0) at
../src/basic/string-util.c:920
#6 0x7f24256b3081 in chase_symlinks.constprop.36 (path=, ret=0x7ffe16aeac98, flags=0, original_root=0x0) at
../src/basic/fs-util.c:1009
#7 0x7f24256b8c0c in device_set_syspath (device=0x19e5760,
_syspath=_syspath@entry=0x7ffe16aead10 "/sys/bus/serio/devices/serio0",
verify=verify@entry=true)
at ../src/libsystemd/sd-device/sd-device.c:148
#8 0x7f24256b930a in sd_device_new_from_syspath
(ret=ret@entry=0x7ffe16aeadd0, syspath=syspath@entry=0x7ffe16aead10
"/sys/bus/serio/devices/serio0")
at ../src/libsystemd/sd-device/sd-device.c:223
#9 0x7f24256bf572 in enumerator_scan_dir_and_add_devices
(enumerator=enumerator@entry=0x19e5690, basedir=basedir@entry=0x7f24256c77c8
"bus",
subdir1=subdir1@entry=0x7f24257d014b "serio",
subdir2=subdir2@entry=0x7f24256c77ef "devices") at
../src/libsystemd/sd-device/device-enumerator.c:471
#10 0x7f24256bf945 in enumerator_scan_dir
(enumerator=enumerator@entry=0x19e5690, basedir=basedir@entry=0x7f24256c77c8
"bus", subdir=, subsystem=0x0)
at ../src/libsystemd/sd-device/device-enumerator.c:568
#11 0x7f24256c221f in enumerator_scan_devices_all
(enumerator=0x19e5690) at ../src/libsystemd/sd-device/device-enumerator.c:777
#12 device_enumerator_scan_devices (enumerator=0x19e5690) at
../src/libsystemd/sd-device/device-enumerator.c:844
#13 udev_enumerate_scan_devices (udev_enumerate=,
udev_enumerate=) at ../src/libudev/libudev-enumerate.c:377
#14 0x7f2430302f45 in ?? () from
/opt/altera/20.1/quartus/linux64/libsys_cpt.so
I've tried to build a minimal test case, which succeeds:
#include
int main(int argc, char **argv)
{
struct udev *u = udev_new();
struct udev_enumerate *e = udev_enumerate_new(u);
return udev_enumerate_scan_devices(e);
}
So, in order to get better debug information, I've tried to rebuild the
systemd package with debug information. For convenience, I did this inside
a container, and got several failing test cases. I then upgraded to the
version in sid to see if the problem had been solved in the meantime, but
building this package also failed:
324/598 udev-test SKIP 0.12s
351/598 test-engine FAIL 0.04s (killed
by signal 6 SIGABRT)
351/598 test-engine FAIL 0.04s (killed
by signal 6 SIGABRT)
357/598 test-boot-timestamps SKIP 0.04s
359/598 test-unit-nameFAIL 0.05s (killed
by signal 6 SIGABRT)
359/598 test-unit-nameFAIL 0.05s (killed
by signal 6 SIGABRT)
360/598 test-load-fragmentFAIL 0.07s (killed
by signal 6 SIGABRT)
360/598 test-load-fragmentFAIL 0.07s (killed
by signal 6 SIGABRT)
377/598 test-util FAIL 0.09s (killed
by signal 6 SIGABRT)
377/598 test-util FAIL 0.09s (killed
by signal 6 SIGABRT)
408/598 test-process-util FAIL 0.06s (killed
by signal 6 SIGABRT)
408/598 test-process-util FAIL 0.06s (killed
by signal 6 SIGABRT)
417/598 test-barrier SKIP 0.03s
419/598 test-namespaceSKIP 0.03s
423/598 test-seccomp FAIL 0.04s (killed
by signal 6 SIGABRT)
423/598 test-seccomp FAIL 0.04s (killed
by signal 6 SIGABRT)
426/598 test-loop-block SKIP 0.04s
429/598 test-bpf-devices SKIP 0.02s
430/598 test-bpf-firewall SKIP 0.02s
431/598 test-watch-pidFAIL 0.03s (killed
by signal 6 SIGABRT)
431/598 test-watch-pidFAIL 0.03s (killed
Bug#989039: cdebootstrap: fails to bootstrap Devuan (bug in HTTP implementation)
Package: cdebootstrap Version: 0.7.8+b1 Severity: normal Hi, I've tried to bootstrap a Devuan system, with cdebootstrap \ --verbose \ --keyring /tmp/devuan-archive-keyring.gpg \ beowulf /target http://deb.devuan.org/merged This successfully downloads one package, then fails to get the next. Repeated invocations get one more package each. This seems to be related to the redirect processing in the Devuan archive: unchanged packages come from Debian. cdebootstrap follows the redirect, but then requests the next file from the same host again, but uses the path from the Packages file without any prefix. E.g. [Devuan server] -> GET /merged/pool/DEBIAN/main/z/zlib/zlib1g_1.2.11.dfsg-1_amd64.deb <- 302 Found [Debian server] -> GET /debian/pool/main/z/zlib/zlib1g_1.2.11.dfsg-1_amd64.deb <- 200 Okay -> GET /pool/DEBIAN/main/d/dpkg/dpkg_1.19.7_amd64.deb <- 404 Not Found Simon -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages cdebootstrap depends on: ii debian-archive-keyring 2021.1.1 ii gpgv2.2.27-1 ii libbz2-1.0 1.0.8-4 ii libc6 2.31-11 ii libcurl3-gnutls 7.74.0-1.2 ii libdebian-installer-extra4 0.121 ii libdebian-installer40.121 ii liblzma55.2.5-2 ii zlib1g 1:1.2.11.dfsg-2 cdebootstrap recommends no packages. Versions of packages cdebootstrap suggests: pn qemu-user-static -- no debconf information
Bug#988513: ITP: ffts -- FFT library with JIT code generation
Package: wnpp Severity: wishlist Owner: Simon Richter X-Debbugs-Cc: debian-de...@lists.debian.org, s...@debian.org * Package name: ffts Version : 0.0.20170717 Upstream Author : Anthony M. Blake * URL : https://github.com/anthonix/ffts * License : BSD Programming Lang: C Description : FFT library with JIT code generation This is an implementation of FFT for use in DSP pipelines, assuming that parameters will not change at runtime and optimizing for this case. This is a dependency of glscopeclient (ITP'd as #988409).
Bug#977478: : broken definition DP_IS_END_TYPE
Package: gnu-efi Version: 3.0.9-1 Severity: minor File: /usr/include/efi/efidevp.h Tags: upstream Hi, in line 71, there is the macro definition #define DP_IS_END_TYPE(a) Obviously, the empty string is not a valid expression to test whether the lower seven bits of a are set, this should probably read #define DP_IS_END_TYPE(a) (DevicePathType(a) == END_DEVICE_PATH_TYPE) Simon -- System Information: Debian Release: 10.6 APT prefers stable APT policy: (990, 'stable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-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) LSM: AppArmor: enabled -- no debconf information
Bug#973536: RM: libparser++ -- ROM; unused
Package: ftp.debian.org Severity: normal Hi, this was a build dependency of debian-xcontrol, which was removed in 2019, and no other users are known, so it should be safe to remove. Simon
Bug#959093: command to delete downloaded package lists and package cache, for container building
Package: apt Version: 2.0.2 Severity: wishlist Tags: upstream Hi, I'm trying to build a few Docker containers for various apps, and since I'm adding packages, I need to have package lists available during the container build, but I'd like to remove them before packing the final application container. I can obviously do that manually, which requires me to know apt internals. It would be nice if there was a command to remove the downloaded lists and the indexes (although the latter can also be removed by just dropping all files below /var/cache, which would be allowed in any case). Simon -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: ppc64el (ppc64le) Kernel: Linux 5.5.0-2-powerpc64le (SMP w/64 CPU cores) Kernel taint flags: TAINT_UNSIGNED_MODULE 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser 3.118 ii debian-archive-keyring 2019.1 ii gpgv2.2.20-1 ii libapt-pkg6.0 2.0.2 ii libc6 2.30-4 ii libgcc-s1 10-20200418-1 ii libgnutls30 3.6.13-2 ii libseccomp2 2.4.3-1+b1 ii libstdc++6 10-20200418-1 ii libsystemd0 245.5-1 Versions of packages apt recommends: ii ca-certificates 20190110 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.12-3 ii dpkg-dev1.19.7 ii gnupg 2.2.20-1 ii powermgmt-base 1.36 -- no debconf information
Bug#958535: overlapping outputs configured as separate frames
Package: ratpoison Version: 1.4.9-1 Severity: minor Hi, I often use a duplicated display where the laptop screen shows the same picture as the external monitor. In this configuration, frame 0 is the internal display, frame 1 the external, both occupy the same screen space. Simon -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-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) LSM: AppArmor: enabled Versions of packages ratpoison depends on: ii libc6 2.28-10 ii libx11-62:1.6.7-1 ii libxft2 2.3.2-2 ii libxrandr2 2:1.5.1-1 ii libxtst62:1.2.3-1 Versions of packages ratpoison recommends: ii 9menu1.9-2 ii menu 2.1.47+b1 ii xterm [x-terminal-emulator] 344-1 Versions of packages ratpoison suggests: pn xbindkeys ii xclip 0.13-1 -- no debconf information
Bug#951479: [files list file for package 'base-passwd' is missing final newline] [debian buster 10.3]
Hi, On Mon, Feb 17, 2020 at 04:49:44PM +0100, Jean-Marc LACROIX wrote: > >Could you attach the old base-passwd.list file? > yes, in attached file. That file has a sensible size, but consists of only zeroes. This typically happens with file systems that have metadata only journaling after a power loss, as the metadata update is covered by the journal and can be replayed, while the data write itself is lost. That can happen e.g. with ext4 in "data=writeback" mode, which is discouraged precisely for that reason. Simon
Bug#951479: [files list file for package 'base-passwd' is missing final newline] [debian buster 10.3]
Hi, On Mon, Feb 17, 2020 at 10:31:25AM +0100, Jean-Marc LACROIX wrote: > dpkg: unrecoverable fatal error, aborting: > files list file for package 'base-passwd' is missing final newline > E: Sub-process /usr/bin/dpkg returned an error code (2) That file is generated by dpkg on installation, so it's not the package's fault. The "final newline" check is a safety check to see that the file name is complete, guarding against write errors. You need to reinstall the base-passwd package, possibly after deleting /var/lib/dpkg/info/base-passwd.list, and I'd also run a file system check for good measure, because that state should only happen on write errors (although I remember it also sometimes happened when /var was full, but IIRC that got fixed). Simon
Bug#951324: CTest does not detect NUMA correctly
Package: cmake Version: 3.15.4-1 Severity: minor Tags: upstream Hi, I've run ctest on a dual-socket machine, and the generated report contains NumberOfLogicalCPU="64" NumberOfPhysicalCPU="1" That is wrong. numastat shows two nodes, node 0 and node 8. Simon -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: ppc64el (ppc64le) Kernel: Linux 5.3.0-3-powerpc64le (SMP w/64 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages cmake depends on: ii cmake-data3.15.4-1 ii libarchive13 3.4.0-1+b1 ii libc6 2.29-10 ii libcurl4 7.67.0-2 ii libexpat1 2.2.9-1 ii libgcc1 1:9.2.1-25 ii libjsoncpp1 1.7.4-3.1 ii librhash0 1.3.9-1 ii libstdc++69.2.1-25 ii libuv11.34.2-1 ii procps2:3.3.15-2+b1 ii zlib1g1:1.2.11.dfsg-1.2 Versions of packages cmake recommends: ii gcc 4:9.2.1-3.1 ii make 4.2.1-1.2 Versions of packages cmake suggests: pn cmake-doc ii ninja-build 1.10.0-1 -- no debconf information
Bug#950673: autoremove reports "1 not upgraded"
Package: apt Version: 1.8.2 Severity: minor Hi, I'm getting a report from "apt autoremove" that one package could not be upgraded, while "apt upgrade" reports zero: # apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. # apt autoremove Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded. As discussed on IRC: # python Python 2.7.16 (default, Oct 10 2019, 22:02:15) [GCC 8.3.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import apt; print([p for p in apt.Cache() if p.is_upgradable]) [] >>> Full dump of /etc/apt /var/lib/apt/lists /var/lib/dpkg/status is at http://psi5.com/~geier/aptbug.tar.xz . Simon -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-image-unsigned-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-buildinfo-4\.9\.0-9-amd64$"; APT::NeverAutoRemove:: "^linux-source-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-source-4\.19\.0-6-amd64$"; APT::NeverAutoRemove:: "^linux-source-4\.9\.0-9-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-modules"; APT::VersionedKernelPackages::
Bug#949679: defines preprocessor symbols reserved for the application
Package: libpython3.7-dev Version: 3.7.6-1 Severity: minor Tags: upstream Hi, the file pyconfig.h defines several preprocessor symbols, leading to warnings such as /usr/include/powerpc64le-linux-gnu/python3.7m/pyconfig.h:127: note: this is the location of the previous definition 127 | #define HAVE_CLOCK_GETTIME 1 This will cause warnings for all autotools based packages that also use this feature test. In addition, pyconfig.h defines _GNU_SOURCE and _POSIX_C_SOURCE, which alter the behaviour of libc headers included after them. IMO, the HAVE_* definitions from feature tests should be given a prefix if they need to be available to other public python headers, or moved to a private header that is used only for compiling Python itself, and the definition of _*_SOURCE should be either the first line of source files inside the Python source tree, or of a precompiled header if it is used, so these macros are set consistently for the entire source tree -- as it is now, files including Python.h get different libc features depending on whether libc headers are included before or after. Simon -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: ppc64el (ppc64le) Kernel: Linux 5.3.0-3-powerpc64le (SMP w/64 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libpython3.7-dev depends on: ii libexpat1-dev2.2.9-1 ii libpython3.7 3.7.6-1 ii libpython3.7-stdlib 3.7.6-1 Versions of packages libpython3.7-dev recommends: ii libc6-dev [libc-dev] 2.29-7 libpython3.7-dev suggests no packages. -- no debconf information
Bug#946533: Please remove me from Uploaders
Package: src:uclibc Severity: minor Hi, I haven't really done anything on the package in ages, and am not currently using it, so it might make sense to remove me from the Uploaders list. Simon -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/32 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 /bin/dash Init: sysvinit (via /sbin/init)
Bug#941198: In support of mandatory unit files
Hi, On 08.12.19 09:54, Tobias Frost wrote: > Well, I was responding to a mail that suggested to make unit files > mandatory (which I read as then RC-buggy) and suggesting some lines > later to drop support for the sysv-generator and in this case it is > quite moot that policy can be ignored because I fear that once > unit files would become mandatory that would be used as an argument to > drop support for the generator. The generator that makes the init scripts usable for systemd generates a unit that calls the init script. It should be possible to just do the same thing and build a unit file that calls the init script. That would be fully allowed when unit files are mandatory. Simon signature.asc Description: OpenPGP digital signature
Bug#941198: In support of mandatory unit files
Hi, chiming in as I've been pointed to this bug: I agree with Ansgar in that adding unit files does not hurt sysvinit support in the least, provided we still get to ignore them. I'd even be in favour of making them mandatory (i.e. upgrading the lintian warning to an error), and I don't see how the GR outcome would affect the question of whether we want to ship unit files in packages, so I'd be fine with going ahead with this change even while the GR is still running. As long as we support sysv-rc, init scripts will have to remain mandatory as well, though. IMO, an ideal outcome would be that systemd can completely ignore any init scripts from Debian packages, i.e. the compatibility generator, if installed, would only have to generate units for init scripts that didn't come from a package, and default installations would not include this generator. The same should be done for cron files vs timer units -- ideally, we'd get to a state where cron files can be completely ignored by systemd because it is a bug to not have a timer unit with the same settings. That would allow systemd users to get rid of the spurious wakeups as well, which I'd consider a major win. Simon
Bug#945283: users should check whether they get same packages as all other users get
Hi, On Fri, Nov 22, 2019 at 03:20:45PM +0300, dinar qurbanov wrote: > so, in order to serve a package with malware to a > user, disrtribution/repository admins would have to also serve wrong > "packages" and "release" files to him. so, if user checks the > "release" file, that it is ok, enough, he can be sure that packages > are also ok. There is also the Release.gpg and InRelease files, which contain a PGP signature for the data in the Release file, anchoring the trust chain in a public key distributed inside the Debian installer, so an attacker cannot generate a Release file that will be accepted by apt. It is possible to delay updates by several days as apt accepts older timestamps on Release files, precisely so out-of-date mirrors can be used for noncritical updates. The security updates are distributed centrally, and the timestamp on those files is checked more stringently (the Release file on the security mirror has a Valid-Until field, after that time apt requires that package lists are refreshed). > from point of view of users, debian > may have to send malware to some users by government request. if to > say about all distributions, there may be malicious distributions. There is only one central point by which packages enter the mirror network, so comparing packages across mirrors does not give any advantage. If the central point is compromised, all mirrors are, if individual mirrors are compromised, these are unable to serve packages at all, because they do not have a valid signed Release file. Simon
Bug#945039: firefox-esr: "new behaviour for extensions in private windows" dialog fights window manager
Package: firefox-esr Version: 68.2.0esr-1+b1 Severity: minor Tags: upstream Hi, I just got the one-time notification dialog that extensions are disabled in private windows by default now. This dialog flickers between the position it was opened at and the center of the screen on ratpoison, so it is not properly marked as transient, and it also fights the window manager on positioning. Minor since it's a one-time event that can be resolved by pressing escape, but it's still indicative of an oversight in the framework, and other notifications might be affected too. Simon -- Package-specific info: -- Addons package information -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages firefox-esr depends on: ii debianutils 4.9 ii fontconfig2.13.1-2+b1 ii libasound21.1.9-1 ii libatk1.0-0 2.34.1-1 ii libc6 2.29-3 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.16-2 ii libdbus-glib-1-2 0.110-4 ii libevent-2.1-72.1.11-stable-1 ii libffi6 3.2.1-9 ii libfontconfig12.13.1-2+b1 ii libfreetype6 2.10.1-2 ii libgcc1 1:9.2.1-19 ii libgdk-pixbuf2.0-02.40.0+dfsg-1 ii libglib2.0-0 2.62.2-3 ii libgtk-3-03.24.12-1 ii libjsoncpp1 1.7.4-3+b1 ii libnspr4 2:4.23-1 ii libnss3 2:3.45-1 ii libpango-1.0-01.42.4-7 ii libsqlite3-0 3.30.1-1 ii libstartup-notification0 0.12-6 ii libstdc++69.2.1-19 ii libx11-6 2:1.6.8-1 ii libx11-xcb1 2:1.6.8-1 ii libxcb-shm0 1.13.1-2 ii libxcb1 1.13.1-2 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.5-1 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1+b3 ii procps2:3.3.15-2+b1 ii zlib1g1:1.2.11.dfsg-1+b1 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.2.1-2 Versions of packages firefox-esr suggests: ii fonts-lmodern 2.004.5-6 ii fonts-stix [otf-stix] 1.1.1-4 ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.17-6 ii libgtk2.0-02.24.32-4 ii pulseaudio 13.0-3 -- no debconf information
Bug#906060: Coordinate overflow when rendering
Hi, On Wed, Oct 23, 2019 at 09:45:11AM +1300, Olly Betts wrote: > > This is a major showstopper for linking KiCad 5 against GTK3, so this > > requires us to keep GTK2 around longer. > The debian kicad package has now using the GTK3 flavour of wxwidgets3.0 > for many months, so has this bug been solved (at least as far as kicad > and wxwidgets3.0 are concerned)? No, we rewrote the entire rendering engine so we render through wxGLCanvas now in most cases, with a fallback where we apply the zoom ourselves before rendering through Cairo directly. Hardly an ideal outcome. > If so, I think we can at least unassign this from wx and kicad. This can be marked as fixed in kicad >= 5.1 probably, but it's still a problem for rendering to a zoomed wx canvas through a wxDC. > If not, I'm very unclear what (as a maintainer of wxwidgets3.0) I'm > expected to do given that the problem clearly seem to lie lower down the > stack: > > Quick debugging has shown that the coordinates given to Cairo still make > > sense, even if the zoom level makes them numerically large. As I'd need > > significant time to debug into optimized drawing routines, I'd like to pass > > this on. I suspect that this is mostly an interaction between Cairo and > > Pixman, with an overflow happening somewhere in a conversion from double to > > an integer type. In any case it's an upstream problem, either in Cairo or wx, depending on whether large zoom levels are supposed to work in Cairo. Simon
Bug#942614: valgrind: debuginfo section duplicates a section in the main ELF file
Package: valgrind Version: 1:3.15.0-1.1 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, this is probably the same as Ubuntu bug #1848211. Debug information for glib and gtk libraries is not loaded properly: - --22862-- WARNING: Serious error when reading debug info - --22862-- When reading debug info from /usr/lib/x86_64-linux-gnu/libgdk-3.so.0.2404.8: - --22862--debuginfo section duplicates a section in the main ELF file - --22862-- WARNING: Serious error when reading debug info - --22862-- When reading debug info from /usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0.4000.0: - --22862--debuginfo section duplicates a section in the main ELF file - --22862-- WARNING: Serious error when reading debug info - --22862-- When reading debug info from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6200.1: - --22862--debuginfo section duplicates a section in the main ELF file - --22862-- WARNING: Serious error when reading debug info - --22862-- When reading debug info from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.1: - --22862--debuginfo section duplicates a section in the main ELF file - --22862-- WARNING: Serious error when reading debug info - --22862-- When reading debug info from /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0.6200.1: - --22862--debuginfo section duplicates a section in the main ELF file - --22862-- WARNING: Serious error when reading debug info - --22862-- When reading debug info from /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1.0.7: - --22862--debuginfo section duplicates a section in the main ELF file - --22862-- WARNING: Serious error when reading debug info - --22862-- When reading debug info from /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1.0.7: - --22862--debuginfo section duplicates a section in the main ELF file Stack traces involving these libraries are completely broken: ==22862== 64 bytes in 1 blocks are possibly lost in loss record 8,003 of 11,130 ==22862==at 0x4837D7B: realloc (vg_replace_malloc.c:836) ==22862==by 0x625CA87: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.1) ==22862==by 0x8BCC117: ??? ==22862==by 0x61DCFB3: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6200.1) ==22862==by 0x1FFEFFEACF: ??? ==22862==by 0xC: ??? ==22862==by 0x8BCC117: ??? ==22862==by 0x5C78170: ??? (in /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.8) ==22862==by 0x1FFEFFEACF: ??? Simon - -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages valgrind depends on: ii libc6 2.29-2 ii libc6-dbg 2.29-2 Versions of packages valgrind recommends: ii gdb 8.3.1-1 ii valgrind-dbg 1:3.15.0-1.1 Versions of packages valgrind suggests: pn alleyoop pn kcachegrind pn valgrind-mpi pn valkyrie - -- no debconf information -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAl2qaIwACgkQfr04e7CZ CBH+mQf/W22EZvgua1KHzObamkhtHO+mcxuPN8xAdvoFw+9hIgKfKgUtcu2Omqsb LbQpVjWm3Jkge25KLhhVpQ/ZjfOv6aQic8yH7cQKMcvtyAVs+YTl4bTndeWJLuzD CmeBclivjBPFPm7PayEelt1ponpQEoRJqMoftu77XSW2/Ve/C/JcPwyysSaoKI5V imoSn1/7yj9GcIYGJZ/b2lyFmAwPhJ1o+xwRrf+l3WU23ogQPnpkLTAAHhomGhhx Y6VlPmeBJGXn/RF4aHW/kKxna2+hxkZcyE0Zwl6i6SfyPpbjMOiUkgrcGKK+hH9f /Cia0kUjYZXgCtSzg7LQ/1ivDrWy3Q== =2No5 -END PGP SIGNATURE-
Bug#942603: dkms: complains about systemd and dbus not running
Package: dkms Version: 2.7.1-4 Severity: minor Hi, I just did a system update, and after compiling my dkms modules, I got a bunch of error messages: depmod... System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Der Rechner ist nicht aktiv These seem ultimately harmless, and installation continues, but it is nonetheless annoying to have error messages during installation, and it also suggests that an error return code is ignored here. Simon -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'testing-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages dkms depends on: ii build-essential 12.8 ii coreutils8.30-3+b1 ii dpkg-dev 1.19.7 ii gcc 4:9.2.1-3.1 ii kmod 26-3 ii make 4.2.1-1.2 ii patch2.7.6-6 Versions of packages dkms recommends: ii fakeroot 1.24-1 ii linux-headers-amd64 5.2+107 ii lsb-release 11.1.0 ii sudo 1.8.27-1+deb10u1 Versions of packages dkms suggests: ii menu2.1.47+b1 pn python3-apport -- no debconf information
Bug#942548: (no subject)
Subject: valgrind: does not notice Intel DRI mapping in client process Package: valgrind Version: 1:3.14.0-3 Severity: normal Tags: upstream Hi, I'm trying to debug a program that renders using OpenGL, so for direct rendering, a portion of video ram is directly mapped into client address space for the command queue. Valgrind doesn't notice this mapping being made, so all commands are treated as invalid accesses: ==7997== Invalid write of size 4 ==7997==at 0x4EDAFBD2: ??? (in /usr/lib/x86_64-linux-gnu/dri/i965_dri.so) ==7997==by 0x285B0242: ??? (in /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0) ==7997==by 0x4891C5A: wxGLCanvasX11::SwapBuffers() (glx11.cpp:604) [...] ==7997== Address 0x7fea79042944 is not stack'd, malloc'd or (recently) free'd The mapping can be found in /proc/7997/maps: [...] 7fea76937000-7fea77037000 rw-s 00:18 7365028/i915 (deleted) 7fea77037000-7fea79037000 rw-s 00:18 7366173/i915 (deleted) 7fea79037000-7fea7903b000 rw-s 00:18 7369037/i915 (deleted) 7fea7903b000-7fea7903f000 rw-s 00:18 7369035/i915 (deleted) 7fea7903f000-7fea79044000 rw-s 00:18 7369034/i915 (deleted) This generates a few thousand error messages for each drawing operation, and valgrind soon stops reporting errors. It appears as if the memory is mapped through the DRM_IOCTL_I915_GEM_MMAP ioctl on the DRM device. Simon - -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=de_DE.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages valgrind depends on: ii libc6 2.28-10 ii libc6-dbg 2.28-10 Versions of packages valgrind recommends: ii gdb 8.2.1-2+b1 ii valgrind-dbg 1:3.14.0-3 Versions of packages valgrind suggests: pn alleyoop pn kcachegrind pn valgrind-mpi pn valkyrie - -- no debconf information -BEGIN PGP SIGNATURE- iQEyBAEBCgAdFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAl2o5V8ACgkQfr04e7CZ CBFAsQf40e/X0514ViMhCmL39Cy0cotKtjSKcbCEoVGHprTYU0MASitWIGqE1JGs 54pVZC/FCWV7N7EnElU2hHOaN5kbQOfWfvri+5XURupn9YiVd7Rj+THI2exGXFw2 aQEWIGhowjRh7s84CI8bkb3FgOqX5MxE8Mncypxi5O9bCmDzujwuMcm9if5zLFdh Mk4b1CYtTffx9Ua5Qo7z/yXa/4QnkAOTn6iA9g3FJhAJzC59bPUmCJI2nG4YGBjz HCPRGS10AFEyUbQfYrDWxsIUG32suulqMbjo41yVLTXr4GNqdBAHhnanQBQShcNB O+tNmrrmIPt2DpFXN7ZyH5fkQduE =LWj0 -END PGP SIGNATURE-
Bug#941277: dispatch function missing in header file generated for RPC service
Hi, On 27.09.19 22:30, Florian Weimer wrote: > Ugh, can you describe exactly what is missing? Then I can file it > here (or just submit a patch): If you compile a service description for the server side, e.g. rpcgen -m /usr/include/rpcsvc/mount.x you get the dispatch function that takes an incoming request and calls the appropriate server function. For single-service programs, you would normally generate the main function as well, using rpcgen -s tcp /usr/include/rpcsvc/mount.x This way, the dispatch function is adequately registered. If you need to provide your own main function (i.e. the RPC service is part of a larger program), you need to call svc_register yourself, so you need a declaration of this function, for the mount service that would be void mountprog_1(struct svc_req *rqstp, register SVCXPRT *transp); That function is absent from the header generated using rpcgen -h /usr/include/rpcsvc/mount.x If you generate dispatch tables using -T, the table is declared in the header, so I'd also expect the dispatch function to be declared. Simon signature.asc Description: OpenPGP digital signature
Bug#941277: dispatch function missing in header file generated for RPC service
Package: libc-dev-bin Version: 2.28-10 Severity: minor Tags: upstream Hi, while implementing an RPC service (in 2019, no less!) I found out that the dispatch function generated by rpcgen is not listed in the generated header file, so if the service is generated without a main function or inetd interface, the code using it needs to create its own declaration. The signature is easy to guess, but nonetheless I think it should be provided by the header. Simon -- System Information: Debian Release: 10.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-6-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) LSM: AppArmor: enabled Versions of packages libc-dev-bin depends on: ii libc6 2.28-10 Versions of packages libc-dev-bin recommends: ii manpages 4.16-2 ii manpages-dev 4.16-2 libc-dev-bin suggests no packages. -- no debconf information
Bug#940971: init script takes 90 seconds
Hi, On Sun, Sep 22, 2019 at 09:01:48PM +0100, Mark Hindley wrote: > > /etc/init.d/dbus is hanging pretty much exactly 90 seconds on either boot > > or manual start: > I have observed similar behaviour on sysvinit systems which still have systemd > installed. > I think it is related to libnss-systemd: removing it gets rid of the hang for > me. So this is likely a bug in libnss-systemd. Simon
Bug#940971: init script takes 90 seconds
Package: dbus Version: 1.12.16-1 Severity: important Hi, /etc/init.d/dbus is hanging pretty much exactly 90 seconds on either boot or manual start: # time service dbus start Starting system message bus: dbus. real1m30.111s user0m0.010s sys 0m0.010s The service seems to be running afterwards. Simon -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: ppc64el (ppc64le) Kernel: Linux 5.2.0-2-powerpc64le (SMP w/64 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: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages dbus depends on: ii adduser 3.118 ii libapparmor1 2.13.3-5 ii libaudit1 1:2.8.5-2 ii libc6 2.29-1 ii libcap-ng00.7.9-2+b1 ii libdbus-1-3 1.12.16-1 ii libexpat1 2.2.7-2 ii libselinux1 2.9-2+b2 ii libsystemd0 242-7 dbus recommends no packages. Versions of packages dbus suggests: ii dbus-x11 [dbus-session-bus] 1.12.16-1 Versions of packages dbus is related to: ii dbus-x11 1.12.16-1 ii systemd 242-7 pn systemd-sysv -- no debconf information
Bug#940965: apt: Fails to find a solution for libgtk-3-0 and sysvinit-core
Package: apt Version: 1.8.2 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, apt's resolver does not find a working solution for installing both libgtk-3-0 and sysvinit-core, or for installing libgtk-3-0 when systemd-sysv has a negative score in preferences. Aptitude resolves both of these by favouring dbus-x11 over dbus-user-session. When presented manually with this solution, apt accepts it as valid. Simon - -- Package-specific info: - -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-modules-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-modules-extra-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-image-unsigned-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-modules-.*-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-tools-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-cloud-tools-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-buildinfo-4\.19\.0-5-amd64$"; APT::NeverAutoRemove:: "^linux-source-4\.19\.0-5-amd64$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-modules"; APT::VersionedKernelPackages:: "linux-modules-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "linux-image-unsigned"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::VersionedKernelPackages:: "linux-cloud-tools"; APT::VersionedKernelPackages:: "linux-buildinfo"; APT::VersionedKernelPackages:: "linux-source"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::Update ""; APT::Update::Post-Invoke ""; APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || true"; APT::Default-Release "buster"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Architectures:: "i386"; APT::Architectures:: "armhf"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "false"; APT::Compressor::zstd::Cost "60"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200";
Bug#940729: Cannot compile qwt programs without optimization through CONFIG+=debug
Package: libqwt-dev Version: 6.1.4-1 Severity: normal Hi, qwtconfig.pri contains QMAKE_CXXFLAGS *= $(shell dpkg-buildflags --get CXXFLAGS) which unconditionally pulls in flags from dpkg-buildflags. By default, these include "-O2" unless DEB_BUILD_OPTIONS='noopt' is given, so programs linking against qwt will be built with optimization enabled even if they were configured as Debug. Simon -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/6 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) LSM: AppArmor: enabled Versions of packages libqwt-dev depends on: ii libc62.28-10 ii libgcc1 1:8.3.0-6 ii libqt4-designer 4:4.8.7+dfsg-18 ii libqt4-dev 4:4.8.7+dfsg-18 ii libqtcore4 4:4.8.7+dfsg-18 ii libqtgui44:4.8.7+dfsg-18 ii libqwt-headers 6.1.4-1 ii libqwt6abi1 6.1.4-1 ii libstdc++6 8.3.0-6 libqwt-dev recommends no packages. libqwt-dev suggests no packages. -- no debconf information
Bug#933732: Fixed upstream
Hi, I've submitted an updated version of this patch upstream, and it was merged as commit e78d816e on September 5th. Simon
Bug#939690: libasound2-plugins:amd64: HDMI plugin missing
Package: libasound2-plugins Version: 1.1.8-1 Severity: normal Hi, aplay -L reports that I have two HDMI audio channels: hdmi:CARD=PCH,DEV=0 HDA Intel PCH, HDMI 0 HDMI Audio Output hdmi:CARD=PCH,DEV=1 HDA Intel PCH, HDMI 1 HDMI Audio Output That is indeed correct, but trying to use them I end up with alsa-lib: dlmisc.c:287:(snd1_dlobj_cache_get) Cannot open shared library /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_hdmi.so ((null): /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_hdmi.so: cannot open shared object file: No such file or directory) It seems the plugin is missing here. The normal audio device works in some configurations, but has no information on the capabilities of the connected device. Simon -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libasound2-plugins:amd64 depends on: ii libasound21.1.8-1 ii libavcodec58 7:4.1.4-1~deb10u1 ii libavresample47:4.1.4-1~deb10u1 ii libavutil56 7:4.1.4-1~deb10u1 ii libc6 2.28-10 ii libjack-jackd2-0 [libjack-0.125] 1.9.12~dfsg-2 ii libpulse0 12.2-4 ii libsamplerate00.1.9-2 libasound2-plugins:amd64 recommends no packages. libasound2-plugins:amd64 suggests no packages. -- no debconf information
Bug#933275: Patch for #933275
tags 933275 +patch thanks Hi, here's a patch I've also sent to the mailing list. Works for me, but probably needs some testing that it doesn't break anything else. Simon >From 13105537e68f0d3692b19a0f5cf675d79e32d42a Mon Sep 17 00:00:00 2001 From: Simon Richter Date: Tue, 13 Aug 2019 13:49:06 +0200 Subject: [PATCH] Apply path correction to correct argument This fixes running OpenCL tests under Valgrind, by applying the path transformation to the argument that the original command turned into. It would be nice to have a cleaner solution here that doesn't depend on text substitution, but as long as there is no OpenCL test named "valgrind", this should work. --- framework/test/piglit_test.py | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/framework/test/piglit_test.py b/framework/test/piglit_test.py index 0881f00a6..ab6de0398 100644 --- a/framework/test/piglit_test.py +++ b/framework/test/piglit_test.py @@ -75,8 +75,7 @@ class PiglitBaseTest(ValgrindMixin, Test): @Test.command.getter def command(self): # Prepend TEST_BIN_DIR to the path. -cmd = os.path.join(TEST_BIN_DIR, super(PiglitBaseTest, self).command[0]) -return [cmd] + self._command[1:] +return [os.path.join(TEST_BIN_DIR, c) if c == self._command[0] else c for c in super(PiglitBaseTest, self).command ] def interpret_result(self): out = [] @@ -231,8 +230,7 @@ class CLProgramTester(PiglitCLTest): @PiglitCLTest.command.getter def command(self): command = super(CLProgramTester, self).command -command.insert(1, os.path.join(ROOT_DIR, self.filename)) -return command +return command + [ os.path.join(ROOT_DIR, self.filename) ] class VkRunnerTest(PiglitBaseTest): -- 2.20.1
Bug#933732: causes piglit test failure
Package: ocl-icd-libopencl1 Version: 2.2.12-2 Severity: minor Tags: upstream Hi, I have a single OpenCL ICD installed, and am running piglit tests against it. I get a test failure in the clGetExtensionFunctionForPlatform test, which expects NULL to be returned when the platform parameter passed is NULL. The implementation in ocl-icd does platform=selectPlatformID(platform); which selects the platform if only one is available, causing the test to fail. If that is indeed correct behaviour according to the spec, then the testsuite is wrong, but as far as I've understood it, this function should not fall back to the default platform if the parameter that is passed is NULL. Simon -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/32 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 /bin/dash Init: sysvinit (via /sbin/init) Versions of packages ocl-icd-libopencl1 depends on: ii libc6 2.28-10 ocl-icd-libopencl1 recommends no packages. Versions of packages ocl-icd-libopencl1 suggests: pn opencl-icd -- no debconf information
Bug#933275: expects valgrind in own binary dir, fails to run tests with --valgrind option
Package: piglit Version: 0~git20180515-62ef6b0db-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, running piglit tests with the --valgrind option gives a results file with all tests marked as skipped: "result": "skip", "command": "/usr/lib/x86_64-linux-gnu/piglit/bin/valgrind", "out": "An internal exception that should have been handled was not:\nTest executable not found.\n", Simon - -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages piglit depends on: ii libc62.28-10 ii libdrm-intel12.4.97-1 ii libdrm2 2.4.97-1 ii libegl1 1.1.0-1 ii libgbm1 18.3.6-2 ii libgcc1 1:8.3.0-6 ii libgl1 1.1.0-1 ii libstdc++6 8.3.0-6 ii libwaffle-1-01.5.2-4 ii libwayland-client0 1.16.0-1 ii libwayland-egl1 1.16.0-1 ii libx11-6 2:1.6.7-1 ii libxcb-dri2-01.13.1-2 ii libxcb1 1.13.1-2 ii libxkbcommon00.8.2-1 ii ocl-icd-libopencl1 [libopencl1] 2.2.12-2 ii python3 3.7.3-1 ii python3-mako 1.0.7+ds1-1 ii python3-six 1.12.0-1 piglit recommends no packages. piglit suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQFDBAEBCgAtFiEEtjuqOJSXmNjSiX3Tfr04e7CZCBEFAl094XsPHHNqckBkZWJp YW4ub3JnAAoJEH69OHuwmQgRztwH/ilPtSuR38jTd/69IECI+fmnLK7gNCnA11rh jAe/no1ANIDH+0jbX+v8eb9cxmzHOVfkkMToxu0Q15w/6y+j8iigS6DC4QAF5VjJ 7PjNOJFNtPyhBCvZgcXJjjw4EZVicKzMmxBfZxndmOq0zRgWA1OTizwmUxS0cwSf t7JIKg2ZP5qI1Pgzt1hNI8WQAZdztqNvcwIkA515B3kOFofUmt0xGe05AdeRs6JC JRDSd7gJ3QU3mMr668FEiw2rVe/nyvB6BtTpKJxjOAZJmvgbN1IR/Q5YP+4yRuT8 FFWR5CuC6LrcgE/S6NtbEWYdVDan0GZ1F4l/va4NHVLkWF8PM5s= =hsb0 -END PGP SIGNATURE-
Bug#830371: librevisa: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2
Hi, > override_dh_auto_test: > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) > -dh_auto_test > endif Yes, that's fine with me. I'm not even sure the conditional is needed, shouldn't dh_auto_test already look at DEB_BUILD_OPTIONS? Simon
Bug#830371: librevisa: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2
Hi, On Wed, Jul 24, 2019 at 01:30:26PM -0400, Boyuan Yang wrote: > I tried to rebuild this package in my local sbuild chroot and the result > appears to be successful. I plan to make a (no-change) NMU upload onto Sid to > see if a sourceful rebuild would solve this issue. This is an error caused by network environment. The "find" test runs both an Avahi lookup and an USB scan (but largely ignores the results, as none of the devices found during that scan matches the "DUMMY" filter), depending on the autobuilder configuration that triggers a security policy, which makes the test fail. I have no really good idea how to keep the test meaningful and stop it from failing in more restricted environments. Note that the FTBFS happened during a QA rebuild, the packages in the archive are fine, so an unchanged source NMU would not fix the problem. Simon
Bug#930682: debian-xcontrol: Remove from archive?
severity 930682 normal reassign 930682 ftp.debian.org retitle 930682 Please remove debian-xcontrol thanks Hi, On Tue, Jun 18, 2019 at 01:35:48PM +0200, Julian Andres Klode wrote: > Package: debian-xcontrol > Version: 0.0.4-1.1 > Severity: serious > There do not seem to be any users of debian-xcontrol left, > and the last update was 9 years ago, so time to let it go? Yes, I thought I had sent a request for its removal years ago. Simon
Bug#929312: wxpython4.0: Build-Depends too loose: needs sip-dev >= 4.19.1
Source: wxpython4.0 Version: 4.0.4+dfsg-2 Severity: normal Hi, while backporting to Devuan ascii, which has sip-dev 4.18.1+dfsg-2, I got a build error: Running command: sip /usr/bin/sip -w -o -g -I /tmp/wxpython4.0-4.0.4+dfsg/src -I /tmp/wxpython4.0-4.0.4+dfsg/sip/gen -c /tmp/tmpxXqdbK -b sip/cpp/_core.sbf -X pycode_core:wx/core.py sip/gen/_core.sip sip: sip/gen/display.sip:34: syntax error Command '/usr/bin/sip -w -o -g -I /tmp/wxpython4.0-4.0.4+dfsg/src -I /tmp/wxpython4.0-4.0.4+dfsg/sip/gen -c /tmp/tmpxXqdbK -b sip/cpp/_core.sbf -X pycode_core:wx/core.py sip/gen/_core.sip' failed with exit code 1. Finished command: sip (0.45s) The line in question is "%PreMethodCode", which was introduced in sip 4.19.1, so the Build-Depends need to be tightened here. Simon -- System Information: Debian Release: 9.9 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/32 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 /bin/dash Init: sysvinit (via /sbin/init)
Bug#928526: linux-image-4.19.0-4-amd64: data corruption when swapping to encrypted SSD with LVM and TRIM enabled
Hi, On 06.05.19 21:35, Simon Richter wrote: > I can probably test intermediate versions and/or changes in setup, but this > is difficult to automate because "bad" runs require manual file system > repairs and every run requires LUKS setup to be repeated. FWIW, using a separate LV and swapon --discard=pages seems to work, so this is likely to be specific to swap files (which normally shouldn't be affected by discards, as their allocation doesn't change, but the kernel might have some default behaviour here that I'm not aware of). Simon signature.asc Description: OpenPGP digital signature
Bug#928526: linux-image-4.19.0-4-amd64: data corruption when swapping to encrypted SSD with LVM and TRIM enabled
Package: src:linux Version: 4.19.28-2 Severity: grave Tags: upstream Justification: causes non-serious data loss Hi, I have an older laptop with an SSD and an encrypted LVM setup with TRIM passthrough through the crypto layers. Normally I run without swap space, but occasionally I will set up a swap file if I anticipate a need for it. I create the swap file on an encrypted partition using dd if=/dev/zero of=/home/swap bs=1G count=8 mkswap /home/swap swapon /home/swap The file system in question is ext4 in a LVM logical volume in a PV that is a LUKS volume inside a DOS partition on an SSD. The "discard" option is set in /etc/crypttab. Since upgrading from stretch to buster, processes using a lot of memory die with signal 11 (often) or 6 (seldom), typically after being swapped in. I can reproduce this rather consistently by compiling KiCad, which at one point invokes four ld processes in parallel that each take roughly 3 GB of RAM, causing some swapping: most of the time, one or two of the ld processes terminates with a segmentation fault. Switching to Firefox during that time almost certainly kills Firefox or the X server, so this seems related to swapping. I have also experienced some file system corruption on the /home partition (that needed manual repair with fsck), it is not entirely clear to me if that is coincidental or related. That partition has run without fsck for some time before, but the affected files were all created shortly before the system went into memory pressure. Other partitions were fine, but that might also be because they are not usually written to during operation. Memtest86+ reports no problems. The same setup works fine with 4.9.0-8-amd64 from stretch, so this is a regression. I can probably test intermediate versions and/or changes in setup, but this is difficult to automate because "bad" runs require manual file system repairs and every run requires LUKS setup to be repeated. Simon -- Package-specific info: ** Version: Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15) ** Command line: initrd=\7fa8c2303086c2fad03bc1be50eaac8c\4.19.0-4-amd64\initrd root=/dev/mapper/coffee-root ro quiet ** Not tainted ** Kernel log: [ 20.645047] systemd-udevd[726]: Using default interface naming scheme 'v240'. [ 20.645574] videodev: Linux video capture interface: v2.00 [ 20.646574] systemd-udevd[726]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. [ 20.647277] usbcore: registered new interface driver qcserial [ 20.647289] usbserial: USB Serial support registered for Qualcomm USB modem [ 20.647997] qcserial 1-1.5:1.0: Qualcomm USB modem converter detected [ 20.648074] usb 1-1.5: Qualcomm USB modem converter now attached to ttyUSB0 [ 20.648279] alg: No test for fips(ansi_cprng) (fips_ansi_cprng) [ 20.648800] usbcore: registered new interface driver cdc_wdm [ 20.651751] qcserial 1-1.5:1.2: Qualcomm USB modem converter detected [ 20.652053] usb 1-1.5: Qualcomm USB modem converter now attached to ttyUSB1 [ 20.653496] qcserial 1-1.5:1.3: Qualcomm USB modem converter detected [ 20.653565] usb 1-1.5: Qualcomm USB modem converter now attached to ttyUSB2 [ 20.654411] qmi_wwan 1-1.5:1.8: cdc-wdm0: USB WDM device [ 20.654574] qmi_wwan 1-1.5:1.8 wwan0: register 'qmi_wwan' at usb-:00:1a.0-1.5, WWAN/QMI device, 0a:b7:4f:bc:8b:4c [ 20.654622] usbcore: registered new interface driver qmi_wwan [ 20.655678] systemd-udevd[604]: Using default interface naming scheme 'v240'. [ 20.657076] systemd-udevd[604]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable. [ 20.657187] qmi_wwan 1-1.5:1.8 wwp0s26u1u5i8: renamed from wwan0 [ 20.667147] uvcvideo: Found UVC 1.00 device FJ Camera (04f2:b2fc) [ 20.686810] Bluetooth: Core ver 2.22 [ 20.686822] NET: Registered protocol family 31 [ 20.686823] Bluetooth: HCI device and connection manager initialized [ 20.686826] Bluetooth: HCI socket layer initialized [ 20.686827] Bluetooth: L2CAP socket layer initialized [ 20.686833] Bluetooth: SCO socket layer initialized [ 20.694365] usbcore: registered new interface driver btusb [ 20.712225] uvcvideo 1-1.6:1.0: Entity type for entity Extension 4 was not initialized! [ 20.712228] uvcvideo 1-1.6:1.0: Entity type for entity Extension 3 was not initialized! [ 20.712230] uvcvideo 1-1.6:1.0: Entity type for entity Processing 2 was not initialized! [ 20.712232] uvcvideo 1-1.6:1.0: Entity type for entity Camera 1 was not initialized! [ 20.712306] input: FJ Camera : FJ Camera as /devices/pci:00/:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/input/input19 [ 20.712362] usbcore: registered new interface driver uvcvideo [ 20.712363] USB Video Class driver (1.1.1) [ 20.717468] systemd-udevd[643]: Using default interface naming scheme 'v240'. [ 20.743958] [drm] Initialized i915
Bug#928040: lprng: fails to install
Package: lprng Version: 3.8.B-2.1 Severity: grave Justification: renders package unusable Hi, lprng fails to upgrade from stretch to buster, and also fails to install on top of itself: # LC_ALL=C dpkg -i /var/cache/apt/archives/lprng_3.8.B-2.1_amd64.deb (Reading database ... 634188 files and directories currently installed.) Preparing to unpack .../lprng_3.8.B-2.1_amd64.deb ... start-stop-daemon: matching only on non-root pidfile /var/run/lprng/lpd.515 is insecure invoke-rc.d: initscript lprng, action "stop" failed. dpkg: warning: old lprng package pre-removal script subprocess returned error exit status 1 dpkg: trying script from the new package instead ... start-stop-daemon: matching only on non-root pidfile /var/run/lprng/lpd.515 is insecure invoke-rc.d: initscript lprng, action "stop" failed. dpkg: error processing archive /var/cache/apt/archives/lprng_3.8.B-2.1_amd64.deb (--install): new lprng package pre-removal script subprocess returned error exit status 1 invoke-rc.d: initscript lprng, action "start" failed. dpkg: error while cleaning up: installed lprng package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: /var/cache/apt/archives/lprng_3.8.B-2.1_amd64.deb Simon -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages lprng depends on: ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-8 ii libcomerr2 1.44.5-1 ii libk5crypto3 1.17-2 ii libkrb5-3 1.17-2 ii libssl1.1 1.1.1b-2 ii lsb-base 10.2019031300 lprng recommends no packages. Versions of packages lprng suggests: pn lprng-doc pn magicfilter -- debconf information: lprng/setuid_tools: false lprng/start_lpd: true lprng/twolpd_conf: lprng/twolpd_perms:
Bug#819331: closed by Christian Ehrhardt (Not a bug but a support request - hint howto and close)
Hi, On Fri, Apr 05, 2019 at 04:24:14PM +, Debian Bug Tracking System wrote: > #819331: libvirt0: fails to start KVM instance using readonly ISO image > > It has been closed by Christian Ehrhardt . [...] > you can disable dynamic ownership in /etc/libvirt/qemu.conf, see [1] > for the file in the source. > There you could also overwrite the user/group that is used to do so. That is a global setting though that disables dynamic ownership completely, which is a blunt tool. > Since this is not a bug that can be fixed in the source/package we can > close it safely. There could be a separate setting for read-only media, or a per-device override in the domain.xml, the latter is probably more useful. I'm leaving the bug report closed for now, but I'd be grateful if it could be reopened. Simon > [1]: https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu.conf#L457
Bug#925370: linux-image-4.9.0-8-amd64: hangs during startup while modesetting
Package: src:linux Version: 4.9.144-3 Severity: important Tags: upstream Hi, I just tried booting my laptop with the lid closed, an HD monitor attached via DVI and an 8K monitor attached via DisplayPort. The boot process stopped in the "Waiting for /dev to be fully populated..." phase, specifically while trying to load the framebuffer driver for Intel hardware: [ 19.238056] fb: switching to inteldrmfb from EFI VGA It appears the system is unsure how to configure the outputs. I have to disconnect the 8K monitor in order to be able to boot, and leave it unplugged until after starting X to get it to work. Simon -- Package-specific info: ** Version: Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.144-3 (2019-02-02) ** Command line: initrd=\7fa8c2303086c2fad03bc1be50eaac8c\4.9.0-8-amd64\initrd root=/dev/mapper/coffee-root ro quiet ** Not tainted ** Kernel log: ** Model information sys_vendor: FUJITSU product_name: LIFEBOOK E782 product_version: 10601186020 chassis_vendor: FUJITSU chassis_version: LIFEBOOK E782 bios_vendor: FUJITSU // Phoenix Technologies Ltd. bios_version: Version 2.11 board_vendor: FUJITSU board_name: FJNB253 board_version: L3 ** Loaded modules: rfcomm ctr ccm cmac bnep cpufreq_conservative cpufreq_userspace cpufreq_powersave xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo binfmt_misc uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc nls_ascii nls_cp437 vfat fat loop lp arc4 intel_rapl ppdev snd_hda_codec_hdmi x86_pkg_temp_thermal intel_powerclamp coretemp iwldvm iTCO_wdt iTCO_vendor_support uvcvideo mac80211 videobuf2_vmalloc kvm_intel videobuf2_memops snd_hda_codec_realtek videobuf2_v4l2 snd_hda_codec_generic videobuf2_core qmi_wwan qcserial btusb cdc_wdm btrtl usb_wwan kvm videodev usbnet btbcm btintel mii media iwlwifi irqbypass snd_hda_intel bluetooth usbserial efi_pstore intel_cstate snd_hda_codec i915 intel_uncore snd_hda_core evdev intel_rapl_perf snd_hwdep joydev cfg80211 serio_raw drm_kms_helper snd_pcm efivars rtsx_pci_ms snd_timer pcspkr snd sg memstick rfkill soundcore drm mei_me mei lpc_ich shpchp i2c_algo_bit parport_pc tpm_infineon parport fujitsu_laptop battery video ac button ext4 crc16 jbd2 fscrypto ecb mbcache algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod hid_generic usbhid hid rtsx_pci_sdmmc mmc_core crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd ahci libahci psmouse libata ehci_pci i2c_i801 xhci_pci scsi_mod i2c_smbus xhci_hcd ehci_hcd rtsx_pci mfd_core e1000e ptp usbcore pps_core usb_common ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09) Subsystem: Fujitsu Limited. 3rd Gen Core processor DRAM Controller [10cf:16bf] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ivb_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Fujitsu Limited. 3rd Gen Core processor Graphics Controller [10cf:16c1] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI]) Subsystem: Fujitsu Limited. 7 Series/C210 Series Chipset Family USB xHCI Host Controller [10cf:16ee] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04) Subsystem: Fujitsu Limited. 7 Series/C216 Chipset Family MEI Controller [10cf:16ea] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:16.3 Serial controller [0700]: Intel Corporation 7 Series/C210 Series Chipset Family KT Controller [8086:1e3d] (rev 04) (prog-if 02 [16550]) Subsystem: Fujitsu Limited. 7
Bug#923528: linux-image-4.9.0-8-amd64: Intel WiFi firmware crash
Package: src:linux Version: 4.9.144-3 Severity: normal Tags: upstream Hi, we just had a power outage, and my access point disappeared without warning. Apparently, this confused the firmware enough that it crashed, and the internal reset mechanism failed as well. Unloading and reloading iwlwifi and iwldvm has helped though. Simon -- Package-specific info: ** Version: Linux version 4.9.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.144-3 (2019-02-02) ** Command line: initrd=\7fa8c2303086c2fad03bc1be50eaac8c\4.9.0-8-amd64\initrd root=/dev/mapper/coffee-root ro quiet ** Tainted: W (512) * Taint on warning. ** Kernel log: [609663.131487] iwlwifi :0a:00.0: 0x755F | beacon time [609663.131491] iwlwifi :0a:00.0: 0x00011AA1 | tsf low [609663.131494] iwlwifi :0a:00.0: 0x | tsf hi [609663.131498] iwlwifi :0a:00.0: 0x | time gp1 [609663.131502] iwlwifi :0a:00.0: 0x00011AA5 | time gp2 [609663.131505] iwlwifi :0a:00.0: 0x | time gp3 [609663.131509] iwlwifi :0a:00.0: 0x754312A8 | uCode version [609663.131513] iwlwifi :0a:00.0: 0x00B0 | hw version [609663.131517] iwlwifi :0a:00.0: 0x00488700 | board version [609663.131520] iwlwifi :0a:00.0: 0x090A0010 | hcmd [609663.131524] iwlwifi :0a:00.0: 0x00122080 | isr0 [609663.131528] iwlwifi :0a:00.0: 0x | isr1 [609663.131531] iwlwifi :0a:00.0: 0x0602 | isr2 [609663.131535] iwlwifi :0a:00.0: 0x014000C0 | isr3 [609663.131538] iwlwifi :0a:00.0: 0x | isr4 [609663.131542] iwlwifi :0a:00.0: 0x01000112 | isr_pref [609663.131546] iwlwifi :0a:00.0: 0x00024B96 | wait_event [609663.131550] iwlwifi :0a:00.0: 0x | l2p_control [609663.131554] iwlwifi :0a:00.0: 0x | l2p_duration [609663.131557] iwlwifi :0a:00.0: 0x | l2p_mhvalid [609663.131561] iwlwifi :0a:00.0: 0x | l2p_addr_match [609663.131565] iwlwifi :0a:00.0: 0x0047 | lmpm_pmg_sel [609663.131568] iwlwifi :0a:00.0: 0x06061222 | timestamp [609663.131572] iwlwifi :0a:00.0: 0x00540810 | flow_handler [609663.131652] iwlwifi :0a:00.0: Start IWL Event Log Dump: nothing in log [609663.131721] iwlwifi :0a:00.0: FW error in SYNC CMD REPLY_RXON [609663.131730] CPU: 4 PID: 30543 Comm: ip Tainted: GW 4.9.0-8-amd64 #1 Debian 4.9.144-3 [609663.131732] Hardware name: FUJITSU LIFEBOOK E782/FJNB253, BIOS Version 2.11 07/15/2014 [609663.131735] a0f34524 89a393ac0018 af8f09e875d0 [609663.131740] c0b62c2d 89a3 89a296c11080 a0cbd350 [609663.131744] af8f09e87580 af8f09e87580 fdb809a3b981ce0c 89a38d3d9528 [609663.131749] Call Trace: [609663.131759] [] ? dump_stack+0x5c/0x78 [609663.131772] [] ? iwl_trans_pcie_send_hcmd+0x3cd/0x4e0 [iwlwifi] [609663.131777] [] ? prepare_to_wait_event+0xf0/0xf0 [609663.131786] [] ? iwl_dvm_send_cmd_pdu+0x53/0x70 [iwldvm] [609663.131793] [] ? iwlagn_commit_rxon+0x318/0xad0 [iwldvm] [609663.131799] [] ? iwl_dvm_send_cmd_pdu+0x53/0x70 [iwldvm] [609663.131805] [] ? iwl_alive_start+0x213/0x310 [iwldvm] [609663.131811] [] ? iwlagn_mac_start+0x12d/0x1d0 [iwldvm] [609663.131838] [] ? drv_start+0x40/0x100 [mac80211] [609663.131861] [] ? ieee80211_do_open+0x2ad/0x990 [mac80211] [609663.131882] [] ? ieee80211_check_concurrent_iface+0x11a/0x1e0 [mac80211] [609663.131887] [] ? __dev_open+0xc8/0x140 [609663.131892] [] ? __dev_change_flags+0x9c/0x160 [609663.131896] [] ? dev_change_flags+0x23/0x60 [609663.131899] [] ? do_setlink+0x32c/0xd60 [609663.131904] [] ? list_del+0x9/0x30 [609663.131908] [] ? page_is_poisoned+0xa/0x20 [609663.131912] [] ? get_page_from_freelist+0x8f0/0xb20 [609663.131917] [] ? rtnl_newlink+0x5d2/0x880 [609663.131923] [] ? mem_cgroup_oom_synchronize+0x320/0x340 [609663.131927] [] ? kmem_cache_alloc+0x11c/0x530 [609663.131931] [] ? memcg_kmem_get_cache+0x50/0x160 [609663.131935] [] ? cap_inode_killpriv+0x20/0x20 [609663.131938] [] ? security_capable+0x47/0x60 [609663.131942] [] ? rtnetlink_rcv_msg+0xe7/0x220 [609663.131946] [] ? kmem_cache_alloc_node+0x13e/0x530 [609663.131950] [] ? rtnl_newlink+0x880/0x880 [609663.131954] [] ? netlink_rcv_skb+0xa4/0xc0 [609663.131958] [] ? rtnetlink_rcv+0x24/0x30 [609663.131961] [] ? netlink_unicast+0x18a/0x230 [609663.131964] [] ? netlink_sendmsg+0x357/0x3b0 [609663.131969] [] ? sock_sendmsg+0x36/0x40 [609663.131972] [] ? ___sys_sendmsg+0x2c8/0x2e0 [609663.131976] [] ? __alloc_pages_nodemask+0xf6/0x260 [609663.131981] [] ? mem_cgroup_commit_charge+0x78/0x4b0 [609663.131985] [] ? handle_mm_fault+0xcd8/0x1310 [609663.131989] [] ? __sys_sendmsg+0x51/0x90 [609663.131993] [] ? do_syscall_64+0x8d/0xf0 [609663.131997] [] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6 [609663.132002] iwlwifi :0a:00.0: Error clearing ASSOC_MSK on BSS (-5) [609663.135902] iwlwifi :0a:00.0: Unable to
Bug#776766: closed by brl...@debian.org (Bernhard R. Link) (Bug#776766: fixed in ratpoison 1.4.9-1)
Hi Bernhard, On 02.02.19 10:09, Debian Bug Tracking System wrote: > #776766: ratpoison: needs handling for monitor hotplug > It has been closed by brl...@debian.org (Bernhard R. Link). Thanks! Simon signature.asc Description: OpenPGP digital signature
Bug#917134: opencl-c-headers: Prototype for clCreateFromGLBuffer should use cl_int, not int for error return
Package: opencl-c-headers Version: 2.1-1 Severity: minor Tags: upstream Hi, the signature for clCreateFromGLBuffer in uses "int *" for error return, while the specification uses "cl_int *". These are usually the same type, so minor. Simon -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) -- no debconf information
Bug#914598: ITP: ethereal -- UCI-compliant chess engine
Hi, On 25.11.18 15:52, Jose G. López wrote: > * Package name: ethereal Be aware that wireshark used to be called ethereal in the old days. It is long enough I believe that you don't need to do anything special, but the current wireshark package still has Conflicts: ethereal (<< 1.0.0-3) Replaces: ethereal (<< 1.0.0-3) for this reason, and some people may be confused about that. Simon signature.asc Description: OpenPGP digital signature
Bug#914504: enigmail: asks to trust EVIL32 key
Package: enigmail Version: 2:2.0.8-5~deb9u1 Severity: normal Tags: upstream Hi, there is an EVIL32 key for my name, which I have in my keyring as untrusted, and I don't have the secret key for it. Enigmail occasionally pops up requests to assign ultimate trust to this key. The 32 bit keyid is the same as my regular key, which would be default for signing. Simon -- System Information: Debian Release: 9.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages enigmail depends on: ii gnupg 2.1.18-8~deb9u3 ii gnupg-agent2.1.18-8~deb9u3 ii icedove1:60.3.0-1~deb9u1 ii thunderbird [icedove] 1:60.3.0-1~deb9u1 Versions of packages enigmail recommends: ii pinentry-gtk2 [pinentry-x11] 1.0.0-2 enigmail suggests no packages. -- no debconf information
Bug#909282: Asserts
Hi, I wonder why asserts are shown at all -- supposedly this is a Release build? Is this a wx problem perhaps? Simon
Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload
Hi, pulling gnupg or enigmail from backports would only solve the problem for new installations, but doesn't help users who have both thunderbird and enigmail installed, only have stretch and stretch-security in the sources.list (what I'd expect to be the majority) and are now trying to run "apt upgrade": Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages have been kept back: icedove lightning thunderbird 0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded. So this is blocking security upgrades. Simon signature.asc Description: OpenPGP digital signature
Bug#906060: Coordinate overflow when rendering
Package: kicad,libwxgtk3.0-gtk3-0v5,libcairo2,libpixman-1-0 Severity: important Hi, this bug is difficult to pin down to a specific package. KiCad uses the graphics context from wxWidgets for rendering in the schematic editor (which somewhat works) and the PCB editor (which fails utterly). When wxWidgets is linked against GTK 3, it uses a Cairo context for rendering, as is proper for GTK 3. Cairo is given appropriate coordinates (as doubles) for a path, into a zoomed(!) canvas. The logical coordinates used are dependent on the current zoom level, and the scaling factor between device and logical coordinates is somewhere between 1:50 and 1:30. Depending on zoom level, different failure modes can be observed, but there is no zoom level at which the rendering is correct. At some levels, something resembling the correct output can be seen, but as if the coordinates were wrapped modulo a certain number. Short video is at http://psi5.com/~geier/overflow.ogv This can be reproduced best by compiling KiCad with libwxgtk3.0-gtk3-dev installed, running "pcbnew" and switching to "legacy" canvas. Quick debugging has shown that the coordinates given to Cairo still make sense, even if the zoom level makes them numerically large. As I'd need significant time to debug into optimized drawing routines, I'd like to pass this on. I suspect that this is mostly an interaction between Cairo and Pixman, with an overflow happening somewhere in a conversion from double to an integer type. This is a major showstopper for linking KiCad 5 against GTK3, so this requires us to keep GTK2 around longer. Simon -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-7-amd64 (SMP w/40 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 /bin/dash Init: systemd (via /run/systemd/system)
Bug#904917: general: Gnome randomly crash and restart to login.
reassign 904917 gnome-shell retitle 904917 gnome-shell: segmentation fault thanks Hi, On 05.08.2018 23:54, Carl-Valentin Schmitt wrote: > Is this a machine with nvidia graphics card and nvidia drivers? Unlikely that this is the problem, the crash address was somewhere in libgobject, which the nV drivers don't use directly. I've reassigned the bug to the "gnome-shell" package, the maintainers there should know better how to debug this further. The address being dereferenced looks suspiciously like ASCII data, "x74f4f". Note that the bug submitter has mentioned that he won't have time until end of August. Simon signature.asc Description: OpenPGP digital signature
Bug#904917: general: Gnome randomly crash and restart to login.
Hi, On 04.08.2018 01:32, Riccardo Gagliarducci wrote: > after firmware update it still happens ~once a day, > still without doing anything particular. Is anything listed in the kernel log? After a crash, log back in, then, as root: # cat /proc/uptime The first number is the number of seconds the system is running. # dmesg This will dump the kernel logfile to the console. At the beginning of each line is a timestamp. The uptime you got earlier gives you a rough estimate which lines are recent, these have a good chance of being related. Simon signature.asc Description: OpenPGP digital signature
