Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

On 2022-09-28 5:30 PM, Ansgar wrote: On Wed, 2022-09-28 at 16:40 -0400, Zack Weinberg wrote: "Available and usable at all times" is orthogonal to "maintainer scripts do not render the system unbootable".  As I read things, *all* packages bear the responsibility of not

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

On 2022-09-28 3:06 PM, Ansgar wrote: On Wed, 2022-09-28 at 14:54 -0400, Zack Weinberg wrote: On 2022-09-28 2:40 PM, Ansgar wrote: If I thought there was a bug in some other package that posed a significant risk of rendering Debian systems unbootable on upgrade, I would have filed a report

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

On 2022-09-28 2:16 PM, Marco d'Itri wrote: it appears to be possible for the next boot to find the root filesystem in a state where /lib or /bin doesn’t exist at all. Recovery from this state will require booting from installation media. This is technically correct. But after 8 years of

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

On 2022-09-28 2:04 PM, Ansgar wrote: On Wed, 2022-09-28 at 13:53 -0400, Zack Weinberg wrote: On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote: No, you would need to atomically replace the *entire* system, not just individual directories. ??? Atomic replacement of each affected directory

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

On 2022-09-28 2:16 PM, Russ Allbery wrote: "Zack Weinberg" writes: 1. Is there already a rule (or multiple rules) somewhere that forbids the existence of pairs of packages where one ships /X/Y and the other ships /usr/X/Y, where X is a directory on non-merged-/usr

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

On Wed, Sep 28, 2022, at 1:47 PM, Ansgar wrote: > No, you would need to atomically replace the *entire* system, not just > individual directories. ??? Atomic replacement of each affected directory is, as far as I can see, both necessary and sufficient to prevent the system being rendered

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

On Wed, Sep 28, 2022, at 1:40 PM, Helmut Grohne wrote: > Hi Zack, > > On Wed, Sep 28, 2022 at 12:29:19PM -0400, Zack Weinberg wrote: >> I thought about this a bunch yesterday evening and I believe I see a >> concrete scenario that can cause problems but is not covered by the &

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

On Wed, Sep 28, 2022, at 5:08 AM, Svante Signell wrote: > > You can easily revert any system having usrmerge installed with dpkg- > fsys-usrunmess. This should be known by all Debian users, by some > suitable channel. Having used it myself a couple of times, I would question "easily". If all

Bug#1020922: usrmerge: please split convert-* scripts into separate package from the postinst that actually performs the conversion

Source: usrmerge Version: 31 Severity: wishlist X-Debbugs-Cc: z...@owlfolio.org It would be significantly easier to experiment with convert-usrmerge under exotic conditions if the scripts were installable without also pulling the postinst that performs the conversion. -- System Information:

Bug#1020920: usrmerge: if "the system crashes at a really bad time" during conversion it may be left unbootable

Package: usrmerge Version: 31 Severity: critical Justification: breaks the whole system X-Debbugs-Cc: z...@owlfolio.org convert-usrmerge is nominally idempotent and restartable, but (as it says in the script’s own documentation) if “the system crashes at a really bad time” during the conversion

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

On Tue, Sep 27, 2022, at 4:12 PM, Sebastian Ramacher wrote: > On 2022-09-27 10:26:36 -0400, Zack Weinberg wrote: >> On Tue, Sep 27, 2022, at 5:15 AM, Sebastian Ramacher wrote: >> >> I'd like to make sure that the bug submitter has not identified >> >> something

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

