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
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
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
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
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
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
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
&
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
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:
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
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
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
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
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,
[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
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
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
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
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
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
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
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
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
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
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
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)
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)
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
Merged as 86d1e4e3815fa6c47613bda86820ee50e41ebd11, thank you for the
patch. It's good to know someone is testing cross compilation.
zw
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,
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
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
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
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
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
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
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
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
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
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
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
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 =
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
> 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
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
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
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
I installed that package over 17.11-2 and ESS is now loading correctly
with no manual intervention required. Thanks for the quick fix!
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" =
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
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.
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
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
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.
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
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.)
Upstream patch submission:
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1411004.html
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
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
Filed https://github.com/systemd/systemd/issues/5659
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
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
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
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
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
>
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
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
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
>>
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
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
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/
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
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
I regret to say I am no longer able to test this.
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
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:
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
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
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
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
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
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
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
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
>>
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
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 - 100 of 510 matches
Mail list logo