Control: tags 1071335 pending
James Cameron wrote...
> You may be interested in these upstream commits;
>
> b01478d ("Fix some parts of macro expansion are not guarded")
> 0194b80 ("strerror and memset require string.h")
Thanks a lot for having an eye on the Debian packaging. As you'd expect,
Preuße, Hilmar wrote...
> On 03.05.2024 22:29, Christoph Biedl wrote:
> > Hilmar Preusse wrote...
> > > * Bump Standards and dh compat version, no changes needed.
> >
> > I'm a little surprised why you would change that in a NMU.
> >
> Well, thi
Hilmar Preusse wrote...
> Changes since the last upload:
>
> nq (0.5-0.1) unstable; urgency=medium
> .
>* Non-maintainer upload.
> .
>* New upstream version (Closes: #1038937).
>* Bump Standards and dh compat version, no changes needed.
I'm a little surprised why you would
Control: tags 1038937 pending
E Harris wrote...
> nq 0.5 was released March 26, 2022 and contains several bug fixes and
> improvements.
> nq 0.3.1 was released March 7, 2018, and is what is in all of stable,
> testing, and unstable.
> Please update this package.
Upon request by upstream and
Control: tags 1069915 pending
Steve Langasek wrote...
> The time_t transition automation scripts incorrectly changed the versioned
> Breaks/Replaces against old libmagic1 to point to libmagic1t64, which
> clearly never had a package version (<< 1:5.28-4~).
... and your fellow maintainer didn't
Source: systemd
Severity: serious
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Greetings,
systemd build-depends on liblz4-tool but that package is no longer build
from src:lz4 (since 1.9.4-2, uploaded about a week ago). Just replacing
the dependency with lz4 seems to fix this problem
anon2529 wrote...
> The early boot fails to unlock a volume automatically. We get a
> prompt to unlock a volume (it's a swap volume) but clevis is
> unable to unlock it automatically because it cannot resolve
> the Tang server's hostname.
That ought to be fixed in clevis 20 (not uploaded yet,
Control: tags 1067237 pending
jose wrote...
> The master branch of the upstream ngircd changelog informs about an
> SSL security related patch [1] that is missing in the -26-1 ngircd debian
> package patches.
Thanks, this is on radar and I'm in contact with upstream on how to deal
with this.
Package: libresolv-wrapper
Version: 1.1.8-2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Greetings,
while looking for a way to overload hostname resolution as non-root
(part of a test suite and/or autopkgtest), I came across your package.
However, *nothing*
Control: forwarded 1067457 https://github.com/latchset/jose/issues/151
signature.asc
Description: PGP signature
Control: tags 1066850 -moreinfo +pending
Matthias Klose wrote...
> On 14.03.24 21:38, Christoph Biedl wrote:
> > Do you have an idea, an existing solution how to do that?
> dep := $(shell dpkg-query '-f${Depends}' -W libmagic-dev | sed
> 's/.*\(libmagic[a-z0-9]*\).*/\1/')
> e
After getting some help in IRC, I guess the problem boils down to:
1. All architectures provide the t64 variant (libmagic1t64).
2. Some architectures no longer provide the old variant (libmagic1), for
example armhf.
3. Therefore, the install dependency of python3-magic must be the t64 variant.
Control: tags 1066850 moreinfo
Matthias Klose wrote...
> Package: src:python-magic
> Version: 2:0.4.27-2
> Severity: serious
> Tags: sid trixie
>
> the package build-depends on libmagic1, and depends on it. The name was
> recently changed to libmagic1t64.
This is not a real problem as
Control: merge 1066134 1065940
Ups, that had already been reported.
signature.asc
Description: PGP signature
Christoph Biedl wrote...
> So, assuming this is the cause here, the fix is pretty simple:
(...)
> +#ifdef INET6
> if (if6_is_up)
> sif6down(0);
> +#endif
This was silently done as part of
commit 80b8744eb42c7493794f3e3fe0bf1ce14f53e6dd
Author: Eivind Næss
Date:
Source: ppp
Version: 2.4.9-1+1.1
Severity: serious
Tags: patch upstream ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Hi Chris,
ppp no longer builds in unstable here, tested in a minimal chroot. A
build in a
Axel Beckert wrote...
> Citing from https://buildd.debian.org/status/package.php?p=aptitude:
(...)
> /usr/include/cppunit/TestAssert.h:161:6: note: template argument
> deduction/substitution failed:
> ../../tests/test_misc.cc:187:5: note: deduced conflicting types for
> parameter ‘const T’
> I'm not qualified to write the upstream documentation. Suggest you open a
> bug
> in the upstream bugzilla: https://bugs.ghostscript.com/
This is one of the tasks of a package maintainer:
| If it's an upstream problem, you have to forward it to the upstream
| author.
[
"Bug
Package: lintian
Version: 2.117.0
Severity: wishlist
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Dear maintainer,
a few times too often I got annoyed by a "patch-not-forwarded-upstream"
warning from lintian where that wasn't actually sensible. Looking into
the lintian sources, then
Control: tags 1065101 pending
Boyuan Yang wrote...
> Package ngircd depends on binary package libident, but this package has
> been renamed to libident0 due to time64 transition. Please fix the binary
> dependency relationship accordingly. You may need to rebuild the package.
The fix for
Source: libident
Severity: serious
Tags: patch
Version: 0.32-2
X-Debbugs-Cc: by...@debian.org, efing...@packages.debian.org,
vor...@debian.org, debian.a...@manchmal.in-ulm.de
Control: block 1065100 by -1
Control: block 1065101 by -1
For libident, the t64 transition was done in a slightly
Source: grub2
Version: 2.12-1
Severity: normal
Tags: patch
Dear Maintainer,
Hello,
while rebuilding grub, I encountered two issues from the test suite.
Perhaps I've already reported them but cannot find any traces of that.
One is, things go downhill in util/grub-shell if an environment
Chris Hofstaedtler wrote...
> You are welcome to write a new tool or implement all the missing
> parts in deborphan and deal with users thinking deborphan is a magic
> tool that knows everything and its output can be used by
> non-thinking humans. Various people in the past have suggested its
>
Chris Hofstaedtler wrote...
> please remove deborphan. It is stuck, featurewise, in a very old time
> and does not support many currently available dpkg features properly
> (multi-arch, versioned provides, etc).
FWIW, deborphan is part of my regular workflow, and while you claim
it has defects,
Boyuan Yang wrote...
> Package ngircd depends on binary package libident, but this package has
> been renamed to libident0 due to time64 transition. Please fix the binary
> dependency relationship accordingly. You may need to rebuild the package.
Well, that is broken anyway at the moment:
(...)
Julien Cristau wrote...
> The snapshot infrastructure currently can't cope with -ports imports,
> as they take longer than the interval between pushes, for reasons.
> We'll turn it back on when we can.
Thanks for the update. If you think people can help you with that,
please let us know.
My
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
X-Debbugs-Cc: debian-de...@lists.debian.org, debian.a...@manchmal.in-ulm.de
* Package name: tftp-proxy
Version : 1.0.0
Upstream Contact: Arnoud Vermeer
* URL : https://github.com/openfibernet/tftp-proxy
Package: reprepro
Version: 5.3.1-4
Severity: minor
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Hello,
While looking for a way to include .buildinfo and .changes, I learned
about the tracking feature of reprepro. Things are working fine now, but
the ride was a bit bumpy.
So I'd like you to
Sebastian Andrzej Siewior wrote...
> The testsuite fails with openssl 3.2. Please find attached upstream
> commit 287770666008b ("Test suite: Update for OpenSSL 3.x") which fixes
> the issue.
Thanks. As upstream is about to do another release, this issue will
resolve automatically. If however
Christoph Biedl wrote...
> Looking at
>
> https://snapshot.debian.org/archive/debian-ports/
>
> it seems debian-ports was not updated for almost half a year now. If
> that was just an error, please fix it. If it was discontinued by
> intention, please place according no
Control: retitle 977716 ITP: llhttp -- parser for HTTP messages
Control: tags 977716 pending
Christoph Biedl wrote...
> * Package name: llhttp
> Version : 3.0.0
9.3.1 already
> The http-parser library has declared unmaintained by upstream[1],
> and this one he
Package: snapshot.debian.org
Severity: normal
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Greetings,
Looking at
https://snapshot.debian.org/archive/debian-ports/
it seems debian-ports was not updated for almost half a year now. If
that was just an error, please fix it. If it was
Package: libipc-run3-perl
Version: 0.048-3
Severity: important
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Greetings,
Summary: When a Perl application uses IPC::Run3::run3, any unread data
on stdin is lost.
The problem has been around for a long time, I can confirm it's already
This topic is getting a bit bigger, perhaps let me sort first what
issues we're talking about here. So to summarize the longer text that
follows:
1. News::Article::NoCeM may embed an invalid hash algorithm declaration,
depending on the gpg program used by PGP::Sign, and possibly other
Russ Allbery wrote...
> Christoph Biedl writes:
>
> > * Omitting the hash declaration is not an option either, perl-nocem
> > fails then.
>
> I'm somewhat surprised by this, as my impression was that these Hash lines
> are optional and GnuPG did the right thing if
Package: libnews-article-nocem-perl
Version: 0.09-3
Severity: important
Tags: upstream
X-Debbugs-Cc: libpgp-sign-p...@packages.debian.org,
debian.a...@manchmal.in-ulm.de
Greetings,
At the moment, NoCeM messages generated using News::Article::NoCeM
declare a hard-coded signature hash algorithm
Control: tags 1059975 pending
Gianfranco Costamagna wrote...
> In order to achieve this we found a total of 8 packages still using the old
> one,
> so I'm asking you to update it and let us drop that old cruft from src:lirc.
Sure thing. Force-ping me if this is still open within in two weeks
Bálint Réczey wrote...
> Technically it is possible, but is there a use case where "tshark -G"
> is not sufficient already?
That would be good enough, thanks. So, problem solved for me, feel free
to close or to wait until somebody else complains about any other file
now missing.
Oh, and just in
Control: tags 1056960 pending
Chris Hofstaedtler wrote...
> your package aoetools installs some files into /lib and /sbin. I
> understand this was to support split-/usr installs in the past.
Telling stories, this was a deliberate change by an earlier maintainer
of aoetools. I wanted to revert
Control: tags 1056898 pending
Chris Boot wrote...
> Please could you try the patch and test the pptpd-logwtmp.so pppd
> plugin, and upload the package to unstable?
Test is looking good, I've also sent upstream a notice about that.
> I'll upgrade the bug to RC when I upload ppp-2.5.0 to
Package: libwireshark-data
Version: 4.2.0-1
Severity: normal
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Greetings,
ealier version of the libwireshark-data package shipped a file
/usr/share/wireshark/manuf that holds a list of MAC vendors. However,
it's no longer present in 4.2.0-1, along with
Christoph Biedl wrote...
> after upgrading from 0.7.2 to 0.8.1, the symlinks in /usr/lib/molly-guard/
> are gone.
It was suggested in IRC this might be the effect of another package's
upgrade. I find that unlikely since no other package should touch
/usr/lib/molly-guard/ - still,
Package: molly-guard
Version: 0.8.1
Severity: grave
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Greetings,
after upgrading from 0.7.2 to 0.8.1, the symlinks in /usr/lib/molly-guard/
are gone. As this happened on a second machine today, I reckon it's not
a coincidence.
Current state:
# ls -l
Package: e2fsprogs
Version: 1.47.0-2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Greetings,
Summary: If the APM_EMULATION kernel option is enabled (and built-in),
fsck during boot may be skipped all the time.
Longer story: One day I noticed some virtual
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: lib...@packages.debian.org, g...@packages.debian.org,
till.kamppe...@gmail.com, debian.a...@manchmal.in-ulm.de
Control: affects -1 + src:libppd
Greetings,
As previously announced in
Package: pv
Version: 1.8.0-2
Severity: wishlist
Tags: patch
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Hi there,
thanks for resolving the valgrind dependency issue for armel and a few
more release archs. Unfortunatly, there are several port archs where pv
still fails to build. As a solution,
Arnaud Ferraris wrote...
> * Package name: railway
> Version : 2.0.0
> Upstream Contact: Julian Schmidhuber
> * URL : https://gitlab.com/schmiddi-on-mobile/railway
> * License : GPL
> Programming Lang: Rust
> Description : GUI application for searching
Control: tags 1052632 moreinfo
Helmut Grohne wrote...
> We want to change the value of systemdsystemunitdir in systemd.pc to
> point below /usr. clevis' upstream build system consumes this value, but
> the debian packaging hard codes its current value. When it changes,
> clevis will fail to
Kurva Prashanth wrote...
> * Package name: control
> Version : 0.9.4
> Upstream Author : >
> * URL : http://python-control.org/
While I cannot judge whether this package is a sensible addition to
Debian - I strongly ask you to re-consider the package name as
Control: reopen 1052255
Closed that one by accident, sorry for the mess.
signature.asc
Description: PGP signature
Control: reopen 1052255D
Closed that one by accident, sorry for the mess.
signature.asc
Description: PGP signature
Control: tags 1052278 pending
Helmut Grohne wrote...
> we're trying to finalize the /usr-merge transition. In the process, I
> ask you to move the remaining files from / to /usr. In your source
> package, only two files are affected and both are systemd units. Such a
> move violates the file
Source: libppd
Version: 2:0.10-9
Severity: important
X-Debbugs-Cc: g...@packages.debian.org, debian.a...@manchmal.in-ulm.de,
till.kamppe...@gmail.com
The libppd package is very old software with little use (maximum popcon
is 148 for libppd0). As far as I understand, it was created by taking
bits
Source: nutsqlite
Version: 2.0.6-3
Severity: important
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Bonjour,
the latest upstream version of the file package introduced a detection
of SQLite write-ahead shared memory files. As a result, the autopkgtest
of nutsqlite breaks when using that version
022-10-15 12:46:49.0 +0200
+++ smokeping-2.7.3/debian/changelog2023-09-02 11:50:51.0 +0200
@@ -1,3 +1,11 @@
+smokeping (2.7.3-4.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Remove recommendation on echoping which is no longer in Debian.
+Closes: #1042953
+
+ --
Control: tags 1050426 pending
JiaLing Zhang wrote...
> Please add loong64 to architecture list. I can confirm this could build in
> loong64 .
Will do. Testing a stick on that architecture would be the icing on the
cake but I'm aware these stick are really hard to get these days. Still
it's
Simon McVittie wrote...
> 2½ years later, updating a debootstrap merge request reminded me that this
> is unresolved. I see schroot now has a new maintainer and a new upstream:
> please consider applying the patch proposed here to set up a working
> /dev/ptmx and /dev/console in more situations.
r upload
+ * New upstream version 4.3.1
+ * Switch to the pcre2 library. Closes: #999946
+
+ -- Christoph Biedl Sun, 30 Jul 2023
12:04:27 +0200
+
syslog-ng (3.38.1-5) unstable; urgency=medium
* Build without Criterion support.
diff --git a/debian/control b/debian/control
index f8a6c90..3
Control: tags 1043458 pending
Jan Smets wrote...
> Can you please add the Multi-Arch hints to the debian/control file.
Sure thing.
Christoph
signature.asc
Description: PGP signature
Control: tags 1040467 upstream
fr...@gmail.com wrote...
> UEFI systems make the boot logo accessible for reading at the path
> /sys/firmware/acpi/bgrt/image
>
> The file can be displayed directly using for example:
> $ feh /sys/firmware/acpi/bgrt/image
>
> Strange things happen when you copy
Control: tags 1038750 confirmed
Control: forwarded 1038750
https://mailman.astron.com/pipermail/file/2023-July/001201.html
Bjarni Ingi Gislason wrote...
> here are some notes and fixes for the man page.
Thanks, now forwarded upstream where applicable, the rest fixed locally.
Christoph
Control: tags 1041041 confirmed
Control: forwarded 1041041
https://mailman.astron.com/pipermail/file/2023-July/001200.html
sowg09+39vc9e5tpgdtw@cs.email wrote...
(...)
> I propose that `file` should either drop the leading 0, so that it
> shows 34f5ee1202469ff7, or it should put an 'x' after
Michael Biebl wrote...
> If (bookworm-) backports are a concern, you might also use something like
> this
>
> -libblockdev-crypto2,
> +udisks2 (>= 2.10) | libblockdev-crypto2,
Thanks for the suggestion, will adjust the still-not-yet-happened upload.
Christoph
signature.asc
Control: Tags 1040924 +pending
Jeremy Bícha wrote...
> Yes, it's a transition. Sorry that it didn't follow the recommended procedure.
Thanks for the clarification. New version is underway, I'd like to do
some thourough testing, though.
Christoph
signature.asc
Description: PGP signature
Control: tags 1040924 moreinfo
Jeremy Bícha wrote...
> clevis-udisks2 depends on libblockdev-crypto2 which is no longer built
> by libblockdev in Unstable. Please update the manual dependency to
> libblockdev-crypto3
I fail to understand what is happening here. Is this supposed to be a
isting multi-user bullseye installations, rotating the keys
+is suggested.
+ * Make the tangd-rotate-keys program executable
+
+ -- Christoph Biedl Sat, 08 Jul 2023
12:41:29 +0200
+
tang (8-3+deb11u1) bullseye-security; urgency=high
* Fix data leak [CVE-2021-4076]
diff -Nru
tang-8/debian/p
,3 +1,11 @@
+tang (11-2+deb12u1) bookworm; urgency=medium
+
+ * Fix CVE-2023-1672. Closes: #1038119
+- Cherry-pick "Fix race condition when creating/rotating keys"
+- Assert restrictive permissions on tang's key directory
+
+ -- Christoph Biedl Sat, 08 Jul 2023
12:49:07 +0200
+
Salvatore Bonaccorso wrote...
> CVE-2023-1672[0]:
> | Fix race condition when creating/rotating keys
>
> Please adjust the affected versions in the BTS as needed.
As I'm very short of time today, first in words only:
* Debian sid will see a new upstream version (containing the fixes)
in the
Package: manpages
Version: 6.03-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Dear maintainer,
the tmpfs.5 manpages states in the description of the huge= mount option:
| Set the huge table memory allocation policy for all files in this
| instance (if
Christoph Biedl wrote...
> James Vega wrote...
>
> > On Fri, Feb 11, 2011 at 08:03:40AM +, Aníbal Monsalve Salazar wrote:
> > > Please preserve timestamps in the dget script. I'm using the patch
> > > below to pass the -N option to wget. I don't know the corre
Control: tags 1034353 confirmed upstream
Mathieu Malaterre wrote...
> % wget -O filelogo.jls
> "https://bugs.astron.com/file_download.php?file_id=214=bug;
> % file --mime-type filelogo.jls
> filelogo.jls: image/jpeg
>
> However upstream claims this is fixed since 5.41, some kind of regression ?
Control: tags 1031684 moreinfo
Hans-Christoph Steiner wrote...
> There is a new bugfix version available from upstream. It would be
> nice to have that in bookworm, and there is still time before the hard
> freeze if it is uploaded now. I can contribute there if that is
> needed to make this
Package: redis
Version: 5:7.0.8-2
Severity: minor
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Greetings,
it seems redis 5:7.0.8-2 wanted to add the "delaycompress" keyword to
the logrotate snippet but a missing letter will void that.
You're not alone, though:
Package: watchdog
Version: 5.16-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debian.a...@manchmal.in-ulm.de
Today, for the first time in years, watchdog was able to send an e-mail
before resetting the system - I guess usually this is triggered that
fast the message doesn't get through.
But
user debian-rele...@lists.debian.org
usertags 1022180 + bsp-2023-01-ch-stcergue
thank you
@maintainer:
Excuse my bluntness, but is there a reason to *not* just replace "10"
with "12" as shown below, and previously done in commit 334e9afa
("Switch to using gcc-10 rather than gcc-9. Closes:
Christoph Biedl wrote...
> After finally sorting things out: Unlocking in early userland using
> dracut works like a charm here, both with tang and tpm pins.
Still cannot reproduce, and no update in years. Hence closing.
signature.asc
Description: PGP signature
Varac wrote...
> * Package name: yq
> Version : 2.1.2
> Upstream Author : Mike Farah
> * URL : http://mikefarah.github.io/yq/
Hello everybody,
it's been a while ... bookworm freeze is getting closer, and I'd like to
find a solution for the current problems providing
Control: tags 849782 pending
Hans-Christoph Steiner wrote...
> APKs can be a totally standard JAR with a valid JAR signature, and they
> can be assembled with any tool that can make a valid ZIP archive with a
> valid JAR signature. The vast majority of APKs are made with the same
> toolchain,
Control: tags 1026920 patch
Christoph Biedl wrote...
> It took a few hours to realize locale setting ruin your day. I could
> reproduce that only with LC_ALL=C, and then bisecting led to:
>
> commit f448f3e5c37de8c285ac14b032b2bdcea82fc08b
> Author: Christos Zoulas
&g
Louis-Philippe Véronneau wrote...
> Lintian runs file (more precisely, `file --no-pad --print0 --print0 --`)
> to get the "file_type" value of files [1].
Very exhausting debugging¹ reveals lintian has that file_type set to the
empty string. Obviously this causes ...
> Then, for all the files in
-maintainer upload
+ * Adjust PARAM_BYTES_MAX for change in file 5.44. Closes: #1026988
+
+ -- Christoph Biedl Wed, 11 Jan 2023
18:53:56 +0100
+
ruby-ruby-magic-static (0.5.4-1) unstable; urgency=medium
* Team upload
diff -Nru
ruby-ruby-magic-static-0.5.4/debian/patches/adjust-for-new-file
Control: reassign 1026976 file 1:5.43-2
Control: tags 1026976 pending
Christoph Biedl wrote...
> As I understand it, this is result of how t/fixtures/pyzip/pyzip.in is
> described by file(1):
>
> - a /usr/bin/python3 script executable (binary data)
> + Zip archive, with extra
Paul Gevers wrote...
> On 31-12-2022 10:06, Christoph Biedl wrote:
>
> > So src:libppd has been renamed to src:libppd-legacy, and has entered
> > experimental yesterday. While doing so, I've fixed a longstanding
> > mismatch in the soname version, hence the new number l
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lib...@packages.debian.org, Till Kamppeter
Control: affects -1 + src:libppd
Greetings,
possible this is not a regular transition, but in exchange I guess it
should be
+1,38 @@
+Subject: Follow renaming of libppd to libppd-legacy
+Author: Christoph Biedl
+Date: 2022-12-27
+Forwarded: not-needed
+
+--- a/configure
b/configure
+@@ -6383,13 +6383,13 @@
+ done
+
+
+- { $as_echo "$as_me:${as_lineno-$LINENO}: checking for ppd_file_new in
-lppd"
Chris Lamb wrote...
> Thanks again for the "new version of file in experimental" bugs; very
> much appreciated.
You're welcome. Given file's volatility, I guess this will not be the
last conversation in that regard ...
> > - a /usr/bin/python3 script executable (binary data)
> > + Zip archive,
Source: yara
Version: 4.2.3-1
Severity: important
Hello,
The last upload of file/libmagic (1:5.43-3), currently in experimental)
breaks the yara test suite:
==
==
yara 4.2.3: ./test-suite.log
Source: ruby-ruby-magic-static
Version: 0.5.4-1
Severity: important
Hello,
The last upload of file/libmagic (1:5.43-3), currently in experimental) also
the ruby-ruby-magic-static test suite:
==
Failure:
Control: tags 1005435 pending
Lucas Nussbaum wrote...
> Source: gpr
> Version: 0.15deb-2
> Severity: serious
> Justification: FTBFS
> > configure: error: Must have libppd installed to compile gpr
This was caused by yours truly as a result of updating src:libppd
almost a year ago. Fix is
Source: strip-nondeterminism
Version: 1.13.0-2
Severity: important
Hello,
possibly you've seen the similar story in diffoscope already: The last
upload of file/libmagic (1:5.43-3, currently in experimental) broke also
the strip-nondeterminism test suite:
Package: lintian
Version: 2.115.3
Severity: important
Greeting,
my recent upload of file (1:5.43-3) to experiental broke lintian's autopkgtest.
Possibly this is the relevant section.
# Hints do not match
#
# ---
Package: libtss2-fapi1
Version: 3.2.1-1
Severity: normal
(...)
Setting up libtss2-fapi1:amd64 (3.2.1-1) ...
Failed to read '/usr/lib/tmpfiles.d/tpm2-tss-fapi.conf': Is a directory
(...)
Cause is an old trap, debian/*.install wants a directory only in the
second column. Happens all the time to me
Control: tags 1026460 confirmed upstream
Hilmar Preusse wrote...
> Not sure if this is solvable, at the fist glance I found no magic byte
> for vf files.
Things are worse: file(1) /does/ have magic for "TeX virtual font data"
but is *that* weak (only 16 bit, 0xf7 0xca at the start of file) it
Control: forwarded 1022565
https://mailman.astron.com/pipermail/file/2022-December/000995.html
Paul Wise wrote...
> The detected MIME type of OpenPGP files is now application/octet-stream:
Ups. That's clearly a regression, and a rather weird one. Sent to upstream.
Christoph
Control: tags 1011921 moreinfo
積丹尼 Dan Jacobson wrote...
> $ file 111D2012841-01.txt
> 111D2012841-01.txt: ISO-8859 text, with CRLF line terminators
Hello,
as you noticed, your file is utf-8. Can you please re-send as don't have
a clue how to proceed?
Regards,
Christoph
signature.asc
Michael Lueck wrote...
> xfsdump: ERROR: /srv/shares/pdoxdata/ does not identify a file system
Came across that problem as well today. From a little probing - I did
not check the sources, though - it seems xfsdump is pretty pedantic
about that path. I guess it must exactly match the
Guillem Jover wrote...
> I'd be interested to know about those scenarios (or abstract descriptions
> of them), to be able to understand the required semantics for this, or
> whether there are other alternatives?
Well, the particular use case is not fully the Debian way to do things:
It's an
Package: dpkg
Version: 1.21.9+b1
Severity: wishlist
Hello,
in some (admittedly unusual) scenarios, I'd like to hook
dpkg-buildpackage way earlier then via the "init" hook. More precisely,
I'd like to run a hook *before* debian/changelog and debian/control are
inspected.
Implementing this (I
Christoph Biedl wrote...
> as briefly discussed in IRC, I tried to import upstream version 0.67 -
> turns out this is no big deal:
Someone™ asked for a debdiff, see attachment. May contain easter eggs.
Christoph
diff --git a/debian/changelog b/debian/changelog
index f91eaf7..4964eb8
Package: quilt
Version: 0.66-2.1
Severity: normal
Dear maintainer,
as briefly discussed in IRC, I tried to import upstream version 0.67 -
turns out this is no big deal:
* Drop setup-dont-read-pc patch as it was applied upstream
* Add gawk as a build dependency as this is now needed by the test
1 - 100 of 1949 matches
Mail list logo
