Control: forcemerge 970555 971674
Am 04.10.2020 um 21:07 schrieb Thorsten Glaser:
> found 971674 0.81
> notfound 971674 0.80
> thanks
>
>> Definitively an issue as log.c (part of the DLL) uses curses
>> making the whole thing fragile.
>
> Jessica, you added this in
Control: tags -1 + fixed-upstream
On 2018-05-13 10:33 -0400, Thomas Dickey wrote:
> On Sun, May 13, 2018 at 09:27:03AM +0200, Sven Joachim wrote:
>> Control: tags -1 upstream
>>
>> On 2018-04-15 16:45 +, brian m. carlson wrote:
>>
>> > Package: ncurs
On 2020-09-18 21:01 +0100, Jessica Clarke wrote:
> On 18 Sep 2020, at 20:51, Sven Joachim wrote:
>>
>> It seems that cowdancer should not link with ncurses in the first place,
>> as it only uses the tinfo library. In fact, rebuilding cowbuilder with
>> a curr
Package: webext-compactheader
Version: 3.0.0~beta5-2
Severity: grave
Control: forwarded -1 https://github.com/jmozmoz/compactheader/issues/42
After upgrading thunderbird from 68 to 78, it deactivated the
CompactHeader extension as incompatible.
Perhaps it should be replaced by
Control: reassign -1 cowdancer
Control: forcemerge 970555 -1
On 2020-09-25 13:28 +0200, Michael Biebl wrote:
> Package: libncurses6
> Version: 6.2+20200918-1
> Severity: serious
>
> Today I tried to upgrade my cowbuilder chroots.
> This failed with the following error message:
>
> Preparing to
Package: texlive-base
Version: 2020.20200804-3
Severity: normal
I noticed the following update-alternatives warnings when upgrading to
the latest texlive-binaries version (sorry for the German):
,
| texlive-binaries (2020.20200327.54578-5) wird eingerichtet ...
| update-alternatives:
On 2020-09-21 18:39 +0200, Rene Engelhard wrote:
> Hi,
>
> Am 21.09.20 um 18:34 schrieb Sven Joachim:
>> Control: reassign -1 cowdancer
>> Control: forcemerge 970555 -1
>>
>> On 2020-09-21 17:53 +0200, Rene Engelhard wrote:
>>
>>> Package: li
Control: reassign -1 cowdancer
Control: forcemerge 970555 -1
On 2020-09-21 17:53 +0200, Rene Engelhard wrote:
> Package: libtinfo6
> Version: 6.2+20200918-1
> Severity: serious
>
> Hi,
>
> in a (dist-|cowbuilder ) upgrade of my i386 chroot:
>
> Preparing to unpack
Control: reassign -1 cowdancer
Control: merge 970555 -1
On 2020-09-19 23:11 +0900, Hideki Yamane wrote:
> Package: libtinfo6
> Version: 6.2+20200912-1
> Severity: important
>
> Dear Maintainer,
>
> I've updated my cowbuilder environment with --update and got an
> error as below.
>
>
>
Control: clone -1 -2
Control: reassign -2 libncurses-dev 6.2+20200912-1
Control: retitle -2 dpkg and zsh FTBFS: KEY_EVENT undeclared
Control: severity -1 normal
Control: tags -2 - ftbfs
On 2020-09-18 19:29 +0200, Guillem Jover wrote:
> On Fri, 2020-09-18 at 18:26:34 +0200, Sven Joachim wr
On 2020-09-18 21:51 +0200, Sven Joachim wrote:
> It seems that cowdancer should not link with ncurses in the first place,
> as it only uses the tinfo library. In fact, rebuilding cowbuilder with
> a current toolchain that defaults to the "--as-needed" linker flag
Control: reassign -1 cowdancer 0.88
Control: retitle -1 cowdancer: needlessly links with ncurses
Control: severity -1 important
On 2020-09-18 18:22 +0200, Sebastiaan Couwenberg wrote:
> Control: tags -1 - moreinfo
>
> On 9/18/20 6:13 PM, Sven Joachim wrote:
>> On 2020-09-18 1
Am 18.09.2020 um 13:43 schrieb Helmut Grohne:
> Source: dpkg
> Version: 1.20.5
> Severity: serious
> Tags: ftbfs
>
> dpkg FTBFS as of today:
>
> | g++ -DHAVE_CONFIG_H -DLOCALEDIR=\"/usr/share/locale\"
> | -DADMINDIR=\"/var/lib/dpkg\" -DLIBDIR=\"/usr/lib/dpkg\"
> |
Control: tags -1 moreinfo
On 2020-09-18 16:55 +0200, Bas Couwenberg wrote:
> Source: ncurses
> Version: 6.2+20200912-1
> Severity: serious
> Justification: makes the package in question unusable or mostly so
>
> Dear Maintainer,
>
> Upgrading sid & experimental pbuilder chroots fails due to the
Control: fixed -1 1.0.17.1+dfsg-1.4
On 2020-08-08 19:42 +, Matthias Klose wrote:
> not sure what the bug submitter was trying, but 1.0.17.1+dfsg-1.4 just built
> fine.
I tried to build the package with sbuild in a sid chroot, which failed.
Apparently some change in dh-python made it
The python-librdf package has a hardcoded dependency on python. Simply
removing it should be enough to fix this bug, however the package does
currently FTBFS, see #967932.
Cheers,
Sven
Source: redland-bindings
Version: 1.0.17.1+dfsg-1.3
Severity: serious
Tags: bullseye sid ftbfs
I was looking at #966787, and while the fix for that bug should be easy
(just remove python-librdf's hardcoded python dependency), I could not
build the package in a current amd64 sid chroot:
,
|
Package: texlive-luatex
Version: 2020.20200804-1
Severity: serious
There was a hiccup installing your package (sorry for the German):
,
| Entpacken von texlive-luatex (2020.20200804-1) über (2020.20200629-1) ...
| dpkg: Fehler beim Bearbeiten des Archivs
Package: aptitude
Version: 0.8.13-1+b1
Severity: normal
X-Debbugs-Cc: Sven Joachim , Guillem Jover
When viewing the Debian changelog of bash in aptitude's TUI, I saw the
screen flash and then error messages from aptitude-changelog-parser
appeared scattered across the screen, redrawing the screen
Control: reopen -1
On 2020-06-24 21:06 +0200, Sven Joachim wrote:
> Control: tags -1 + patch
>
> On 2020-06-24 20:53 +0200, Sven Joachim wrote:
>
>> Source: util-linux
>> Version: 2.35.1-1
>> Severity: important
>> Tags: FTBFS
>>
>> Your packa
Package: po4a
Version: 0.60-1
Severity: wishlist
Policy § 12.7 recommends including the upstream NEWS file as
/usr/share/doc/po4a/NEWS.gz, which is currently missing.
$ echo NEWS >> debian/docs
should be enough to include it. :-)
-- System Information:
Debian Release: bullseye/sid
APT
Package: libdpkg-perl
Version: 1.20.2
Severity: normal
I have seen the following warning when running sbuild-update:
,
| use get_build_env_allowed() instead at /usr/share/perl5/Sbuild/Conf.pm line
1486.
`
Which gave me absolutely no clue: instead _of what_ (looking at
Control: tags -1 + patch
On 2020-06-24 20:53 +0200, Sven Joachim wrote:
> Source: util-linux
> Version: 2.35.1-1
> Severity: important
> Tags: FTBFS
>
> Your package fails to build on the kfreebsd and hurd ports, because it
> invokes dh_makeshlibs for the packages libmo
Source: util-linux
Version: 2.35.1-1
Severity: important
Tags: FTBFS
Your package fails to build on the kfreebsd and hurd ports, because it
invokes dh_makeshlibs for the packages libmount1{,-udeb} which do not
exist on these architectures.
,
| dh_makeshlibs -plibmount1 -V \
|
On 2020-06-21 17:11 -0400, Thomas Dickey wrote:
> On Sun, Jun 21, 2020 at 10:13:41PM +0200, Lucas Nussbaum wrote:
>> Source: xterm
>> Version: 356-1
>> Severity: serious
>> Justification: FTBFS on amd64
>> Tags: bullseye sid ftbfs
>> Usertags: ftbfs-20200620 ftbfs-bullseye
>>
>> Hi,
>>
>>
Package: ftp.debian.org
Severity: normal
Please change the section of libncurses5-dev, libncursesw5-dev and
libtinfo-dev to oldlibs. These are empty transitional packages for
libncurses-dev.
On 2020-06-05 20:35 +0300, Mohammed Alnajdi wrote:
> Hey Sven,
> Thanks for the fast reply.
>
>> I fail to see how it does that, could you please elaborate?
> https://packages.debian.org/buster/libncurses5-dev has a dependency of
> https://packages.debian.org/buster/libncurses-dev which has a
Control: severity -1 normal
Control: tags -1 moreinfo wontfix
On 2020-06-05 14:35 +0300, Mohammed Alnajdi wrote:
> Package: libncurses5-dev
> Version: 6.1+20181013-2+deb10u2
> Severity: serious
> Justification: Installing libncurses5-dev installs libncurses6 from
> libncurses-dev and not
>
>
c7f9cb848f8da2e4807753138f64acce0397b343 Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Mon, 1 Jun 2020 09:08:10 +0200
Subject: [PATCH 1/1] Fix d/not-installed for non-amd64
---
debian/not-installed | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/not-installed b/debian/not-installed
index b08b312
Control: forwarded -1
https://public-inbox.org/git/20200422084254.GA27502@furthur.local/
On 2020-03-23 18:57 +0100, Sven Joachim wrote:
> On 2020-03-23 07:10 +0100, Sven Joachim wrote:
>
>> Package: git
>> Version: 1:2.26.0~rc2-1
>> Severity: important
>&
On 2020-05-14 06:48 +0800, 積丹尼 Dan Jacobson wrote:
> Package: aptitude
> Version: 0.8.12-3
>
> Odd, today I had to reinstall a package to get aptitude to stop trying
> to get rid of it.
The package in question has been marked as automatically installed and
there are no longer any reverse
On 2018-01-23 11:15 +0530, Chris Lamb wrote:
> tags 798762 + moreinfo
> thanks
>
> Hi,
>
>> Lintian tag pre-depends-directly-on-multiarch-support too much
>> debhelper-centric
>
> It seems like this was not applied. That sucks. However, do we still
> need this now that the issue (and the stable
Package: lintian
Version: 2.68.0
Severity: normal
I have seen the following notice on a local testbuild after upgrading
the debhelper compat level:
,
| P: ncurses source: package-uses-experimental-debhelper-compat-version 13
`
The tag's description says
,
| The debhelper
Package: crispy-doom
Version: 5.8.0-1
Severity: serious
There was a problem installing your package (sorry for the German):
,
| Vorbereitung zum Entpacken von .../crispy-doom_5.8.0-1_amd64.deb ...
| Entpacken von crispy-doom (5.8.0-1) über (5.6.4-1) ...
| dpkg: Fehler beim Bearbeiten des
Control: reassign -1 libwacom-dev 1.3-1
Control: fixed -1 libwacom/1.3-2
On 2020-04-03 21:37 +0200, Lucas Nussbaum wrote:
> Source: libinput
> Version: 1.15.4-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200402 ftbfs-bullseye
>
> Hi,
>
>
On 2020-04-02 09:20 +0200, Mathieu Malaterre wrote:
> Control: retitle -1 REP (repeat previous character) escape sequence
>
> On Wed, Apr 1, 2020 at 10:21 PM Thomas Dickey wrote:
>>
>> On Wed, Apr 01, 2020 at 11:02:13AM +0200, Mathieu Malaterre wrote:
>> > Hi Thomas,
>> >
>> > Thanks for your
Control: found -1 2.60.0
On 2020-03-25 11:09 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the lintian package:
>
> #954803: lintian: no-md5sums-control-file tag should not be triggered for
> udebs
>
> It has
On 2020-03-24 19:23 -0400, Thomas Dickey wrote:
> On Tue, Mar 24, 2020 at 01:15:40PM +0100, Harald Dunkel wrote:
>> Package: xterm
>> Version: 353-1
>>
>> xterm -g 256x50 has a much worse "scroll performance" than xterm -g 255x50,
>> esp if there are very long lines and its a slow network
Package: bind9
Version: 1:9.16.1-2
Severity: normal
Upgrading from 1:9.11.16+dfsg-2 created new symlinks /etc/rc?.d/*named
for the renamed init script, but left the old ones in place:
,
| $ file /etc/rc?.d/*bind9
| /etc/rc0.d/K02bind9: broken symbolic link to ../init.d/bind9
|
Package: libgcc-8-dev
Version: 8.4.0-2
Severity: grave
The latest version of gcc-8 is not installable because libgcc-8-dev
depends on libgcc-s1 (>= 1:8.4.0-2), but the version of libgcc-s1 in the
archive does not have an epoch and is therefore too low to fulfill this
requirement.
The same holds
On 2020-03-23 07:10 +0100, Sven Joachim wrote:
> Package: git
> Version: 1:2.26.0~rc2-1
> Severity: important
>
> I have a git repository for the Linux kernel where I track both Linus'
> and the stable repository.
>
> ,
> | $ git remote --verbose show
> | origin
Package: lintian
Version: 2.59.0
Severity: normal
The following is not supposed to happen, I think:
,
| $ lintian libtinfo6-udeb_6.2-1_amd64.udeb
| I: libtinfo6-udeb udeb: no-md5sums-control-file
`
AFAIK it is normal for udebs not to ship an md5sums control file, and
dh_md5sums does not
Package: git
Version: 1:2.26.0~rc2-1
Severity: important
I have a git repository for the Linux kernel where I track both Linus'
and the stable repository.
,
| $ git remote --verbose show
| origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
(fetch)
| origin
Control: reassign -1 cpp-9
Control: forcemerge 953806 -1
On 2020-03-14 10:11 +0100, Berillions wrote:
> Package: libc6-dev
> Version: 2.30-2
>
> Hello,
>
> I try to build plain wine-5.4 on my debian sid 64bits (directly on my
> system or in a chroot with pbuilder) and i have an error about
Control: reassign -1 cpp-9
Control: forcemerge 953806 -1
On 2020-03-13 20:03 +0100, Adam Sjøgren wrote:
> Package: libc6-dev
> Version: 2.30-2
> Severity: normal
>
> Dear Maintainer,
>
> I cannot build GNU Emacs on Debian unstable after the latest update -
> configure
> fails with an error with
Control: tags -1 + fixed-upstream
On 2020-03-10 18:10 +, Ben Hutchings wrote:
> reassign 953522 firmware-realtek
> thanks
For the record, the file has been added to firmware-linux.git in
September[1]. I think upgrading firmware-nonfree to 20200122 would be
rather useful.
Cheers,
On 2020-02-29 01:04 +, Craig Small wrote:
> Control: tag -1 pending
>
> Hello,
>
> Bug #951293 in procps reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
>
>
Control: reassign -1 libprocps-dev
Control: forcemerge 951494 -1
On 2020-02-23 14:27 +0100, Lucas Nussbaum wrote:
> Source: apitrace
> Version: 9.0+repack-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
>
> Hi,
>
> During
Package: procps
Version: 2:3.3.16-1
This version of procps moved the file /etc/sysctl.d/protect-links.conf
to /usr/lib/sysctl.d/, but it remains on the system on upgrades as an
obsolete conffile.
Please refer to dpkg-maintscript-helper(1) and dh_installdeb(1) how to
properly clean up obsolete
Control: notfound -1 2.4.6-11
Control: found -1 2.4.6-12
On 2020-02-08 10:49 +0100, Jakub Wilk wrote:
> Package: libtool-doc
> Version: 2.4.6-11
> Severity: serious
>
> The package failed to upgrade:
>
> Preparing to unpack .../28-libtool-doc_2.4.6-12_all.deb ...
> Unpacking libtool-doc
Package: libgcc-s1
Version: 10-20200202-1
Severity: serious
On systems where /lib is a symlink to /usr/lib (which is the case for
every new buster installation, for instance), it can easily happen that
/usr/lib/$DEB_HOST_MUTIARCH/libgcc_s.so.1 disappears on upgrades. This
happens whenever
On 2020-01-09 16:46 +, Joseph Van Riper wrote:
>> That is to be expected as the file is really no longer there, it has been
>> superseded in the point release update.
>
> This makes sense to me.
>
>> Your package list is out of date by a few months.
>
> I suspected something like this.
>
>>
On 2020-01-09 16:29 +, Joseph Van Riper wrote:
> $ sudo apt install libncurses-dev
>
> [sudo] password for jvanriper:
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Suggested packages:
> ncurses-doc
> The following NEW packages will be
Control: tags -1 + moreinfo unreproducible
On 2020-01-09 09:33 -0500, Joseph Van Riper wrote:
> Package: libncurses-dev
> Severity: important
>
> Dear Maintainer,
>
> It is currently not possible to install libncurses-dev.
Works for me, and apparently for everyone else.
> I tried clearing the
aks/Replaces relationship on geeqie-common, but it is
missing the epoch. See the attached patch (trivial, but untested).
Cheers,
Sven
From c5090b2eb850ab5055bb5da1dbb309db47509bef Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Tue, 7 Jan 2020 16:33:58 +0100
Subject: [PATCH] Add missing
Package: geeqie-common
Version: 1:1.5.1-3
Severity: serious
The changelogs in this package are not compressed:
,
| $ ls /usr/share/doc/geeqie-common/changelog*
| /usr/share/doc/geeqie-common/changelog
/usr/share/doc/geeqie-common/changelog.Debian
`
Looking at debian/rules, apparently
Package: geeqie
Version: 1:1.5.1-3
Severity: serious
There was a problem when updating your package (sorry for the German):
,
| Vorbereitung zum Entpacken von .../6-geeqie_1%3a1.5.1-3_amd64.deb ...
| Entpacken von geeqie (1:1.5.1-3) über (1:1.5.1-2) ...
| dpkg: Fehler beim Bearbeiten des
Source: wine
Version: 5.0~rc1-1
Severity: serious
This upload has silently dropped the wine-binfmt and fonts-wine
packages. This seems to be a consequence of building from the git
master branch used for wine-development and probably has not really been
intended.
Bringing back these packages
Package: texlive-latex-recommended
Version: 2019.20191208-1
Severity: serious
Once again a file has moved to a different package without proper
Breaks+Replaces:
,
| Vorbereitung zum Entpacken von
.../01-texlive-latex-recommended_2019.20191208-1_all.deb ...
| Entpacken von
Package: webext-compactheader
Version: 3.0.0~beta5-1
Severity: serious
The webext-compactheader depends on thunderbird (>= 68.0~), missing the
epoch that the thunderbird package carries. I have just installed it
with thunderbird 1:60.9.0-1 where it does not work.
Going to upgrade thunderbird
Package: udev
Version: 244-3
Severity: important
According to /usr/share/doc/udev/README.Debian.gz,
ln -s /dev/null /etc/systemd/network/99-default.link
should be sufficient to keep the kernel-provided network interface
names. Despite this symlink being present, after upgrading systemd and
Control: reassign -1 udev 243-5
Control: forcemerge 944675 -1
On 2019-11-16 03:45 +, Ximin Luo wrote:
> Package: xorg
> Version: 1:7.7+20
> Severity: important
>
> Dear Maintainer,
>
> After upgrading a bunch of packages on two very different machines, X no
> longer
> responds to keyboard
Control: reassign -1 udev 243-5
Control: forcemerge 944675 -1
I think this is a problem with the new udev in testing, please follow up
on bug #944675 if you have new information.
Am 15.11.2019 um 19:35 schrieb mad:
> Package: xserver-xorg-input-evdev
> Version: 1:2.10.6-1
> Severity: important
Control: tags -1 + fixed-upstream patch
On 2019-11-04 21:14 +0100, Sven Joachim wrote:
> Control: reassign -1 libseccomp2 2.4.1-1
> Control: forwarded -1 https://github.com/seccomp/libseccomp/issues/153
> Control: retitle -1 libseccomp2: seccomp_rule_add is very slow
> Control: affec
Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: bls
The build log scanner reports stale data for ncurses from the 20190803-1
version[1]. The problems reported there have been fixed[2] in the
20191019-1 upload, yet the tracker keeps complaining.
Either
Package: bitwise
Version: 0.40-1
User: ncur...@packages.debian.org
Usertags: hardcoded-dependency
Your package has hardcoded dependencies on libncurses5 and libreadline5
which is Wrong™. The correct dependencies on libncurses6 and
libreadline8 are obtained via ${shlibs:Depends}, which is right.
Package: bzip2
Version: 1.0.6-9
Severity: important
Tags: lfs
On 32-bit systems bzip2 cannot handle files over 2 GiB, as seen here in
an i386 chroot:
,
| $ dd if=/dev/zero of=bigfile bs=1 count=0 seek=2049M
| [...]
| $ bzip2 bigfile
| bzip2: Can't open input file bigfile: Value too large for
On 2019-11-08 19:52 +, Adam D. Barratt wrote:
> On Wed, 2019-11-06 at 11:54 +, Adam D. Barratt wrote:
>> Control: tags -1 + confirmed d-i
>>
>> On 2019-11-02 19:10, Sven Joachim wrote:
>> > I would like to upload ncurses 6.1+20181013-2+deb10u2 to buster,
v 4, 2019 at 10:20 AM Sven Joachim wrote:
>>
>> It seems to me we are likely experiencing
>> https://github.com/seccomp/libseccomp/issues/153.
>
> Thanks for sharing! Perhaps that's why Lintian's test suite has been
> running so slow.
Does this test suite also involv
On 2019-11-01 10:42 +0100, Sven Joachim wrote:
> Bringing man-db and libseccomp maintainers into the loop.
>
> On 2019-10-31 23:01 -0700, Felix Lechner wrote:
>
>> On Thu, Oct 31, 2019 at 11:33 AM Sven Joachim wrote:
>>>
>>> Running lintian on packages
Package: xul-ext-compactheader
Version: 2.1.6-1
Severity: serious
This package is not compatible with thunderbird 68 which has just appeared
in unstable:
,
| $ LANG=C aptitude -s install thunderbird thunderbird-l10n-de
| The following packages will be upgraded:
| thunderbird{b}
if it cannot remove a conflicting name, because
+ treating that as a partial success can cause an infinite loop in
+ use-resolution.
+
+ -- Sven Joachim Sat, 02 Nov 2019 19:16:19 +0100
+
ncurses (6.1+20181013-2+deb10u1) buster; urgency=medium
* Drop "rep" from xterm-new a
Bringing man-db and libseccomp maintainers into the loop.
On 2019-10-31 23:01 -0700, Felix Lechner wrote:
> On Thu, Oct 31, 2019 at 11:33 AM Sven Joachim wrote:
>>
>> Running lintian on packages with many manpages is painfully slow.
>
> I can confirm that it takes a
Package: lintian
Version: 2.31.0
Running lintian on packages with many manpages is painfully slow.
Just run "apt download manpages-dev && lintian manpages-dev*.deb" to
see for yourself. On this (admittedly dated) dual core machine it
took over three minutes.
Running 'top' in a different
Control; tags -1 + patch
On 2019-10-31 10:48 +0100, Sven Joachim wrote:
> Package: debian-policy
> Version: 4.4.1.1
> Severity: minor
>
> Footnote 4 to chapter 9 has a lot of extraneous whitespace:
>
> ,
> | [4] "/lib/lsb/init-functions", which assists in w
Package: debian-policy
Version: 4.4.1.1
Severity: minor
Footnote 4 to chapter 9 has a lot of extraneous whitespace:
,
| [4] "/lib/lsb/init-functions", which assists in writing LSB-
| compliant init scripts, may fail if "set -e" is in effect
| and echoing status messages to
On 2019-10-30 16:58 +, Daniel James wrote:
> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.16-1
> Severity: important
> File: nouveau
>
> Dear Maintainer,
>
> [Message prepared by reportbug 7.5.3-de10u1 but mailed from
> Thunderbird on a different system]
>
> In Debian 10 "Buster" the
Control: tags -1 + patch
Control: forwarded -1 https://github.com/grml/grml2usb/pull/25
On 2019-10-31 09:36 +0100, Sven Joachim wrote:
> On 2019-10-30 23:46 +0100, Lukas Schwaighofer wrote:
>
>> On Wed, 30 Oct 2019 22:41:48 +0100
>> Sven Joachim wrote:
>>
>>>
Schwaighofer wrote:
> On Wed, 30 Oct 2019 22:41:48 +0100
> Sven Joachim wrote:
>
>> On 2019-10-30 21:03 +0100, Lukas Schwaighofer wrote:
>> > I'm suspecting that there is somehow a mismatch between the version
>> > of syslinux/extlinux used while installin
On 2019-10-30 21:03 +0100, Lukas Schwaighofer wrote:
> Control: tags -1 + moreinfo
>
> Hi Sven,
>
> thanks for your report!
>
> On Wed, 30 Oct 2019 18:58:12 +0100
> Sven Joachim wrote:
>
>> Today I built myself a USB stick with grml on it (see #943838 for the
&g
Package: syslinux-common
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-1
Severity: important
Today I built myself a USB stick with grml on it (see #943838 for the
problems I had with that). When booting an old 32-bit laptop with this
stick syslinux threw some error messages before its prompt:
Control: tags -1 + patch
Control: forwarded -1 https://github.com/grml/grml2usb/pull/24
On 2019-10-30 17:09 +0100, Sven Joachim wrote:
> Package: grml2usb
> Version: 0.16.7
> Severity: grave
>
> The check_for_fat() function always fails, no matter what:
>
> ,
> | # fi
Package: grml2usb
Version: 0.16.7
Severity: grave
The check_for_fat() function always fails, no matter what:
,
| # file -s /dev/sdc2
| /dev/sdc2: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat",
sectors/cluster 64, reserved sectors 64, root entries 1024, Media descriptor
0xf8,
Control:; reassign -1 rpcbind
This bug has been assigned to libc6 which no longer ships the rpcinfo
program.
On 2006-03-26 15:04 +0200, Steinar H. Gunderson wrote:
> tags 353867 - patch
> thanks
>
> On Tue, Feb 21, 2006 at 03:55:17PM +0100, Stephan Krempel wrote:
>> -
Control: reassign -1 rpcbind
This bug has been reported against rpcinfo which is no longer shipped in
libc-bin, but rather in rpcbind. I could not tell off-hand if it still
relevant.
Cheers,
Sven
Am 25.06.2010 um 21:46 schrieb Alexander Kretschmer:
> Package: libc-bin
> Version:
Package: libfilezilla0
Version: 0.18.2-3
Severity: important
The "Breaks: filezilla (<= 3.39.0-2)" in libfilezilla0 is too low. If
filezilla ever gets updated in Buster (and there already is a good
reason to do this, namely #928282) it becomes possible to install
non-working combinations of
On 2019-09-03 03:01 +0200, Guillem Jover wrote:
> Source: breezy
> Source-Version: 3.0.1-3
> Severity: wishlist
>
> I see upstream contains a git-remote-bzr program, but it's not
> currently being installed(?). With the removal of the git-remote-bzr
> binary package, and the transition away from
Control: reassign -1 apt 0.9.8.2
Control: fixed -1 apt/1.1~exp13
On 2013-08-06 15:46 +0200, Francois Gouget wrote:
> Package: aptitude
> Version: 0.6.8.2-1
> Severity: normal
>
> Dear Maintainer,
>
> Here is how to reproduce this bug:
> * Download http://fgouget.free.fr/bugs/testdep.tar.bz2
>
m the Debian changelog and not be
hardcoded. Attached is a patch that does the trick using dpkg's
pkg-info.mk Makefile snippets.
Cheers,
Sven
From 326cb477bd07538615f41b327e98f493337a4a1e Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Wed, 16 Oct 2019 10:55:58 +0200
Subject: [PATCH 1/1
Control: found -1 5.9-10
On 2019-10-15 20:54 +0200, Salvatore Bonaccorso wrote:
> Source: ncurses
> Version: 6.1+20190803-1
> Severity: important
> Tags: security upstream
>
> The following vulnerabilities were published for ncurses.
>
> CVE-2019-17594[0]:
> | There is a heap-based buffer
On 2017-03-24 21:12 +0100, Sven Joachim wrote:
> On 2017-03-20 23:53 -0400, G. Branden Robinson wrote:
>
>> On Mon, Mar 20, 2017 at 08:56:58PM +0100, Sven Joachim wrote:
>>> Apparently you have an Intel GPU and use the modesetting(4) driver (the
>>> defau
Thanks for the quick reply after so many years.
On 2019-10-10 17:31 +, David Griffith wrote:
> My reply is at the bottom. Please put your reply there too.
> On Thu, 10 Oct 2019, Sven Joachim wrote:
>> Control: tags -1 + moreinfo
>>
>> On 2012-08-19 19:22 +
Control: tags -1 + moreinfo
On 2012-08-19 19:22 +0700, Ivan Shmakov wrote:
>> Thomas Dickey writes:
>> On Thu, May 31, 2012 at 11:53:05PM -0700, David Griffith wrote:
>
> >> Package: xterm
> >> Version: 278-1
> >> Severity: normal
>
> >> After a normal bootup, the terminal bell with
Control: tags -1 + moreinfo
On 2012-05-31 23:48 -0700, David Griffith wrote:
> Package: xterm
> Version: 278-1
> Severity: normal
>
> Compared to Xterm in Squeeze, Xterm in Wheezy is very slow to scroll and
> update. This leads to distracting flashes and empty blocks when
> scrolling or
Control: retitle -1 filezilla: FTBFS with libfilezilla 0.18.2
On 2019-10-09 21:06 +0200, Andreas Beckmann wrote:
> Package: filezilla
> Version: 3.39.0-2
> Severity: serious
> Tags: sid bullseye
> Justification: fails to build from source (but built successfully in the past)
>
> filezilla FTBFS
On 2019-09-26 08:16 +0200, Sven Joachim wrote:
> Control: reassign -1 libfilezilla0 0.18.2-1
>
> On 2019-09-26 17:53 +1200, jfp wrote:
>
>> Package: filezilla
>> Version: 3.39.0-2
>> Severity: grave
>> Justification: renders package unusable
>>
&g
On 2018-10-13 14:58 +0200, Andreas Beckmann wrote:
> Followup-For: Bug #905209
> Control: found -1 2.40.1-5
>
> Hi,
>
> I don't see a change w.r.t. these broken symlinks in the last upload.
> Did you want to close #910198 instead?
In the current libgraphviz-dev version (2.42.2-2) the originally
Package: dh-runit
Version: 2.8.14
The fix for bug #934500 has the side effect of introducing broken
symlinks[1] into packages using it, causing complaints by tools that
report such oddities, e.g. adequate(1) or symlinks(1):
,
| $ sudo symlinks -r /etc | grep dangling
| dangling:
Package: libobjc-9-dev
Version: 9.2.1-8
Your package includes a dangling symlink:
,
| $ file /usr/lib/gcc/x86_64-linux-gnu/9/libobjc_gc.so
| /usr/lib/gcc/x86_64-linux-gnu/9/libobjc_gc.so: broken symbolic link to
../../../x86_64-linux-gnu/libobjc_gc.so.4
`
According to apt-file there is
On 2019-10-07 06:29 +0200, Jonas Smedegaard wrote:
> Package: elinks-data
> Version: 0.13~20190125-4
> Severity: important
>
> elinks-data recommends elinks, versioned.
>
> This breaks when elinks gets a binNMU.
Indeed, I had to persuade aptitude to upgrade elinks anyway and thus get
rid of
401 - 500 of 4051 matches
Mail list logo
