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
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 into experimental while we wait for 1.7.1-3 to
Thanks both Michael and Santiago for sorting this out!
I agree that backporting
https://github.com/NLnetLabs/ldns/commit/4d2057f0b5220487882be1b19c302833b84cffe3
to 1.7.1 is the most reasonable/conservative fix. We want that to
propagate into testing as soon as possible without risking being bloc
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
El 13/04/22 a las 16:25, Michael Tokarev escribió:
> [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 Santi
Processing control commands:
> forwarded -1 https://github.com/NLnetLabs/ldns/issues/142
Bug #1009385 [libldns3] libldns3 1.7.1-2.1 changes output of ldns-key2ds,
causing FTBFS on dns-root-data
Set Bug forwarded-to-address to 'https://github.com/NLnetLabs/ldns/issues/142'.
> tags -1 + pending
Bug
Control: forwarded -1 https://github.com/NLnetLabs/ldns/issues/142
Control: tags -1 + pending
On Wed, 13 Apr 2022 14:52:58 +0200 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?=
wrote:
> Control: tags -1 + upstream
> Control: tags -1 + forwarded https://github.com/NLnetLabs/ldns/issues/142
🙈
> El 13/0
[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
Processing control commands:
> tags -1 + upstream
Bug #1009385 [libldns3] libldns3 1.7.1-2.1 changes output of ldns-key2ds,
causing FTBFS on dns-root-data
Added tag(s) upstream.
> tags -1 + forwarded https://github.com/NLnetLabs/ldns/issues/142
Unknown tag/s: forwarded, https://github.com/NLnetLa
Control: tags -1 + upstream
Control: tags -1 + forwarded https://github.com/NLnetLabs/ldns/issues/142
El 13/04/22 a las 10:37, Michael Tokarev escribió:
> 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
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.
Th
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 + help
Processing control commands:
> reassign 1009385 libldns3 1.7.1-2.1
Bug #1009385 [src:dns-root-data] dns-root-data: FTBFS: root-anchors.ds root.ds
differ
Bug reassigned from package 'src:dns-root-data' to 'libldns3'.
No longer marked as found in versions dns-root-data/2021011101.
Ignoring request
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 + help
Lucas, thanks for flagging this!
The build f
Source: dns-root-data
Version: 2021011101
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20220412 ftbfs-bookworm
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> make[1]: Ente
20 matches
Mail list logo