On Tue, Sep 27, 2022, at 12:25 PM, Andreas Metzler wrote: > On 2022-09-27 Zack Weinberg wrote: > [...] >> What I am asking for is a schedule change: specifically, that the >> merged /usr transition not be allowed to proceed past the status quo >> as of two weeks ago (i

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

On Tue, Sep 27, 2022, at 5:15 AM, Sebastian Ramacher wrote: >> I'd like to make sure that the bug submitter has not identified >> something new here. > > I've not seen any new issues appearing since the last round I file bugs. I wasn’t aware that you have been filing bugs related to the

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

On Tue, Sep 27, 2022, at 4:23 AM, Matthew Vernon wrote: > Thanks for bringing this to the committee; even if Sean is correct that > we won't act on this report, you've described the issues clearly and I > think it was worth bringing to our attention. Thank you for saying so. > As Sean says,

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

[Procedural note: I’m very busy with my day job this week, so I will be responding to messages related to this report in batch mode, once a day.] On Mon, Sep 26, 2022, at 4:49 PM, Sam Hartman wrote: >> "Sean" == Sean Whitton writes: > > Sean> - you might be lacking the full context of

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

On Mon, Sep 26, 2022, at 4:30 PM, Sean Whitton wrote: > I believe that this request is invalid, for two reasons: > > - the specific things you ask for are all or mostly things that we think > are currently up to the Release Team, and the TC cannot override > delegates I'm surprised to hear

Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed

Package: tech-ctte Severity: normal X-Debbugs-Cc: z...@owlfolio.org I formally request that the Technical Committee call a halt to the merged-/usr transition until such time as all of the bugs in dpkg that can, on a merged-/usr system, cause damage to the contents of the filesystem (e.g. packaged

Bug#1009277: gnome-weather: background service ImportError on login

Package: gnome-weather Version: 42.0-1 Severity: normal X-Debbugs-Cc: za...@panix.com Upon logging in I get these error messages in the user journal: Apr 10 16:51:27 moxana org.gnome.Weath[5211]: ImportError: Unable to load file from: resource:///org/gnome/Weather/js/service/main.js

Bug#1005128: nmu: hugin_2021.0~beta1+dfsg-1

On Mon, Feb 7, 2022, at 12:13 PM, Sebastian Ramacher wrote: > This is currently not possible. See #1003547 Ah, thank you. I didn't find that bug because I was only looking at https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=hugin, not at

Bug#1005128: nmu: hugin_2021.0~beta1+dfsg-1

Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: za...@panix.com nmu hugin_2021.0~beta1+dfsg-1 . ANY . unstable . -m "Rebuild against libgsl27" hugin is currently built against libgsl25 and therefore is uninstallable in

Bug#1003653: Revision of removal of rename.ul from package util-linux

As an end user I wish to register an objection to any solution to this bug that makes it impossible for me to install a Debian system where, out of the box, "rename" in the default PATH is the Perl rename. This is what my fingers expect, and what dozens of non-packaged scripts rely on. (I say

Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

As a Debian user I'm pleased to see the ctte taking proactive steps to ensure that the merged-/usr transition will still allow smooth upgrades from Debian 11 to 12 and 12 to 13. As an upstream contributor to several pieces of software included in Debian, and as someone with an interest in

Bug#991185: systemd: 'systemctl start anacron.service' from emergency mode kills emergency shell

On Wed, Jul 21, 2021 at 9:46 AM Michael Biebl wrote: > When emergency mode is triggered (either by a boot failure or adding > emergency to the kernel command line), emergency.target is started and > emergency.service as a result of it. > > sysinit.target has "Conflicts=emergency.service

Bug#991185: systemd: 'systemctl start anacron.service' from emergency mode kills emergency shell

On Tue, Jul 20, 2021 at 8:00 AM Michael Biebl wrote: > Am 16.07.21 um 21:09 schrieb Zack Weinberg: > > Package: systemd > > Version: 247.3-5 > > Severity: important > > X-Debbugs-Cc: za...@panix.com > > > > Running ‘systemctl start anacron.servi

Bug#991190: dpkg-fsys-usrunmess: block service activation with policy-rc.d?

On Sat, Jul 17, 2021 at 12:51 PM Guillem Jover wrote: > On Fri, 2021-07-16 at 15:23:01 -0400, Zack Weinberg wrote: > > As a stopgap safety measure, I suggest that dpkg-fsys-usrunmess should > > use policy-rc.d to block all service activation while it’s running. > > Hmm, r

Bug#991192: dpkg-fsys-usrunmess: should be restartable

Package: dpkg Version: 1.20.9 Severity: wishlist File: /usr/sbin/dpkg-fsys-usrunmess X-Debbugs-Cc: za...@panix.com I tried to run dpkg-fsys-usrunmess from systemd’s emergency mode, thinking that this would be safer, since nothing else would be running. This tickled a bug in systemd (see #991185)

Bug#991190: dpkg-fsys-usrunmess: block service activation with policy-rc.d?

Package: dpkg Version: 1.20.9 Severity: normal File: /usr/sbin/dpkg-fsys-usrunmess X-Debbugs-Cc: za...@panix.com I tried to run dpkg-fsys-usrunmess from systemd’s emergency mode, thinking that this would be safer, since nothing else would be running. This tickled a bug in systemd (see #991185)

Bug#989808: fonts-linuxlibertine: Newer Libertine fonts available from CTAN

Package: fonts-linuxlibertine Version: 5.3.0-6 Severity: important X-Debbugs-Cc: za...@panix.com, debian-tex-ma...@lists.debian.org The Libertine font project ceased to make new releases circa 2012 (you will probably already have noticed that the debian/watch file is pinging a location that no

Bug#985372: [hel...@subdivi.de: Bug#985372: libxcrypt FTCBFS: glibc version detection inspects build architecture libc]

Merged as 86d1e4e3815fa6c47613bda86820ee50e41ebd11, thank you for the patch. It's good to know someone is testing cross compilation. zw

Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

On Tue, Mar 2, 2021 at 4:30 AM Matthias Klose wrote: > On 2/16/21 5:34 PM, Zack Weinberg wrote: > > Unpackaged Python-2-only software > > will continue to exist indefinitely—I am *certain* that I will still > > need a Python 2 interpreter ten years from now,

Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

On Wed, Feb 17, 2021 at 3:17 PM Dimitri John Ledkov wrote: > In Bullseye release file:/usr/bin/python is not reserved, but > intentionally unused. That is not good enough. It needs to be reserved. > In Bullseye release neither deb:python2 nor deb:python3 packages own > /usr/bin/python. Yes, I

Bug#982925: libgtk: print dialog lists autodetected printer twice

Package: libgtk-3-0 Version: 3.24.24-1 Severity: normal Tags: upstream X-Debbugs-Cc: za...@panix.com I have only one printer, a network-attached Brother HL model. CUPS autodetects it somehow and creates a queue for it: $ lpstat -e Brother_HL_L2350DW_series This queue shows up twice in the GTK

Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

Source: what-is-python Version: 3.8.6-3 Severity: critical Justification: breaks unrelated software X-Debbugs-Cc: za...@panix.com Any system where the unqualified command names ‘python’ and/or ‘python-config’, or the well-known pathname /usr/bin/python, refer to Python 3, is misconfigured. These

Bug#973432: additional

All of the missing environment variables are present in the output of `systemctl --user show-environment` run from a gnome-terminal window, so the problem *might* just be that emacs.service is getting started too early, in which case it could probably be fixed with some After= directives, but I

Bug#973432: emacs: When run as a systemd user service, emacs does not pick up environment settings from the desktop

Package: emacs Version: 1:27.1+1-2 Severity: normal Tags: a11y upstream X-Debbugs-Cc: za...@panix.com I’ve been experimenting with running emacs as a systemd “user service”, which is an upstream-supported configuration (see /usr/lib/systemd/user/emacs.service). I use GNOME for my desktop. At

Bug#972951: Fwd: Bug#972951: lintian should accept arbitrary files in /usr/share/gocode/**/testdata

On Mon, Oct 26, 2020 at 11:33 AM Felix Lechner wrote: > On Mon, Oct 26, 2020 at 7:48 AM Zack Weinberg wrote: > > > > Go library packages bundle their own test suites, which may include > > arbitrary data files; > > Which package are you working on, please? We cann

Bug#970393: RFP: shfmt -- Shell script formatter

I would like to endorse this RFP; I was about to file one for it myself. shfmt can be used as a more powerful alternative to `sh -n`, able to detect use of bashisms in scripts that are supposed to be POSIX-only. And it has an option to dump out its parse tree as JSON, which could make life easier

Bug#972951: lintian should accept arbitrary files in /usr/share/gocode/**/testdata

Package: lintian Version: 2.99.0 Severity: wishlist Go library packages bundle their own test suites, which may include arbitrary data files; these files are always in a nested subdirectory of /usr/share/gocode named “testdata”. Lintian should ignore such files. I tripped over this as a false

Bug#972871: git-el: .el files not installed / byte-compiled

Package: git-el Version: 1:2.28.0-1 Severity: grave Justification: renders package unusable While updating my emacs configuration for 27.1 (now in unstable) I noticed that /etc/emacs/site-start.d/50git-core.el prints git removed but not purged, skipping setup and does not autoload either git.el

Bug#934738: Experimental gettext 0.21 packages available

Work I'm doing on Autoconf is now also blocked by the out-of-date gettext in Debian, for reasons too tedious to get into, so I've prepared experimental packages of gettext 0.21. Get them from https://research.owlfolio.org/scratchpad/debian -- this URL should work as an apt source line, but beware

Bug#969973: lintian: Please emit dh-exec-useless-usage only when none of the lines needs dh-exec

Package: lintian Version: 2.96.0 Followup-For: Bug #969973 I just tripped over this as well. In my case I am specifically using dh-exec only for filter-build-profiles, but lintian complains anyway: #! /usr/bin/dh-exec --with-scripts=filter-build-profiles

Bug#970920: lintian: spurious no-dh-sequencer with build profile conditionals

Package: lintian Version: 2.95.0 Severity: normal lintian fails to recognize this debian/rules construct as use of the dh sequencer: %: ifeq ($(DEB_BUILD_PROFILE),stage1) dh $@ -Npackage-doc else dh $@ endif This functionally equivalent construct *is* recognized: DH_OPTIONS =

Bug#961875: r-cran-dplyr: please package version 1.0.0

Package: r-cran-dplyr Version: 0.8.5-1+b1 Severity: normal Per https://cran.r-project.org/web/packages/dplyr/index.html the current version of dplyr is 1.0.0; the most recent packaged version is 0.8.5. Version 1.0.0 adds some valuable new features such as the ability to create multiple new

Bug#941991: gnome-shell: crashes on startup (Wayland only) with "JS ERROR: TypeError: actor.get_meta_window(...) is null"

On Sun, Apr 12, 2020 at 7:57 AM Simon McVittie wrote: > On Tue, 08 Oct 2019 at 13:59:12 -0400, Zack Weinberg wrote: > > On my computer, after upgrading to gnome-shell 3.34, I consistently get a > > gnome-shell catastrophic failure about 10 seconds after logging in, but only > &g

Bug#949980: libgl1-mesa-dri: SIGSEGV in rockchip_dri.so when running Gnome/GTK

Package: libgl1-mesa-dri Followup-For: Bug #949980 This bug is still present with the libgl1-mesa-dri in unstable (currently 19.3.3-1), but upgrading the following set of packages to the version in experimental (currently 20.0.0-1) fixes it for me: libegl-mesa0 libgbm1 libgl1-mesa-dri

Bug#941991: gnome-shell: crashes on startup (Wayland only) with "JS ERROR: TypeError: actor.get_meta_window(...) is null"

Package: gnome-shell Version: 3.34.0-2 Severity: grave Justification: renders package unusable On my computer, after upgrading to gnome-shell 3.34, I consistently get a gnome-shell catastrophic failure about 10 seconds after logging in, but only when running under Wayland. This error appears in

Bug#941990: displaycal-apply-profiles needs python-dbus

Package: displaycal Version: 3.8.7.1-1 Severity: normal The displaycal package has no dependency on (python-)dbus, but its script /usr/bin/displaycal-apply-profiles crashes on startup if the dbus module is not available: Traceback (most recent call last): File

Bug#930380: calligraflow: crash on startup (when run under gnome?)

Package: calligraflow Version: 1:2.9.11+dfsg-4+b1 Severity: important calligraflow crashes on startup - possibly only when run under a GNOME desktop session and/or with KDE persistent state not properly initialized, since a stack trace fingers the KDE most-recently-used-files implementation.

Bug#925149: emacs-gtk: next-error painfully slow on glibc build logs

Package: emacs-gtk Version: 1:26.1+1-3.2 Severity: normal File: /usr/bin/emacs-gtk In Emacs 26, compilation-mode has become painfully slow to scan for the next error, when applied to the build logs typically produced by GNU libc. As I am one of GNU libc's upstream maintainers, this is a pretty

Bug#922106: /usr/bin/vim.tiny: flood of E319 errors on startup

Package: vim-tiny Version: 2:8.1.0875-1 Severity: normal File: /usr/bin/vim.tiny When /usr/bin/vim.tiny is invoked with no special options (in particular, without -u NONE or -u NORC) it immediately spews a flood of E319 error messages: Error detected while processing

Bug#920376: lintian: Add a check for binaries using obsolete DES encryption

rom d79acb92725ef2ddbc2b33eba62a4e7b7f361a3d Mon Sep 17 00:00:00 2001 From: Zack Weinberg Date: Thu, 24 Jan 2019 15:40:26 -0500 Subject: [PATCH] Add a check for binaries using obsolete DES encryption. libcrypt.so.1 (part of glibc) used to provide a set of functions that allowed raw use of the DES block cip

Bug#920361: cairo-dock-core: uses DES encryption for password storage

Package: cairo-dock-core Version: 3.4.1-3 Severity: important Tags: security upstream While looking into something else I noticed that cairo-dock is using single DES encryption (via the C library functions setkey() and encrypt()) to store passwords: see

Bug#912909: dh-python: crashes when run under reprotest

Package: dh-python Version: 3.20180927 Severity: normal Tags: patch I tried to use reprotest on a Python module that is built using pybuild, and it blew up deep inside the guts of dh_python2: dh_python2 -O--buildsystem=pybuild I: dh_python2 fs:329: renaming _MeCab.so to

Bug#909699: emacs-gtk: crash on rendering Kannada script

Package: emacs-gtk Version: 1:25.2+1-11 Severity: important File: /usr/bin/emacs-gtk If Emacs is displaying its own window (as opposed to running inside a terminal), visiting the attached text file will cause emacs to segfault. The file is a cut-down version of

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

Yes, that is correct: ii emacs 1:25.2+1-11 ii emacs-bin-common 1:25.2+1-11 ii emacs-common 1:25.2+1-11 ii emacs-gtk 1:25.2+1-11 ii emacsen-common3.0.2 See my other message: this appears to be a problem with upgrades from the pre-ELPA versions of the ESS

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

Additionally, if I start Emacs with --no-site-file --no-init-file, M-x R is initially not a valid command, but if I do M-x package-initialize, M-x R becomes available ... and still throws the same error. In that case, *Messages* contains For information about GNU Emacs and the GNU system, type

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

Thinking about this some more, C-h v keeps telling me that the bad value for ess-etc-directory is coming from ess-site.el even though the string 'ess-etc-directory' does not appear in ess-site.el. So I got suspicious. $ find / -name 'ess-site.el*' -ls 2> /dev/null 33614087 4 -rw-r--r-- 1

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

> I _cannot_ reproduce that right now in a pristine testing/unstable session > running off Docker's r-base container (which I co-maintain): ... > Exactly _how_ do you launch the R session leading to the error? I get the error just by doing M-x R in a freshly started emacs session, on two

Bug#907977: python-minimal: please consider adding argparse to minimal modules

Package: python-minimal Version: 2.7.15-3 Severity: wishlist I am one of the upstream maintainers of GNU libc. We are considering starting to use Python for scripts run during the build. This obviously adds some version of Python to the set of packages that need to be built early in the process

Bug#907976: python3-minimal: please consider adding argparse to minimal modules

Package: python3-minimal Version: 3.6.6-1 Severity: wishlist I am one of the upstream maintainers of GNU libc. We are considering starting to use Python for scripts run during the build. This obviously adds some version of Python to the set of packages that need to be built early in the process

Bug#907893: elpa-ess: R-initialize-on-start looks for .load.R in the wrong place

Package: elpa-ess Version: 17.11-5 Severity: normal When you start an R process from inside ESS, it's supposed to load a file ".load.R" that, among other things, sets it up so C-c C-v works. R-initialize-on-start is looking for this file in the wrong place. I get these error messages in

Bug#906517: ess: doesn't load, "Package ess not fully installed. Skipping setup" in *Messages*

I installed that package over 17.11-2 and ESS is now loading correctly with no manual intervention required. Thanks for the quick fix!

Bug#906517: ess: doesn't load, "Package ess not fully installed. Skipping setup" in *Messages*

On Fri, Aug 17, 2018 at 4:35 PM, Dirk Eddelbuettel wrote: > Ack. Can you check if invoking emacsen-install differently, or updating it, > would help? > > The postinst should still have > > if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = > "abort-deconfigure" ] || [ "$1" =

Bug#906517: ess: doesn't load, "Package ess not fully installed. Skipping setup" in *Messages*

Package: ess Version: 17.11-2 Severity: normal With the current packaging of Emacs 25.2.2 in unstable, ess doesn't get loaded as it ought to. I believe this is fallout from the Emacs maintainers dropping the version number from the packages (as of 'emacs' package version 1:25.2+1-7). On

Bug#878943: with mutter 2.26.2, this only affects gnome-terminal anymore

reassign 878943 gnome-terminal quit mutter version 3.26.2 seems to have corrected the problem for *most* graphical programs -- but not for gnome-terminal. I am therefore reassigning this bug to gnome-terminal.

Bug#878943: mutter: 2.26 regression: one-dimensional window maximize no longer possible

Package: mutter Version: 3.26.1-5 Severity: normal With the GNOME 2.26 mutter, one-dimensional window maximize no longer works correctly. Specifically, if you set one of the "titlebar actions" in gnome-tweak-tool's "windows" tab to either "toggle maximize vertically" or "toggle maximize

Bug#877667: firmware-realtek: please add RTL8812 firmware (rtl8812aefw.bin & rtl8812aefw_wowlan.bin)

Package: firmware-realtek Version: 20170823-1 Severity: normal Tags: upstream This PCI WiFi card... 05:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8812AE 802.11ac PCIe Wireless Network Adapter [10ec:8812] (rev 01) Subsystem: TRENDnet RTL8812AE 802.11ac PCIe

Bug#865442: correction: errno is special, python is not the problem

Control: retitle -1 gdb: x86-64: "cannot find thread-local variables on this target" Further experimentation indicates that this is a problem with thread-local variables in general and there's something special about 'errno' that makes it appear to work; the Python interface is not the problem.

Bug#865442: gdb: "cannot find thread-local storage" from Python, not from CLI

Package: gdb Version: 7.12-6 Severity: normal Tags: upstream Attempting to read thread-local variables (e.g. errno) from the Python interface fails with "Cannot find thread-local storage", but reading the same variable from the (gdb) prompt works. Transcript: $ cat test.c #include #include

Bug#863914: linux-libc-dev: Install separate from /usr/include

On Sat, Jun 3, 2017 at 5:05 PM, Ben Hutchings wrote: >> It would be much easier to arrange >> this if the kernel's headers were installed in a location separate from >> /usr/include and then symlinked into /usr/include. (It would be fine to >> symlink just the directories.)

Bug#863914:

Upstream patch submission: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1411004.html

Bug#863914: linux-libc-dev: Install separate from /usr/include

Package: linux-libc-dev Version: 4.11-1~exp2 Severity: wishlist Certain low-level programs and libraries, notably glibc, would like to be able to make sure that they do *not* use any system headers during their build, other than the kernel's headers and the ones provided by the compiler

Bug#863909: linux/a.out.h: should use #ifdef __linux__ not #ifdef linux, etc

Package: linux-libc-dev Version: 4.11-1~exp2 Severity: normal File: /usr/include/linux/a.out.h Tags: upstream, patch linux/a.out.h contains a number of uses of "deprecated system-specific predefined macros" that will not be defined when the compiler is used in a strict conformance mode, see

Bug#844453: upstream report

Filed https://github.com/systemd/systemd/issues/5659

Bug#844453: apt-daily.service delays startup by more than five minutes

On Mon, Mar 27, 2017 at 6:14 PM, Julian Andres Klode <j...@debian.org> wrote: > On Mon, Mar 27, 2017 at 12:15:38PM -0400, Zack Weinberg wrote: >> >> Well, it _is_ run at boot, and in fact _blocks_ boot, so I don't see >> specifying that it should run within an

Bug#844453: apt-daily.service delays startup by more than five minutes

On Mon, Mar 27, 2017 at 10:49 AM, Julian Andres Klode <j...@debian.org> wrote: > On Mon, Mar 27, 2017 at 10:12:59AM -0400, Zack Weinberg wrote: >> >> I believe an appropriate fix for this bug would be to change >> apt-daily.timer so that systemd does not attempt to

Bug#844453: apt-daily.service delays startup by more than five minutes

Package: apt Version: 1.4~rc2 Followup-For: Bug #844453 I believe an appropriate fix for this bug would be to change apt-daily.timer so that systemd does not attempt to run APT daily background processing during boot-up, but only some time afterward. An appropriate configuration would be similar

Bug#158969: autoconf: AC_SYS_LARGEFILE documentation misleading

On Wed, Jan 25, 2017 at 2:06 PM, Eric Blake wrote: > > I also think we can try harder to point out the need for config.h to > appear first. How about the following counter-proposal: ... If we're going to warn people about this in the context of specific macros we should do

Bug#852617: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

On Wed, Jan 25, 2017 at 1:02 PM, Thorsten Glaser <t.gla...@tarent.de> wrote: > On Wed, 25 Jan 2017, Zack Weinberg wrote: > >> As far as I can tell from the Git history, AC_SYS_LARGEFILE has >> *always* used AC_DEFINE_UNQUOTED to define the various preprocessor >

Bug#852617: autoconf: AC_SYS_LARGEFILE should output to CPPFLAGS

On Wed, Jan 25, 2017 at 12:21 PM, Thorsten Glaser wrote: > > Would you at least *consider* moving the definition back to some > command line argument? (Changing severity to wishlist now; if not, > we can likely close the bug, but I’d still like you to please at > least

Bug#850074: systemd: "Freezing execution" mode breaks batch upgrades

On Tue, Jan 3, 2017 at 4:29 PM, Michael Biebl wrote: > Aha, thanks a lot for the reproducer. This helps a lot! > > Will forward this issue upstream. daemon-reexec should handle the case > of a full /run more gracefully. Thanks. When you do that, please also mention that

Bug#850074: systemd: "Freezing execution" mode breaks batch upgrades

On Tue, Jan 3, 2017 at 3:55 PM, Michael Biebl <bi...@debian.org> wrote: > Am 03.01.2017 um 21:41 schrieb Zack Weinberg: >> >> I don't expect I will be able to reproduce the situation until the >> next time the systemd package is updated. However, I recall this >>

Bug#850074: systemd: "Freezing execution" mode breaks batch upgrades

On Tue, Jan 3, 2017 at 3:19 PM, Michael Biebl wrote: >> An ideal fix would be for systemd to support seamless upgrades of itself, >> i.e. pid 1 would re-exec itself using the new binary, without losing >> any state. > > Well, that's actually what's already happening. In postinst

Bug#850074: systemd: "Freezing execution" mode breaks batch upgrades

Package: systemd Version: 232-8 Severity: normal When the systemd package is upgraded, the running instance of systemd is likely to go into 'freezing execution' mode, in which it is unresponsive to D-Bus requests until the computer is rebooted. If a daemon package is being upgraded at the same

Bug#740208: systemd: encountered with /dev/disk/by-uuid as well

On Mon, Dec 19, 2016 at 12:33 AM Michael Biebl <bi...@debian.org> wrote: > On Thu, 18 Sep 2014 11:46:49 -0400 Zack Weinberg <za...@panix.com> wrote: > > > I've just tripped over the same bug with the latest systemd. > > Is that still an issue on an up-to-date sid/

Bug#843532:

I can now confirm that the problem I was having is solved. I don't use all the functionality of dnssec-trigger, though. I would have appreciated your waiting at least another 48 hours before assuming I had no further complaints. zw

Bug#843532: dnssec-trigger: broken by OpenSSL 1.1.0

Package: dnssec-trigger Version: 0.13~svn685-6 Severity: critical Justification: renders package unusable On upgrading dnssec-trigger within unstable, the postinst fails with errors from systemd: Setting up dnssec-trigger (0.13~svn685-6) ... Job for dnssec-triggerd.service failed because the

Bug#740563: Fwd: [DSE-Dev] Bug#740563: policycoreutils: semodule -d/-e is ridiculously slow

I regret to say I am no longer able to test this.

Bug#838688: update-grub: backup kernels should be sorted after new kernels

Package: grub2-common Version: 2.02~beta2-36 Severity: normal File: /usr/sbin/update-grub When you upgrade a packaged Debian kernel, the old kernel and initrd are preserved under names ending with `.bak`. update-grub should sort these after the new kernel when generating the menu (so the default

Bug#826246: deja-dup: progress details pane does not stretch vertically when window is resized

Package: deja-dup Version: 34.2-1 Severity: minor The "details" pane of the deja-dup progress monitor window doesn't stretch vertically when the window is resized vertically. Please see the attached screenshot. I think this broke with gtk 3.20. -- System Information: Debian Release:

Bug#819731: r-cran-hdf5: crash on loading hdf objects with empty TITLE attribute

On Fri, Apr 1, 2016 at 2:12 PM, Dirk Eddelbuettel wrote: > Only thing to add is that IIRC the BioConductor folks also have a package for > R + hdf5: > >http://bioconductor.org/packages/release/bioc/html/rhdf5.html > > I am not a user of HDF5 so not sure if this is preferable

Bug#819731: r-cran-hdf5: crash on loading hdf objects with empty TITLE attribute

On Fri, Apr 1, 2016 at 11:30 AM, Dirk Eddelbuettel wrote: > > Sadly this package is not longer maintained upstream: > > https://cloud.r-project.org/web/packages/hdf5/index.html > > Somehow R never had real good support for HDF5 files--maybe the newer h5 > package could be an

Bug#819735: RFP: r-cran-h5 -- S4-based interface to the HDF5 library for binary data storage

Package: wnpp Severity: wishlist Debian has a package 'r-cran-hdf5' which provides a basic interface to libhdf5, but it appears to have been abandoned upstream, and is no longer available on CRAN. This would make a suitable replacement. The long description below has been copied verbatim from

Bug#819731: r-cran-hdf5: crash on loading hdf objects with empty TITLE attribute

Package: r-cran-hdf5 Version: 1.6.10-3+b2 Severity: normal Attached to this bugreport are two HDF5 files named 'title.hdf' and 'no-title.hdf', and the Python script that generated them (using pytables). According to h5dump, the only difference between the two is --- title.hdf +++ no-title.hdf

Bug#814240: systemd triggers break upgrades within unstable

On Mon, Feb 29, 2016 at 12:18 PM, Manuel A. Fernandez Montecelo wrote: > >> DPkg::NoTriggers "true"; >> DPkg::ConfigurePending "true"; >> DPkg::TriggersPending "true"; > > > After talking about this bug a few days ago with APT Deities (David > Kalnischkies, in this case), he told me that apt

Bug#814240: systemd triggers break upgrades within unstable

Control: found -1 aptitude/0.7.5-3 On Mon, Feb 15, 2016 at 8:41 AM, Michael Biebl wrote: > > Zack, I guess the aptitude maintainers will want to know which aptitude > version you are using. I know I've seen this with the version currently in unstable, which is 0.7.5-3. It

Bug#814240: systemd triggers break upgrades within unstable

Package: systemd Version: 228-6 Severity: normal libpam-systemd, systemd, and libsystemd0 have = dependencies on each other. This invariant can be temporarily violated in the middle of a large upgrade, and AIUI that is normal and to be expected. However, systemd has several dpkg triggers that

Bug#814240: systemd triggers break upgrades within unstable

On Tue, Feb 9, 2016 at 9:46 AM, Michael Biebl wrote: >> >> It's possible to recover by manually installing the new versions of >> libpam-systemd, systemd, and libsystemd0, but there's got to be some >> way to make apt do the Right Thing, right? (I don't really understand >>

Bug#808789: phantomjs: FTBFS in several architectures (patch)

On Tue, Dec 22, 2015 at 6:43 PM, Mattia Rizzolo wrote: > oh, dear upstream maintainer, I just submitted a debian bug to > phantomjs, and I'd welcome a quick word from you in > https://bugs.debian.org/808789 :) As I said in #795719, Debian should not attempt to package

Bug#807858: quodlibet: "Saving the songs you changed" window immobile & obscures other programs

Package: quodlibet Version: 3.5.1-2 Severity: normal Writing tags back to music files can be very slow, particularly to a network filesystem, and blocks the UI; quodlibet sensibly puts up a progress bar. However, the progress bar is implemented as a dialog box that isn't attached to the

  1   2   3   4   5   6   >