03.05.2024 23:16, Andreas Beckmann wrote:
Package: samba-dev
Version: 2:4.20.0+dfsg-1~exp2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts fileconflict
Hi,
during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine
Control: tag -1 + moreinfo unreproducible
02.05.2024 23:36, Michael Biebl wrote:
Control: reopen -1
Control: found -1 2:4.19.6+dfsg-3
So, I'm confused now. You reopened this for -3 which *fixed* both
issues mentioned by you as reasons for the reopen.
Does -3 actually fails for you?
Thanks,
02.05.2024 23:36, Michael Biebl wrote:
Control: reopen -1
Control: found -1 2:4.19.6+dfsg-3
On Thu, 2 May 2024 11:58:59 -0700 "Leo L. Schwab" wrote:
Did you fix this one, too?
---
Performing actions...
Setting up python3-samba (2:4.19.6+dfsg-2) ...
File
Ok,
I'm removing whole modutils from busybox udeb (besides depmod, this is
lsmod, insmod, rmmod, and modprobe). All these are provided by
kmod-udeb as far as I can see (as symlinks to kod).
--
GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24.
New key: rsa4096/61AD3D98ECDF2C8E
09.04.2024 16:48, Cyril Brulebois wrote:
Marco d'Itri (2024-04-09):
Yes. Nowadays kmod has many more features related to compressed modules
and verification of signatures.
Can we agree that kmod should provide these programs for d-i?
Or can the d-i maintainers just tell us what they want?
I
20.04.2024 15:33, Lucas Nussbaum wrote:
[..]
This is part of a mass rebuild, first building on arm64 and then on
armhf and armel. So I'm not suggesting anything. :-)
Aha.
Is this failing because the build is trying to build arch:all packages,
that can only be built on amd64? If so, the bug
Control: tag -1 + moreinfo
Control: found -1 1:4.2-2
20.04.2024 15:11, Lucas Nussbaum wrote:
Source: qemu
Version: 1:8.2.2+ds-2
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64
Package: locales
Version: 2.37-16
Severity: grave
A fresh `debootstrap unstable' chroot plus `apt install locales`:
Preconfiguring packages ...
locales failed to preconfigure, with exit status 2
dpkg: error processing package locales (--configure):
installed locales package
07.04.2024 05:54, Peter Green wrote:
Ubuntu has already fixed this issue by removing the hardcoded
dependency on libgpgme11
I fixed it in git too, but forgot to upload.
http://launchpadlibrarian.net/720831431/riseup-vpn_0.21.11+ds1-5build3_0.21.11+ds1-5ubuntu1.diff.gz
While poking through
On Sat, 30 Mar 2024 16:59:51 +0900 Kentaro HAYASHI wrote:
Source: sssd
Severity: serious
Tags: ftbfs
Control: found -1 2.9.4-1.1
X-Debbugs-Cc: ken...@xdump.org
Dear Maintainer,
sssd fails to build on armel, armhf.
Though test suite failure was already reported, but
target version is
05.03.2024 10:03, Andrey Rahmatullin wrote:
Breaks: qemu-system-common (<< 8.2.1+ds-3~),
Replaces: qemu-system-common (<< 8.2.1+ds-3~),
so... what's going on here? q-s-d 8.2.2 replaces files from q-s-c 8.2.1
Can it be simply because the package has an epoch and relations should
05.03.2024 09:10, Andrey Rahmatullin wrote:
Package: qemu-system-data
Version: 1:8.2.2+ds-1
Severity: serious
Preparing to unpack .../qemu-system-data_1%3a8.2.2+ds-1_all.deb ...
Unpacking qemu-system-data (1:8.2.2+ds-1) over (1:8.2.1+ds-2) ...
dpkg: error processing archive
Control: severity -1 important
03.03.2024 13:21, Eric Valette :
Package: libsmbclient0
Version: 2:4.19.5+dfsg-3
Severity: grave
Justification: renders package unusable
This is wrong, in my opinion. The effect of this bug on platforms unaffected
by time64_t transition is exactly the same as
01.03.2024 17:24, Emanuele Rocca wrote:
Source: udns
Version: 0.4-1.1
Severity: serious
Tags: ftbfs
User: debian-de...@lists.debian.org
Usertags: time64
Dear Maintainer,
udns fails to build on both armhf and armel with the time64 build flags, which
are on by default. It builds fine without.
01.03.2024 19:05, Aurelien Jarno :
Source: samba
Version: 2:12.3.5-4
Is it really 12.3.5-4? :)
/mjt
09.02.2024 17:57, Thorsten Bonow :
dash << 'EOF' [15:28:53]
if $( (true) 2>/dev/null); then
echo "42"
fi
EOF
42
which only works in dash because of the added space between the command
substitution $(...) and the subshell (...).
Does dash think it
09.02.2024 16:58, ca...@allfreemail.net
Package: console-setup
Followup-For: Bug #1063518
Consider making all scripts provided by console-setup shellcheck-clean, there
are lots of tiny issues that can turn into big issues under the right
conditions.
Please do not do this. Shellcheck is a
06.02.2024 12:34, Helmut Grohne:
...
An option I see here is to provide ABI-duality for libselinux:
-extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file);
+typedef unsigned long libselinux_ino_t;
+typedef uint64_t libselinux_ino64_t;
+extern int
07.02.2024 11:06, Helmut Grohne :
..
pam seems difficult:
| extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
| extern time_t pam_misc_conv_die_time; /* cut-off time for input */
Attached is a sketch to make pam compatible.
I had a more complete and *tested*
06.01.2024 11:40, Helmut Grohne:
On Sat, Jan 06, 2024 at 09:01:12AM +0100, Helmut Grohne wrote:
I also recommend to establish QA for all udebs to automatically detect,
report and address such conflicts as they evidently cause undefined
behaviour otherwise. That can be as simple as collecting
Control: severity -1 normal
Control: merge 1060005 -1
FWIW, this is kernel bug, not cifs-utils bug, - guess it's 6.1.0-17 regression.
/mjt
On Sat, 16 Dec 2023 14:54:32 +0100 Wolfgang Rohdewald
wrote:
Package: docker.io
Version: 20.10.24+dfsg1-1+b3
Severity: critical
Justification: breaks unrelated software
Dear Maintainer,
* What led up to the situation?
installed docker.io with existing qemu guests in bridge mode, did not
Control: tag -1 + moreinfo unreproducible
11.12.2023 14:51, Y :
Package: qemu-guest-agent
Version: 1:8.1.2+ds-1~bpo12+1
Severity: serious
Justification: 6
Dear Maintainer,
The problem arose after upgrading from bullseye to bookworm.
What did you upgrade, host or guest system?
All was OK
Control: reassign -1 dak
11.09.2023 08:40, Christian Marillat wrote:
Package: qemu-system-ppc
Version: 1:8.0.4+dfsg-3+b1
Severity: serious
File: /usr/bin/qemu-system-ppc
Dear Maintainer,
sudo apt-get install qemu-system-ppc qemu-system-data
...
The following packages have unmet dependencies:
Control: tag -1 + moreinfo unreproducible
09.09.2023 15:03, Mikhail Gusarov:
Source: qemu
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: dotted...@debian.org
Some cross-compilers are not available in bookworm, so qemu
09.09.2023 03:07, Peter Green:
async-tls has not switched upstream. On the other hand I don't
see any packages in Debian using it yet. ccing mjt to see what
the reason for packaging it was.
async-tls isn't my baby, count_omega (=werdahias, Cc'd) asked to sponsor it
on Jun-28 and I uploaded
On Sun, 13 Aug 2023 11:40:11 +0200 Aurelien Jarno wrote:
..
The solution to fix this is to use PYIMATH_OVERRIDE_PYTHON_INSTALL_DIR
to define the installation of the Python modules instead of relying on
autodetection.
Can't this be done at the cmake level instead of overriding this in each
Hi everyone!
Somehow I missed this whole issue, - I didn't see it until now.
Will adjust my mail filters.
08.08.2023 00:49, Philip Hands wrote:
Steve McIntyre writes:
On Wed, Jul 12, 2023 at 11:15:57AM +0200, Cyril Brulebois wrote:
Hi Michael,
Cyril Brulebois (2023-06-28):
Control:
15.05.2023 20:50, Michael Tokarev wrote:
15.05.2023 19:49, Bastian Germann wrote:
the qemu-system-* binaries depends on libsasl2-2, which is licensed under CMU's BSD-3-Clause-Attribution license and covered by the RSA-MD license.
They have clauses in place, which are known to be incompatible
15.05.2023 19:49, Bastian Germann wrote:
the qemu-system-* binaries depends on libsasl2-2, which is licensed under CMU's BSD-3-Clause-Attribution license and covered by the RSA-MD license.
They have clauses in place, which are known to be incompatible with GPL (as far as I can see the mentioned
Control: tag -1 + moreinfo
Control: found -1 1:3.0+dfsg-1
15.05.2023 19:49, Bastian Germann wrote:
Source: qemu
Version: 1:7.2+dfsg-6
Severity: serious
Hi,
the qemu-system-* binaries depends on libsasl2-2, which is licensed under CMU's BSD-3-Clause-Attribution license and covered by the
So, we tried to reproduce it on a different machine at IBM.
The problem doesn't show itself there.
I asked the debian admin team to reboot zelenka into 5.10.0-20 kernel
to verify, - there was no answer so far.
So I'm leaving this as it is now. If the next kernel update will
not fix the issue,
In the build logs for libguestfs, I see last successful builds were done
on 5.10.0-20-s390x kernel, and on 5.10.0-21-s390x, all builds fails.
5.10.0-21-s390x is the one running on zelenka too.
It looks to me like a kernel issue..
/mjt
So, many previous versions behave the same, including bullseye.
However.
1. I was able to create a 512-bytes qcow2 file once in /home/mjt on zelenka.
And.
2. All versions always work fine in /tmp, on a tmpfs.
Is it possible that the tests were running on a tmpfs before?
/mjt
Control: tag -1 + help
Control: found -1 1:5.2+dfsg-11+deb11u2
05.02.2023 20:30, Michael Tokarev wrote:
..
The thing is: I can't find *any* working version of qemu-img, they all
hang like described. This includes 1:7.2+dfsg-1+b1 too.
There's more: I installed bullseye on zelenka, and tried
04.02.2023 23:48, Hilko Bengen wrote:
..
Does 7.2+dfsg-1 work?
I don't have s390x environment so have no way to deal with this one.
No, it doesn't. On the porterbox (zelenka.debian.org) I was only able to
install 1:7.2+dfsg-1+b1 without rebuilding.
Oh, I forgot about zelenka. Tried that one
04.02.2023 23:19, Hilko Bengen wrote:
Package: src:qemu
Version: 1:7.2+dfsg-2
..
qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 512
would hang in what appears a tight loop (100% CPU).
Does 7.2+dfsg-1 work?
I don't have s390x environment so have no way to deal
Package: systemd
Version: 252.2-2~bpo11+1
Severity: serious
I just come across a situation where my notebook does not let me in while
I'm in a place where network is not available. This is entirely wrong.
After a painful debugging session, I found the debian-shipped file
19.12.2022 16:32, Michael Tokarev wrote:
..
Aargh. This is due to my attempts to upload security update without waiting
for the NEW processing. It *had* proper Breaks+Replaces, but I removed it all
in an attempt to clean up new package introduction.
Actually it's a lie, it has nothing to do
19.12.2022 14:29, Andreas Beckmann wrote:
Package: samba-ad-provision
Version: 2:4.17.3+dfsg-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Hi,
during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the
On Fri, 16 Dec 2022 11:50:18 + debian user wrote:
Package: login
Version: 1:4.13+dfsg1-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: r...@localhost.lan, Debian Security Team
Dear Maintainer,
please uncomment the line in /etc/login.defs that currently
On Sat, 26 Nov 2022 12:43:12 -0800 Alex Relis wrote:
Package: nvidia-driver
Version: 470.103.01-1~bpo11+1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
About a week ago, linux-image-6.0.0-0.deb11.2-amd64 was introduced in
bullseye-backports. The problem is that the
08.11.2022 17:50, Michael Tokarev wrote:
08.11.2022 17:11, Guillem Jover wrote:
[..]
If you are really seeing samba linked against old liburing not working
with the new liburing, then we'd need to dig further to see what else
might be missing, but I'm currently not seeing it just by a very
08.11.2022 16:44, Guillem Jover wrote:
Hi!
On Tue, 2022-11-08 at 16:32:25 +0300, Michael Tokarev wrote:
On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev wrote:
Source: liburing
Version: 2.3-1
Severity: grave
liburing 2.3 broke binary compatibility without bumping the soname.
Indeed
08.11.2022 17:11, Guillem Jover wrote:
[..]
If you are really seeing samba linked against old liburing not working
with the new liburing, then we'd need to dig further to see what else
might be missing, but I'm currently not seeing it just by a very quick
code staring.
Well. I already deleted
On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev wrote:
Source: liburing
Version: 2.3-1
Severity: grave
liburing 2.3 broke binary compatibility without bumping the soname.
In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
their sizes. Both of these structures are parts
Source: liburing
Version: 2.3-1
Severity: grave
liburing 2.3 broke binary compatibility without bumping the soname.
In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
their sizes. Both of these structures are parts of io_uring structure
which the main part of the API. Here's
ng mdadm package did not help.
Downgrading busybox-static to 1.35.0-2 fixed the issue.
Now this is interesting. In -3, I included these changes:
commit ac478f88b64d5884d5e81bcd8f8344f0ec72df6a
Author: Michael Tokarev
Date: Mon Oct 17 12:52:23 2022 +0300
deb,static:
Hmm. Other sssd packages are also affected by this.
Not only sssd-ad but sssd-ipa and sssd-ad-common.
Added the Breaks for these in Bullseye (and also in Ubuntu Jammy, which
has exactly the same problem). Will be in the next upload.
/mjt
01.11.2022 13:14, Ralph Boehme wrote:
On 11/1/22 09:15, Michael Tokarev via samba-technical wrote:
Control: tag -1 + upstream
Original context was at http://bugs.debian.org/1013259 , but whole
thing *now* has is about completely unnecessary soname bump of libndr
in 4.17 due to debugging
Control: tag -1 + upstream
Original context was at http://bugs.debian.org/1013259 , but whole thing *now*
has is about completely unnecessary soname bump of libndr in 4.17 due to
debugging
refinements.
01.11.2022 11:07, Michael Tokarev wrote:
01.11.2022 10:59, Michael Tokarev wrote
01.11.2022 10:59, Michael Tokarev wrote:
..
And this revealed one more issue here, now with samba 4.17. Where, the
same libndr.so again, has changed soname from libndr.so.2 to libndr.so.3!
And it looks like *this* is what you're talking about now, once 4.17 with
this new libndr.so.3 hits
Ok. This package appears to lack some love. Bugs are never closed
(I just closed a few bugreports which were fixed years ago), migration
status apparently is never checked, bugs actually are not watched/handled
(these 2 bugs are here for quite some time already). I pinged the maintainer
but he
According to the FAQ at
https://people.freedesktop.org/~dbn/pkg-config-guide.html#faq :
My library z uses libx internally, but does not expose libx data types in its
public API.
What do I put in my z.pc file?
Again, add the module to Requires.private if it supports pkg-config. In this
18.10.2022 09:41, Michael Tokarev wrote:
..
At least once I come across a case where pkgconfig --cflags were
actually needed - because this library's header file actually
included some other header file.
And iirc, it was an upstream bug, the dependency should have been
listed as non-private
18.10.2022 00:17, Michael Biebl wrote:
..
Patching the upstream provided .pc file in Debian feels odd, tbh.
Are you sure Requires.private is only relevant for static linking? Isn't this
what Libs.private is for.
Yes it feels odd indeed. The problem here is often due to lack of
understanding
16.10.2022 08:04, Adrian Bunk wrote:
...
With 0.10.3-1 vulkan is a new requirement, breaking the qemu build again:
https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A7.1%2Bdfsg-2%2Bb1=1665894634=0
The complete list is currently:
$ pkg-config --cflags virglrenderer
Package epoxy was
07.10.2022 18:53, Simon McVittie wrote:
On Fri, 07 Oct 2022 at 18:08:41 +0300, Michael Tokarev wrote:
In debian samba package, there's a strict versioned dependency of libldb2
for samba package - actually samba-dsdb-modules - the only package which
actually *uses* libldb.
I'm not sure that's
07.10.2022 18:08, Michael Tokarev wrote:
...
Removing the symver LDB_2.2.4 from libldb.so.2 was an ABI break, so libldb2
should have versioned Breaks against dependent packages that use the old
symver. It looks as though only the samba and maybe sssd source packages
will be affected by this.
I
Control: tag -1 + confirmed
07.10.2022 11:38, Simon McVittie wrote:
...
# smbclient --help
smbclient: /usr/lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4' not found
(required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)
Workaround: also upgrade samba-libs to the version from
On 26.09.2022 17:39, Justin Ossevoort wrote:
Package: qemu-system-data
Version: 1:5.2+dfsg-11+deb11u2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: deb...@internetionals.nl
Dear Maintainer,
The latest packages in Debian Bullseye Backports depend on
qemu-system-data
27.08.2022 03:35, Santiago Vila пишет:
Hi. Now that this is finally fixed in sid, here is a proposed diff for
bullseye, including changelog.
Heh. The changelog includes entry by me.. it is not fair for your contribution,
I think.. :)
BTW, should we drop the .1 from -3.1+deb11u2 release
25.08.2022 11:49, L. van Belle wrote:
...
The shown fix, commit aeaa786aceb0ea781ded2c151fb68f6b34880ad4
is the patch I added.
and cifs-utils 7.0 also fails to build without that patch with parallel=1
It's difficult to follow.
Commit aeaa786aceb0ea781ded2c151fb68f6b34880ad4 is wrong by its
Control: tag -1 + pending
22.08.2022 17:11, L. van Belle wrote:
I can confirm the patch works.
I've tested on a Debian Bullseye build with
cifs-utils 7.0 from https://ftp.samba.org/pub/linux-cifs/cifs-utils/
I refreshed patch 001.
Added the patch shown buy Helmut.
And I builded against Debian
Control: severity -1 normal
08.05.2022 02:18, Thorsten Glaser wrote:
..
In this bugreport, I see it is/was broken with -machine pc-1.1.
There's no indication if it is broken with other machine types. As
of qemu 5.2 (bullseye) machine types below pc-1.3 are deprecated, and
in 7.0 (current
06.05.2022 19:49, Mike Gabriel wrote:
..
at least the bugtitle is far to unprecise. Here, I test Debian Edu bullseye
really heavily and integrate FAI in Debian Edu.
The FAI installer and also the diskless machines I very often boot via iPXE/QEMU. In Debian 11 (and probably beyond), PXE booting
05.05.2022 13:47, Paul Gevers wrote:
Hi all,
[CC-ing src:debian-edu and src:qemu as they pull in src:ipxe-qemu into the key
package set, so I consider them stakeholders in this RC bug.]
On Fri, 12 Mar 2021 19:29:55 +0100 (CET) Thorsten Glaser
wrote:
So we now know without fail that there’s
Control: severity -1 normal
On Wed, 8 May 2019 22:35:53 +0200 "Steinar H. Gunderson"
wrote:
On Wed, May 08, 2019 at 10:02:46PM +0200, Mathieu Parent wrote:
> Downgrading the severity as the AppArmor side is already fixed it seems in
sid.
serious and grave are of equal severity; serious is
on
+all pythons. Closes: #1009204
+
+ -- Michael Tokarev Mon, 18 Apr 2022 17:39:33 +0300
+
vdirsyncer (0.18.0-6) unstable; urgency=medium
* avoid checking flaky test test_fuzzing;
diff -Nru vdirsyncer-0.18.0/debian/tests/control
vdirsyncer-0.18.0/debian/tests/control
--- vdirsyncer-0.18.0
[Resending whole thing. I think it is is important to have it publicly
available and to reach you, so adding it to the bugreport too.
Apparently team+dns@tracker.d.o isn't working and there's no archives]
I want to follow up on the todays ldns incident.
I think it was quite interesting.
The
BTW, Daniel, please re-tag 1.7.1-3 - this is what's at the tip of master now.
I hope anyway :)
Thanks,
/mjt
Fixed my branch on the ldns repo, rebasing it on top of now-okay master.
If we ever need one more 1.7 release it will be easier to rebase now with
the conflicts resolved.
I have to review my branch again, I think something might not be right
there after the rebase on top of dkg's changes. I
Okay guys.
I thought about this a bit more.
One wrong action by one developer does not make the environment
unhealthy.
I fixed the mess done to the master branch.
I think - provided this wont happen again - it's okay to work
on this to fix the rest of the mess done.
I'm doing this right now.
13.04.2022 21:19, Daniel Kahn Gillmor wrote:
..
reviewed and i'll push that to salsa as a "debian/experimental" branch
later today, if either of you want to take a look at what i'm
considering for release.
The whole thing was ready, polished, everything addressed.
If you wanted another 1.7.1
13.04.2022 21:29, Michael Tokarev wrote:
The only prob is that the master branch on the ldns repository is
seriously messed up.
Also you've made similar commits as I did, but in an incomplete way
(like the watch file update).
Thanks,
/mjt
13.04.2022 21:19, Daniel Kahn Gillmor wrote:
Hi Michael and Santiago--
I've now uploaded ldns 1.7.1-3 with the associated fix for 1009385. I'm
reviewing Michael's changes for 1.8.1, and they're looking good to me.
Thank you for all that work, Michael! I think we should consider
uploading
On 13.04.2022 16:44, Santiago Ruano Rincón wrote:
..
So what do we do now? I think the best is to include
this fix as 1.7.1-3 (provided it actually fixes the
issue) for now, instead of uploading 1.8.
Why just don't uploading 1.8.1?
Well, we know 1.7 (sort of) works while 1.8 might cause
[Just a quick follow-up]
On 13.04.2022 15:52, Santiago Ruano Rincón wrote:
[...]
It seems it was fixed on 1.8.0.
https://github.com/NLnetLabs/ldns/commit/4d2057f0b5220487882be1b19c302833b84cffe3
Wonderful.. :) Thank you Santiago!
So, the prob should've be there after just any
recompile of
13.04.2022 10:09, Michael Tokarev wrote:
..
But let's try.
How this utility is used in building of dns-root-data? Lemme take a look
at this package. If you can provide me some minimal testcase to produce
just the DS record which differs, it will be nice.
I don't have time for this today
13.04.2022 09:50, Daniel Kahn Gillmor wrote:
Control: reassign 1009385 libldns3 1.7.1-2.1
Control: retitle 1009385 libldns3 1.7.1-2.1 changes output of ldns-key2ds,
causing FTBFS on dns-root-data
Control: affects 1009385 + dns-root-data
X-Debbugs-Cc: Michael Tokarev
Control: tags 1009385
(3.10) and allows the python3.10 transition to
+happen, but it is not fixing the actual issiue with ldns using
+distutils which should be addressed later. Closes: #1008638
+
+ -- Michael Tokarev Thu, 07 Apr 2022 16:03:29 +0300
+
ldns (1.7.1-2) unstable; urgency=low
* Team upload
be addressed later. Closes: #1008638
+
+ -- Michael Tokarev Thu, 07 Apr 2022 16:03:29 +0300
+
ldns (1.7.1-2) unstable; urgency=low
* Team upload.
diff -Nru ldns-1.7.1/debian/patches/series ldns-1.7.1/debian/patches/series
--- ldns-1.7.1/debian/patches/series2020-06-03 23:55:03.0
23.03.2022 16:38, Diederik de Haas wrote:
On woensdag 23 maart 2022 06:54:57 CET Axel Beckert wrote:
Gian Piero Carrubba wrote:
Init: sysvinit (via /sbin/init)
Diederik de Haas wrote:
I do not have a /run/samba/ directory on my Bookworm system/server.
I don't think it's relevant, but it
Package: samba
Version: 2:4.13.13+dfsg-1~deb11u2
Severity: critical
Tags: patch upstream
Please see https://lists.samba.org/archive/samba/2022-February/239548.html and
https://lists.samba.org/archive/samba/2022-February/239577.html for the
description of the problem and how serious can it be,
23.10.2021 19:33, Lucas Nussbaum wrote:
Source: qemu
Version: 1:6.1+dfsg-6
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20211023 ftbfs-bullseye
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Control: severity -1 normal
Lowering severity of this bug to normal. It definitely is not grave
in my book, - this is a regular emulation bug which can't emulate
some specific code. Or else every emulation bug should be marked
"grave" as it affects "other software".
BTW, I for one can't
04.09.2021 14:33, Vincent Bernat wrote:
> Package: qemu-user-static
> Version: 1:6.1+dfsg-4
> Severity: critical
>
Hey!
Since 6.0, qemu-user-static does not seem to work properly through
binfmt. I am a bit lost on how to diagnose that:
...
When invoked through binfmt, the binaries seem to go
On Sat, 14 Aug 2021 08:28:41 + Roman Fiedler
wrote:
Package: bridge-utils
Version: 1.7-1
Severity: serious
When running "brctl addbr" and "ip link set [if] address" immediately
afterwards, the second command will fail to apply the address
change. This is somehow annoying as the MAC would
05.01.2021 13:44, Gianfranco Costamagna wrote:
...
after installing it looks still missing
Package 'libpcsclite', required by 'libcacard', not found
Oh. I missed this one. Will do another upload.
/mjt
05.01.2021 13:44, Gianfranco Costamagna wrote:
Source: libcacard
Version: 1:2.8.0-1
Severity: serious
Hello, libglib2.0-dev looks missing on -dev package?
pkg-config --short-errors --print-errors --cflags --libs "libcacard >= 2.5.1"
Package 'glib-2.0', required by 'libcacard', not found
I
Control: tag -1 + moreinfo
Control: severity -1 normal
26.12.2020 15:10, Charles Malaheenee wrote:
Package: qemu-system-x86
Version: 1:5.2+dfsg-2
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: malahee...@gmx.fr
Dear Maintainer,
Not sure is it related with
Control: severity -1 wishlist
Control: tag -1 wishlist
09.12.2020 11:59, Lucas Nussbaum wrote:
Source: edk2
Version: 2020.08-1
Severity: serious
Justification: FTBFS on ppc64el
Tags: bullseye sid ftbfs
Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el
Hi,
During a rebuild of all packages
30.11.2020 23:27, Paul Gevers wrote:
Hi all, Christian,
On Tue, 8 Sep 2020 15:40:11 +0200 Christian Ehrhardt
wrote:
Signed-off-by: Christian Ehrhardt
---
...raseReserved-override-driver-queue_p.patch | 74
...BlockEraseReserved-skip-unless-iSCSI.patch | 39
23.10.2020 19:50, Sebastian Ramacher wrote:
Source: qemu
Version: 1:5.1+dfsg-4
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)
binNMUs of qemu for the libbrlapi transition failed to build on armel
and armhf:
|
On Fri, 03 Jul 2020 18:45:07 +0900 Mike Hommey
wrote:
..
> Arguably, freetype2.pc shouldn't depend on libbrotlidec.pc except with a
> Required.private, assuming one doesn't actually need to include
> libbrotli headers or link against libbrotli library (presumably, that's
> the case).
The thing
01.02.2020 18:53, Adam Borowski wrote:
> Package: qemu-system-ppc
> Version: 1:4.2-2
> Severity: grave
> Justification: renders package uninstallable
>
> Hi!
> Upon upgrading or a fresh install:
>
> Unpacking qemu-system-ppc (1:4.2-2) ...
> dpkg: error processing archive
Control: severity -1 normal
Control: tag -1 + moreinfo
12.01.2020 18:37, peter green wrote:
> Package: qemu-block-extra
> Version: 1:4.2-1
> Severity: serious
>
> The binary packages built from the ceph source package were recently removed
> from mipsel, because the new version of ceph runs out
20.05.2019 16:07, Salvatore Bonaccorso wrote:
Hi
FTR, https://salsa.debian.org/qemu-team/qemu/merge_requests/6 for the
related changes in unstable (and to target buster).
Yeah, I comitted it the same day this issue popped up,
but forgot to push it (done now).
Thanks!
/mjt
Control: notfound -1 1:3.1+dfsg-4
16.02.2019 15:41, Moritz Muehlenhoff wrote:
Source: qemu
Severity: grave
Tags: security
When rdma was enabled in -3, this also made a fix for CVE-2018-20124 necessary:
Yes indeed.
But since this code has a ton of bugs (not only security) and is generally
Control: severity -1 minor
02.01.2019 1:03, Laurent Bigonville wrote:
Le 1/01/19 à 21:35, Michael Tokarev a érit :
[]>>> Well this bug has been reopened that mean that the package will never
migrate
That's sort of unfortunate...
Indeed, it would be unfortunate to not have 3.1
1 - 100 of 357 matches
Mail list logo
