Control: tag -1 + confirmed
Control: found -1 1:7.0+dfsg-2
I just tried to reproduce this and was able to see the same issue
with qemu-user-static 7.0.
However the issues here is not with python failing.
lyx does not even try to run the python script.
It first spawns /bin/sh -c "python3 -tt -V"
Version: 4.7.0-1
On Mon, 10 Jan 2022 12:40:59 +0100 mc36 wrote:
Package: qemu-system
Version: 1:6.2+dfsg-1
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
i recently moved to an ipv6-only netw
Control: tag -1 + moreinfo
On Thu, 13 Jan 2022 16:00:26 +0100 Andreas Beckmann wrote:
On 11/01/2022 08.25, Michael Tokarev wrote:
> 1. try qemu 6.2 (qemu-user-static is self-contained, more or less, so
> it can be installed on earlier debian releases too)
same behavior :-(
>
So.. what should we do?
Build it with libssl again because it is not ready to be used when
built with nettle, and reopen #828699?
Steinar, can you raise this upstream please?
It'd be good if whole unbound can be built with nettle instead of openssl,
and actually work :)
Thanks!
/mjt
Control: tag -1 - moreinfo
It looks there's an upstream TODO item about this:
o timers rfc 5011 support.
(see /usr/share/doc/unbound/TODO.gz)
/mjt
Control: tag -1 + wontfix
[Replying to a bug report which is more than 10 years old..]
On Tue, 21 Jul 2009 19:13:06 +0200 martin f krafft wrote:
..
> if the use case is 'lookup a DNS record and print it like
> bind9-host does' then bind9-host and unbound-host fit that
> description.
Right. A
This is interesting from a few other points of view.
unbound-host should probably not use /var/lib/unbound/root.key which
is an untrusted-owned file in an untrusted-owned directory.
So probably the default value for this root.key file should not
point to this location.
We probably can change bot
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 fo
Replying to an old bugreport which is marked as fixed since 1.5.9-2 version.
This is, in fact, a context of resolvconf, for which we have
several other bugreports.
This one has a lenghtly discussion and debugging.
But I can't understand the main thing there: why on the Earth one
needs to reloa
Control: tag -1 + moreinfo
So, will adding a Recommends: dns-root-data either to libunbound
or to various software packages (eg unbound-host) fix this?
I don't think adding this to libunbound is a good idea since software
using it isn't necessary being used the root key, but adding it to
the bin
28.04.2022 19:22, Ondřej Surý wrote:
On 28. 4. 2022, at 15:23, Michael Tokarev wrote:
Yeah. Formally we should do either one or another.
In practice I *highly* doubt anyone is using these 4
symbols, so maybe we can just disable the thing without
doing anything. I'm too lazy now to provid
28.04.2022 15:27, Ondřej Surý wrote:
..
Yes, it’s the old one. The 2012 hasn’t been specified for use
in DNSSEC - there was a draft, but it has expired.
Ok, that makes sense. Thank you for clarification.
Please note there are at least 4 symbols in the libldns3
library which are gost-related:
27.04.2022 12:08, Ondřej Surý wrote:
Hi,
GOST has been deprecated for use in DNSSEC, and the
actual standard actually says it MUST NOT be used for
signing (and MAY be used for verification), see RFC 8624.
I think the best course of action here is to actually disable it
everywhere where GOST R 3
27.04.2022 19:38, ceddral wrote:
...
attention now being explicit in the config. Now that I'm aware
I do believe a unix socket would be the more sensible default.
This variant (the unix socket) weren't always available.
It was implemented in version 1.5.2, and I wasn't aware
of this until 1.15.
27.04.2022 19:38, ceddral wrote:
..
Tested it, as far as i can tell it works for me with
chroot: "/var/lib/unbound"
and
control-interface: "/run/unbound-control.socket"
Thank you for confirming this. I too did the similar test locally,
you made me curious.
(and BindPaths=/run/systemd/notify:
Control: severity -1 wishlist
Control: tag -1 confirmed
27.04.2022 16:48, ceddral wrote:
Package: unbound
Version: 1.15.0-4
Severity: normal
X-Debbugs-Cc: debian...@ceddral.org
Dear Maintainer,
unbound package upgrade introduced a default config to enable remote-control
via tcp socket.
Can y
Control: tag -1 + moreinfo
Replying to an old bug...
On Tue, 19 Apr 2016 13:43:29 +0200 tkla wrote:
Package: smbclient
Version: 4.2.10
Severity: normal
Tags: upstream
Dear Maintainer,
since the badlock fixes my backup software Amanda stopped working when we're
trying to backup Windows shares.
27.04.2022 14:38, Salis, Antonello (NFOD) wrote:
The new update 2:4.16.0+dfsg-7 is affected as well.
Sure, there was nothing done in there about this issue.
Or else I'd mark it as fixed or at least asked you guys
to try it out :)
Thanks!
/mjt
This has been merged in a strange way. Here are the actual testcases:
ldns-dpa -f "&" -- -f for expression, a & b
ldns-keyfetcher '. .' -v (does not work w/o -v)
ldns-zcat /dev/null
/mjt
Control: severity -1 minor
Control: tag -1 + confirmed upstream
Control: found -1 1.8.1-1
On Wed, 31 Mar 2010 22:52:09 +0200 Piotr Engelking wrote:
Package: ldnsutils
Version: 1.6.4-4
Severity: normal
If the 'nameserver' option is not present in /etc/resolv.conf, drill
refuses to run:
Yeah,
Control: severity -1 minor
Control: tag -1 + wontfix upstream
On Tue, 02 Nov 2021 09:27:40 +0100 Bjørn Mork wrote:
Package: ldnsutils
Version: 1.7.1-2+b1
Severity: normal
File: /usr/bin/drill
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
...
This is the documented behaviour in debian. Qu
Control: tag -1 + moreinfo
Hello!
On Fri, 3 Dec 2021 17:05:59 +0100 Helmut Grohne wrote:
Source: ldns
Version: 1.7.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
ldns fails to cross build from source, because the python build
misdetects the python libraries and attempts
Control: tag -1 + moreinfo
On Tue, 9 May 2017 21:44:45 +0200 martin f krafft wrote:
Package: ldnsutils
Version: 1.7.0-1
Severity: normal
When trying ti use ldns-key2ds with -g, I get an error about GOST
not being available.
% ldns-key2ds -g -n _combined.key
error: libcrypto does n
Control: forcemerge -1 716056 716074
Control: tag -1 + confirmed upstream
Control: found -1 1.8.1-1
Control: retitle -1 numerous input/options parsing errors in ldns example
utilities
ldns-dpa -f "&" -- -f for expression, a & b
ldns-keyfetcher '. .' -v (does not work w/o -v)
ldns-zcat /dev/
In order to make this *significantly* easier, the whole thing boils down to:
ldns-dpa -f "&"
/mjt
So, is there anything else needed on my side to help this?
I can re-send the debdiff (the change against the previous one was the
removal of closing of #1002059 from d/changelog which slipped there by
mistake, and going from -1+deb11u4 to -1~deb11u4 per carnil@ suggestion.
Thanks,
/mjt
26.04.2022 10:37, Salvatore Bonaccorso wrote:
Hi,
On Fri, Apr 15, 2022 at 05:12:38PM +0300, Michael Tokarev wrote:
* switch from weird ~deb11uN to the usual +deb11uN release numbering scheme
since a more recent upstream version is available in testing now
It is not really a change per
Control: tag -1 + pending
So, should we add something like "pending" tag to this bug? ;)
I'm in the process of helping with samba package maintenance
for quite some time now... ;))
I come across this bug report because it popped up in tracker.d.o
page for another package I maintain, with a warni
Control: clone -1 -2
Control: reassing -2 smbclient 2:4.16.0+dfsg-1
Control: tag -2 - upstream patch
Control: block -2 by -1
Since this is something people see in samba and are trying to look up in between
samba bugs, let's clone it properly.
It would be really nice to have this patch backported
Control: tag -1 - patch
On Mon, 28 Jun 2021 18:23:08 +0300 Michael Tokarev wrote:
..
Please address this upstream. If the problem is real, I think this way everyone
will
benefit from this. I don't think patching this in Debian is a good idea, at
least I
want debian version to be as clo
Control: tag -1 - patch
On Sun, 20 Jan 2019 17:55:00 + Ben Hutchings wrote:
Package: qemu-user
Version: 1:3.1+dfsg-2
Severity: normal
Tags: patch
I've been building and testing klibc across many architectures using
qemu-user, and I found that qemu-user fails to load a few programs on
a few
Control: tag -1 + moreinfo - patch
On Tue, 26 Feb 2019 23:18:19 + Benjamin Moody
wrote:
Control: found 898772 1:3.1+dfsg-4
This bug does affect qemu 1:3.1+dfsg-4, except that the list of
known modifier keys is expanded to include "META_L" and "META_R".
The issue is thus somewhat less seve
23.04.2022 23:39, Michael Tokarev wrote:
Package: due
Version: 3.0.0-1
Severity: normal
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org
Please drop "qemu" package from Recommends. It makes no sense, qemu is
a dummy no-op package for a few debian releases already and is going a
24.04.2022 05:46, Shengjing Zhu wrote:
..
recommending qemu makes no sense. It is a dummy package
for a few debian releases already and is going away.
I think you have a broken script to find the affected package.
That script would be my own eyes and fingers, apparently ;)
packer only sugge
Package: due
Version: 3.0.0-1
Severity: normal
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org
Please drop "qemu" package from Recommends. It makes no sense, qemu is
a dummy no-op package for a few debian releases already and is going away.
/mjt
Package: packer
Version: 1.6.6+ds1-4
Severity: normal
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org
recommending qemu makes no sense. It is a dummy package
for a few debian releases already and is going away.
/mjt
Control: tag -1 + moreinfo
On Fri, 07 Aug 2020 10:33:25 +0200 "Josep M. Perez"
wrote:
Package: samba
Version: 2:4.12.5+dfsg-3
Severity: normal
Tags: upstream
X-Debbugs-Cc: josep.m.pe...@gmail.com
Dear Maintainer,
* What led up to the situation?
Enabled aio_pthread.
* What exactly did
On Tue, 02 Nov 2021 15:17:42 +0100 Laurent Grawet wrote:
Package: smbclient
Version: 2:4.13.5+dfsg-2
Severity: normal
Dear Maintainer,
* What led up to the situation? no way to choose between smb and
smbspool_krb5_wrapper cups backend
* What exactly did you do (or not do) that was effec
Control: tag -1 + moreinfo
So, as suggested by FeRD, has it been fixed by subsequent samba release(s)?
Louis, can you test a more recent version, or are you on stable/bullseye now
(which still does not have the mentioned fix)?
It looks like this issue has been fixed by 4.14...
Thanks,
/mjt
23.04.2022 11:28, Michael Tokarev wrote:
...
This also fixes a *sporaric* (rare) broken build which actually
happened with previous security update: #1006935, #1009855, #1002059
The #1002059 slipped there by a mistake. It is a different problem,
most likely a misconfiguration on the OP side
11uN release numbering scheme
+since a more recent upstream version is available in testing now
+ * d/salsa-ci.yml: target bullseye
+
+ -- Michael Tokarev Sat, 23 Apr 2022 11:13:39 +0300
+
samba (2:4.13.13+dfsg-1~deb11u3) bullseye-security; urgency=high
* Non-maintainer upload by the
Hello!
It turned out the security-uploaded build of samba on i386 is broken.
There were several reports about smbd segfaulting at startup or other
weirdness. This is specific to i386 build, the x64 build is fine (and
I know nothing about the other architectures).
An example bugreport is #1006935
22.04.2022 21:37, Michael Tokarev wrote:
Lemme re-build deb11u3 locally to see if this is maybe a build
issue?..
So I just rebuilt ~deb11u3 in a clean bullseye i386 schroot environment,
the standard way.
With the resulting samba-libs package samba does not crash at startup anymore,
and it all
22.04.2022 21:20, Michael Tokarev wrote:
..
Lemme see if to-be 4.13.13+dfsg-1+deb11u4 works...
And this one works indeed. There's no changes between deb11u3
and deb11u4 which can fix this issue, but the prob (with locally
built deb11u4) is gone. The build is performed on a stable
bul
Control: retitle -1 qemu-system-x86_64: ../../target/i386/kvm/kvm.c:2996:
kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
22.04.2022 20:34, Adrian Davey wrote:
Hi Michael,
Please ignore the 5.16.0-5-amd64 that is the laptop kernel, it only features on the bug report due to
Control: tag -1 + confirmed
22.04.2022 19:15, Andrés Maldonado wrote:
Hello,
I got the same problem as 1. after an 'apt upgrade', which upgraded Samba and it's dependencies from 2:4.13.13+dfsg-1~deb11u2 to
2:4.13.13+dfsg-1~deb11u3.
I'm on Debian Bullseye, I also use a i386 package and I have
22.04.2022 19:01, Adrian Davey wrote:
HI Michael,
Apologies the reportbug package is installed on a laptop, the issue is on a
headless system [..]
That's okay, that happens.
This headless server has both Kernel: Linux 5.16.0-6-amd64 as well as Linux
5.17.0-1-amd64 #1 SMP PREEMPT Debian 5.1
22.04.2022 17:10, Adrian Davey wrote:
Package: qemu-system-x86
Version: 1:7.0+dfsg-1
Severity: normal
2022-04-21T17:07:40.354354Z qemu-system-x86_64: warning: This feature depends
on other features that were not requested: CPUID.800AH:EDX.npt [bit 0]
As I said, this is unrelated.
2022-04
Control: tag -1 + moreinfo
22.04.2022 17:10, Adrian Davey wrote:
Package: qemu-system-x86
Version: 1:7.0+dfsg-1
Severity: normal
Dear Maintainer,
VMs controlled by libvirt failed to start when using "host" cpu type with kvm
acceleration
libvirt log gives:
2022-04-21T17:07:40.354354Z qemu-sys
20.04.2022 23:56, Petr Cech wrote:
Package: unbound
Version: 1.15.0-4
Severity: normal
Hi,
I have unbound installed but masked in systemd. So when postinst of
unbound runs unbound-resolvconf.service I end up with "broken"
resolv.conf pointing to localhost but with no running resolver.
I'm not su
Control: reassign -1 gvfs-backends 1.50.0-1
Control: tag -1 + upstream patch
20.04.2022 16:06, Salis, Antonello (NFOD) wrote:
Package: smbclient
Version: 2:4.16.0+dfsg-6
Debian testing
When I try to browse Windows folders with Nautilus or Nemo i get "Failed to
mount Window share: inval
20.04.2022 19:44, Michael Tokarev wrote:
..
An interesting find. I quickly browsed there, but don't immediately see a
solution in there. I'll take a closer look.
This appears to be the fix:
https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/138
(which is in gnome-vfs).
But does
20.04.2022 16:06, Salis, Antonello (NFOD) wrote:
Package: smbclient
Version: 2:4.16.0+dfsg-6
Debian testing
When I try to browse Windows folders with Nautilus or Nemo i get "Failed to
mount Window share: invalid argument".
This never happened before last week.
Does smbclient work by i
20.04.2022 16:18, Vincent Lefevre wrote:
On 2022-04-20 15:27:16 +0300, Michael Tokarev wrote:
..
This is exactly what dpkg does: it preserves local permission
changes for conffilies, even if you tell it to replace your locally-
modified conffile with a new conffile coming from the updated
Control: severity -1 normal
Control: tag -1 + moreinfo
20.04.2022 14:11, Vincent Lefevre wrote:
Package: unbound
Version: 1.15.0-3
Severity: important
In the upgrade to unbound 1.15.0-3, I chose to replace the script
to the default one (following the recent discussions, I intend to
revert to th
20.04.2022 00:58, Vincent Lefevre wrote:
On 2022-04-20 00:43:48 +0300, Michael Tokarev wrote:
20.04.2022 00:40, Vincent Lefevre wrote:
Well, systemd already have its own nameserver configuration and its
own resolver cache which does not need any reload of daemons, since
resolv.conf does not
20.04.2022 00:40, Vincent Lefevre wrote:
Well, systemd already have its own nameserver configuration and its
own resolver cache which does not need any reload of daemons, since
resolv.conf does not change (It does not change with resolvconf and
unbound running with resolvconf hook enabled, eithe
19.04.2022 23:38, Dennis Filder wrote:
I wasn't CC'ed, thus the late reply.
I didn't know either, Dennis. I just replied to the bug :)
But now I've a question: how the initial problem happened?
Okay, it smells like it is, and it definitely it should not be
copied from /usr/share/dns/root.key
On Wed, 5 Jan 2022 16:36:40 +0100 Vincent Lefevre wrote:
..
But I don't understand. The upstream nameservers are supposed to be
used as a fallback. Even if upstream nameservers do not perform DNSSEC
validation, this is still better than a failure when DNSSEC is not
required.
For the record, th
Control: tag -1 + upstream
Hello!
On Wed, 31 Jan 2018 22:12:59 -0500 Daniel Kahn Gillmor
wrote:
Package: unbound-anchor
Version: 1.6.7-1
Severity: wishlist
the dns-root-data package's debian/rules uses unbound-anchor in its
get_orig_source target. It currently specifies the path explicitly,
Control: tag -1 + confirmed upstream
Hello!
Replying to a bug from 2009, this is more than 12 years old! :)
On Tue, 21 Jul 2009 18:07:14 +0200 martin f krafft wrote:
Package: unbound-host
Version: 1.3.2-1
Severity: wishlist
File: /usr/bin/unbound-host
I understand unbound-host does not read
Control: tag -1 + confirmed
Hi Janus!
Replying to a bugreport which is more than 10 years old already.. :)
On Thu, 15 Sep 2011 11:46:58 +0200 Thue Janus Kristensen
wrote:
Package: unbound-host
Version: 1.4.12-1
Severity: normal
Dear Maintainer,
Using a simple "aptitude install unbound-host
Control: tag -1 + moreinfo unreproducible
On Sun, 26 Aug 2018 11:13:22 + root wrote:
Package: unbound
Version: 1.7.3-1
Severity: normal
Dear Maintainer,
* What led up to the situation?
trying to implement an unbound python module (python code executed
while the unbound serve
Control: tag -1 + upstream moreinfo
On Fri, 23 Nov 2018 07:19:05 + Peter Palfrader wrote:
Package: unbound
Version: 1.6.0-3+deb9u2
Severity: normal
Hi!
we have unbound configured as a recursor on most of our hosts,
and we have a few trust-anchors in addition to the root zone's
configured
19.04.2022 17:49, Vincent Lefevre wrote:
..
I don't think this is in the scope of resolvconf people, because
the whole purpose of resolvconf is different.
I don't know what you mean here. In my case, the purpose of resolvconf
is just to restart postfix each time /etc/resolv.conf is modified
r
19.04.2022 16:02, Vincent Lefevre wrote:
On 2022-04-19 15:15:11 +0300, Michael Tokarev wrote:
unbound resolvconf integration (the disabled one) works by setting
DNS servers obtained via DHCP to become the forwarders in
unbound. As simple as that. I'm not saying about 127.0.0.1
filtering
19.04.2022 14:11, Vincent Lefevre wrote:
On 2022-04-19 13:22:53 +0300, Michael Tokarev wrote:
In my understanding over the years, I expected the nameservers
received from/by DHCP should be used *first*. I did this with
unbound or dnsmasq even before resolvconf has been written -
using custom
On Mon, 18 Apr 2022 08:43:24 +0300 Michael Tokarev wrote:
..
Maybe we can always update this (very small) file as a part of the
daemon startup procedure.
It looks like I completely misunderstood this file purpose.
Am I right this is just the initial key and unbound updates
this key
19.04.2022 13:09, Vincent Lefevre wrote:
...> The way resolvconf expects it to work is to use the usual method,
and in case of an error, fall back to the upstream nameservers.
Since the upstream nameservers should be used as a fallback, I don't
see why this would be problematic.
hm.. now this
19.04.2022 12:59, Vincent Lefevre wrote:
On 2022-04-19 12:38:24 +0300, Michael Tokarev wrote:
..
I for one don't know what a maintainer has to do with this bug.
Note that I've let the bug closed since it is not clear that the
issue will occur again.
Oh. This is what happens when
19.04.2022 11:51, Vincent Lefevre wrote:
..
Since there is no way to know whether there was any fix (or even
any change that would make the issue disappear as a side effect),
let's rather tag the bug as unreproducible.
Hi Vincent!
Out of curiocity, what do you expect this bug staying like this
18.04.2022 22:25, James Cloos wrote:
closing the report like that makes no sense whatsoever.
Please feel free to reopen this bug report and be ready to provide
some more information to debug it and to find and fix the problem.
Lacking that it makes no sense whatsoever to keep it.
FWIW, 1.7.1-1
nd 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
Control: severity -1 normal
Control: tag -1 + confirmed
[ https://bugs.debian.org/927435 ]
The talk is about stretch -> buster upgrade.
John Eikenberry:
> Package: upgrade-reports
> Severity: normal
>
> After upgrading to buster, unbound-control would fail to run with this error..
>
> error:
Control: tag -1 + confirmed moreinfo
On Fri, 17 Jan 2020 22:39:27 +0800 hypeng wrote:
Package: unbound
Version: 1.9.4-2+b1
Severity: wishlist
Hi,
On Jun 2019, unbound supported the ipset that could add the domain's ip to a
list easily.Like dnsmasq.
use "./configure --enable-ipset" to enable
Control: tag -1 + moreinfo
On Tue, 27 Jul 2021 18:05:51 -0400 Marcus Furlong wrote:
Package: unbound
Version: 1.9.0-2+deb10u2
When starting unbound and binding to a specific interface using the
`interface` keyword, unbound can fail if the interface is not
configured correctly on boot.
Changin
Version: 1.15.0-1
On Mon, 25 Oct 2021 07:57:22 +0300 Aleksi Suhonen
wrote:
Package: unbound
Version: 1.13.1-1
Severity: normal
Our unbound crashed a twice over the weekend, until I shut it down and
replaced it with different software. Now that I'm back at work, I'm
looking at the logs and f
Control: tag -1 + confirmed
On Tue, 13 Jul 2021 01:11:30 + laalaa laalaa wrote:
Package: unbound
Version: 1.13.1-1
Severity: normal
After upgrade from buster to bullseye with same config file, port
127.0.0.1:8953 was additionally listened for.
From man page, this is "remote-control" port
On Wed, 19 Jan 2022 16:33:46 +0100 Vincent Lefevre wrote:
Package: unbound
Version: 1.13.1-1
Severity: important
Note: The changes I've done on /etc/resolvconf/update.d/unbound
is just logging messages (to known what's going on).
When /run/resolvconf/interface/NetworkManager is obsolete (which
13.04.2022 09:31, Helmut Grohne wrote:
Control: tags -1 + moreinfo
On Wed, Apr 13, 2022 at 09:13:58AM +0300, Michael Tokarev wrote:
No, as far as I understand. B/c udhcpc package lacks the main binary
if there's no busybox... ;)
Can you explain please? :)
Head -> table. I now unders
On Wed, 16 Jun 2021 18:57:26 +0200 Dennis Filder wrote:
Package: unbound
Version: 1.13.1-1
Severity: normal
Tags: patch
I ran out of space on /var and unbound still tried to update the root
trust anchor file which ended up empty. Then later after reboot the
package-helper failed to detect and
On Mon, 14 Mar 2022 23:58:37 +0100 "Steinar H. Gunderson"
wrote:
Package: libunbound8
Version: 1.13.1-1
Severity: normal
Hi,
We were investigating a performance regression in production that crept
in at some point (we noticed by accident that something had become very slow
and started investi
3738-dsdb-crash-4.13-v03.patch
+to make patch deapply happy (quilt does not notice this situation)
+ * switch from weird ~deb11uN to the usual +deb11uN release numbering scheme
+since a more recent upstream version is available in testing now
+ * d/salsa-ci.yml: target bullseye
+
+ -- Michae
[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 whol
13.04.2022 22:37, Daniel Lakeland wrote:
My wife has a dual mirrored glusterfs file server that is used for central storage of biology research data. They'd been running old versions of
Debian, until one of them had a hard drive failure. After replacing hardware and installing the latest Debian r
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 will
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 up
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 1.8.1
On Mon, 30 Jul 2018 12:37:50 +0200 Matthias Klose wrote:
Package: autodep8
Version: 0.13
Severity: important
The python autopkg tests are always run for all supported python versions,
ignoring, if a module is available for all available versions. This is the case
for extensions only built for
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
surp
[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 ldn
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
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
11.04.2022 15:21, Helmut Grohne wrote:
Source: busybox
Version: 1:1.30.1-7
Severity: wishlist
Tags: patch
Hi Aurelien,
would it be possible to avoid the udhcpc -> busybox dependency? It may
seem strange to remove busybox in a quest to reduce file system usage at
first, but if you need iproute2
Package: dpkg
Version: 1.21.7
Severity: minor
Tags: patch
/usr/share/dpkg/architecture.mk sets up variables in a way so that
every single variable out of 33 DEB_{HOST,..}_{ARCH,..} total is
set separately by its own call to dpkg-architecture if it is not
already defined.
On my (not slow at all) s
On Sat, 30 May 2020 18:25:55 +0200 Francois Gouget wrote:
Package: python-talloc
Version: 2.1.14-2
Severity: normal
Dear Maintainer,
python-talloc is 'multiarch: same' but the i386 package is not coinstallable
with the amd64 one because of their python dependency.
Hi!
Aside of this package
Hello!
On Mon, 10 Jan 2022 20:44:31 +0100 Helmut Grohne wrote:
Source: talloc
Version: 2.3.3-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs
talloc fails to cross build from source. I'm inclined to say it's
because waf. Really, stop using waf if you can.
501 - 600 of 2612 matches
Mail list logo
