Bug#1069499: mtbl: FTBFS on armhf: dh_auto_test: error: make -j4 check "TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 returned exit code 2
Lucas Nussbaum wrote: > Source: mtbl > Version: 1.3.0-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armhf > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on armhf. > > > Relevant part (hopefully): > > test-sorted-merge: t/test-sorted-merge.c:96: quiet_tmpnam: Assertion > > `not_found == 1' failed. Hi, Lucas: I see the function that failed here has been entirely rewritten since this release, so I've uploaded the latest upstream version 1.6.1 and that built successfully on all architectures. So I'll mark this bug fixed in 1.6.1-1. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#1068489: O: clamassassin -- email virus filter wrapper for ClamAV
Package: wnpp Severity: normal X-Debbugs-Cc: clamassas...@packages.debian.org Control: affects -1 + src:clamassassin I intend to orphan the clamassassin package. I no longer use this package, and I'm not sure if upstream is still maintaining it (I could not find a current location distributing this software). Nowadays I think there are plugins for rspamd and spamassassin that can do this kind of scanning. The package description is: clamassassin is a simple virus filter wrapper for ClamAV for use in procmail filters and similar applications. clamassassin's interface is similar to that of spamassassin, making it easy to implement for those familiar with that tool. clamassassin is designed with an emphasis on security, robustness and simplicity.
Bug#1061928: avro-c: NMU diff for 64-bit time_t transition
Steve Langasek wrote: > Hi Robert, > > On Tue, Jan 30, 2024 at 02:05:11PM -0500, Robert Edmonds wrote: > > Steve Langasek wrote: > > > As part of the 64-bit time_t transition required to support 32-bit > > > architectures in 2038 and beyond > > > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > > > avro-c as a source package shipping runtime libraries whose ABI > > > either is affected by the change in size of time_t, or could not be > > > analyzed via abi-compliance-checker (and therefore to be on the safe > > > side we assume is affected). > > > Hi, Steve: > > > I'm not aware of anything in avro-c that embeds time_t, or really any > > platform-provided structs, into the API/ABI. Can you point me to the > > actual changes in the avro-c ABI due to this change? > > > Thanks! > > avro-c falls into the second of these categories, "or could not be analyzed > and therefore we assume is affected". > > Output of the attempt to analyze the package with abi-compliance-checker: > https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/libavro-dev/base/log.txt Ah, I see, so basically every header in the -dev package is getting included: // add includes #include "/usr/include/avro/allocation.h" #include "/usr/include/avro/basics.h" #include "/usr/include/avro/consumer.h" #include "/usr/include/avro/data.h" #include "/usr/include/avro/errors.h" #include "/usr/include/avro/generic.h" #include "/usr/include/avro/io.h" #include "/usr/include/avro/legacy.h" #include "/usr/include/avro/msinttypes.h" #include "/usr/include/avro/msstdint.h" #include "/usr/include/avro/platform.h" #include "/usr/include/avro/refcount.h" #include "/usr/include/avro/resolver.h" #include "/usr/include/avro/schema.h" #include "/usr/include/avro/value.h" #include "/usr/include/avro.h" I guess you have to do it that way since there isn't really anything universal and machine readable that says: this is the public API header file to include to use this library. For avro-c in particular the documentation of the library is here: https://avro.apache.org/docs/1.11.1/api/c/ And they only mention including to users of the library. So those headers that work around problems on Microsoft platforms don't end up getting included on other systems since the #include's of those headers are conditionalized. > This shows there are headers that can't be compiled because they're > Windows-specific. So it seems counterproductive to ship these at all in > Debian? > > If this header were removed from the package, or if a quirk were added to > https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads > to exclude the incorrect headers from the analysis, we could confirm that > avro-c is unaffected and avoid unnecessary NMUs / transitions to unstable. If there is a way to quirk the avro-c package for this analysis so you only include /usr/include/avro.h rather than every header file shipped in the -dev package I think it would let your analysis succeed, without missing anything, and, I would guess that that analysis would show no ABI changes and thus no ABI transition is necessary. I'm also open to just dropping those ms*.h files from the -dev package which should just work without any other changes without breaking anything else, but I haven't tested it. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#1061928: avro-c: NMU diff for 64-bit time_t transition
Steve Langasek wrote: > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > avro-c as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). Hi, Steve: I'm not aware of anything in avro-c that embeds time_t, or really any platform-provided structs, into the API/ABI. Can you point me to the actual changes in the avro-c ABI due to this change? Thanks! -- Robert Edmonds edmo...@debian.org
Bug#1059505: ffmpeg: Library dependency with __attribute__((constructor)) function
d_init () at
/lib/x86_64-linux-gnu/libopenblas.so.0
#5 0x7fffe7e6807f in gotoblas_init () at
/lib/x86_64-linux-gnu/libopenblas.so.0
#6 0x77fcfe3e in call_init (env=0x7fffe7f8,
argv=0x7fffe7e8, argc=1, l=) at ./elf/dl-init.c:74
#7 call_init (l=, argc=1, argv=0x7fffe7e8,
env=0x7fffe7f8) at ./elf/dl-init.c:26
#8 0x77fcff24 in _dl_init (main_map=0x77ffe2c0, argc=1,
argv=0x7fffe7e8, env=0x7fffe7f8) at ./elf/dl-init.c:121
#9 0x77fe5500 in _dl_start_user () at /lib64/ld-linux-x86-64.so.2
#10 0x0001 in ()
#11 0x7fffeaf7 in ()
#12 0x in ()
(gdb)
Stack frames 5 and 6 show the dynamic loader calling gotoblas_init() in
libopenblas.so.0, before main() starts. And here's that function in
openblas:
https://sources.debian.org/src/openblas/0.3.25%2Bds-1/driver/others/memory.c/#L1507
Anyway, it would be nice if all programs linked against libavfilter or
libavdevice weren't forced to start up a thread pool for some other
library that happens to get pulled in but is otherwise unused. I'm not
aware of a technique to prevent a constructor function in a shared
library from running.
It looks like this is caused by ffmpeg being compiled with
--enable-pocketsphinx (at least on amd64), and indirectly by
libopenblas's API relying on an implicit __attribute__((constructor))
library initialization function rather than having an explicit library
initialization function.
Feel free to reassign this bug to src:openblas, or to clone it and
reassign to src:openblas.
Thanks!
--
Robert Edmonds
edmo...@debian.org
/*
* Compile with:
*
* gcc -O2 -Wall -o avfilter_test avfilter_test.c $(pkg-config --cflags --libs libavfilter)
*/
#define _GNU_SOURCE
#include
#include
#include
#include
int main(void) {
puts(avfilter_configuration());
putchar('\n');
char *cmd = NULL;
asprintf(, "cat /proc/%d/status | grep ^Threads", (int)getpid());
return system(cmd);
}
Bug#1042250: bup: FTBFS: dh_auto_test: error: make -j8 test "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
It looks like this is a brittle unit test. Lucas Nussbaum wrote: > > Failures: > > ! /<>/test/ext/test-help:35 '1' = '0' FAILED This line is: WVPASSEQ 1 $(bup help save | head -1 | grep -cF 'bup-save(1)') The hyphen in the grep expression "bup-save(1)" in the unit test is the ordinary ASCII character 45: ASCII 2/13 is decimal 045, hex 2d, octal 055, bits 00101101: prints as `-' Official name: Hyphen Other names: Dash, Minus, Worm That matches the output of "bup help save | head -1" in the C locale: root@8f8c3e4ea090:/# LC_ALL=C LANG=C bup help save | head -1 | hd troff::5: warning: cannot select font 'CB' troff::152: warning: cannot select font 'C' vv 62 75 70 2d 73 61 76 65 28 31 29 20 20 20 20 20 |bup-save(1) | ^^ 0010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | * 0070 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 62 | b| 0080 75 70 2d 73 61 76 65 28 31 29 0a |up-save(1).| 008b root@8f8c3e4ea090:/# > The full build log is available from: > http://qa-logs.debian.net/2023/07/26/bup_0.33.2-1_unstable.log User Environment […] LANG=C.UTF-8 LC_ALL=C.UTF-8 […] However, with a UTF-8 locale I see the hyphen being encoded as the byte sequence 0xE2 0x80 0x90: root@8f8c3e4ea090:/# LC_ALL=C.UTF-8 LANG=C.UTF-8 bup help save | head -1 | hd troff::5: warning: cannot select font 'CB' troff::152: warning: cannot select font 'C' 62 75 70 e2 80 90 73 61 76 65 28 31 29 20 20 20 |bup...save(1) | 0010 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | | * 0080 20 62 75 70 e2 80 90 73 61 76 65 28 31 29 0a | bup...save(1).| 008f root@8f8c3e4ea090:/# Which is the UTF-8 encoding of the Unicode character U+2010 'HYPHEN'. So I guess the bup unit tests should probably set LANG/LC_ALL explicitly. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#1040623: bookworm-pu: package bup/0.33.2-1+deb12u1
Adam D. Barratt wrote:
> On Sat, 2023-07-08 at 02:24 -0400, Robert Edmonds wrote:
> > I'd like to update the version of bup in bookworm from 0.33-2 to
> > 0.33.2-1+deb12u1, which incorporates two upstream bugfix releases for
> > a bug deemed important enough by upstream to issue point releases.
> >
>
> The version number for p-u needs to be lower than unstable. This looks
> like a backport of 0.33.2-1 from unstable, so the convention would be
> 0.33.2-1~deb12u1.
>
> Feel free to re-upload with the corrected version number; there's no
> need to wait for the original upload to be rejected.
Uploaded with the corrected version number. Interdebdiff from the
rejected version below.
Thanks!
diff -u bup-0.33.2/debian/changelog bup-0.33.2/debian/changelog
--- bup-0.33.2/debian/changelog 2023-07-08 01:17:38.0 -0400
+++ bup-0.33.2/debian/changelog 2023-07-08 16:11:59.0 -0400
@@ -1,9 +1,9 @@
-bup (0.33.2-1+deb12u1) bookworm; urgency=medium
+bup (0.33.2-1~deb12u1) bookworm; urgency=medium
* Upstream version 0.33.2, with a fix for a problem that can cause POSIX.1e
ACLs to be restored incorrectly.
- -- Robert Edmonds Sat, 08 Jul 2023 01:17:38 -0400
+ -- Robert Edmonds Sat, 08 Jul 2023 16:11:59 -0400
bup (0.33.2-1) unstable; urgency=medium
diff -u bup-0.33.2/debian/patches/debian-changes
bup-0.33.2/debian/patches/debian-changes
--- bup-0.33.2/debian/patches/debian-changes2023-07-08 01:17:38.0
-0400
+++ bup-0.33.2/debian/patches/debian-changes2023-07-08 16:11:59.0
-0400
@@ -30,4 +30,4 @@
-date='2023-07-01 15:08:43 -0500'
-+commit='61307904e4133b55acf7c2794da47fafecedf5af'
-+date='2023-07-08 01:27:47 -0400'
++commit='db4734ba24249fee8060a186e03e6173ce2e5d55'
++date='2023-07-08 16:12:37 -0400'
modified=False
--
Robert Edmonds
edmo...@debian.org
Bug#1040623: bookworm-pu: package bup/0.33.2-1+deb12u1
3 - Changes in 0.33 as compared to 0.32 - Changes in 0.32 as compared to 0.31 - Changes in 0.31 as compared to 0.30.1 @@ -103,9 +105,9 @@ Test status === -| master | +| main | || -| [](https://cirrus-ci.com/github/bup/bup) | +| [](https://cirrus-ci.com/github/bup/bup) | Getting started === @@ -119,12 +121,12 @@ git clone https://github.com/bup/bup ``` - - This will leave you on the master branch, which is perfect if you + - This will leave you on the main branch, which is perfect if you would like to help with development, but if you'd just like to use bup, please check out the latest stable release like this: ```sh -git checkout 0.33 +git checkout 0.33.2 ``` You can see the latest stable release here: diff -Nru bup-0.33/config/configure bup-0.33.2/config/configure --- bup-0.33/config/configure 2022-10-16 17:18:38.0 -0400 +++ bup-0.33.2/config/configure 2023-07-01 16:08:43.0 -0400 @@ -86,6 +86,12 @@ bup-add-cflag-if-supported -Wno-unused-command-line-argument +# Since ./configure changes pwd, fix MAKE if it's relative +case "$MAKE" in +/*) ;; +*/*) MAKE="../../$MAKE";; +esac + for make_candidate in make gmake; do found_make="$(bup_find_prog "$make_candidate" "$MAKE")" if test "$found_make" \ @@ -119,7 +125,7 @@ "$BUP_PYTHON_CONFIG") fi else -for py_min_ver in 10 9 8 7 6; do +for py_min_ver in 11 10 9 8 7; do bup_python_config="$(bup_find_prog "python3.$py_min_ver-config" '')" test -z "$bup_python_config" || break done diff -Nru bup-0.33/debian/changelog bup-0.33.2/debian/changelog --- bup-0.33/debian/changelog 2022-12-26 22:27:53.0 -0500 +++ bup-0.33.2/debian/changelog 2023-07-08 01:17:38.0 -0400 @@ -1,3 +1,50 @@ +bup (0.33.2-1+deb12u1) bookworm; urgency=medium + + * Upstream version 0.33.2, with a fix for a problem that can cause POSIX.1e +ACLs to be restored incorrectly. + + -- Robert Edmonds Sat, 08 Jul 2023 01:17:38 -0400 + +bup (0.33.2-1) unstable; urgency=medium + + [ Rob Browning ] + * 0.33.2 +- Update base_version for 0.33.2 development +- correct_posix1e_v1_delimiters: provide path for error messages + (Closes: #1039089) +- Update docs for 0.33.2 release +- Update base_version for 0.33.2 release + + [ Robert Edmonds ] + * New upstream version 0.33.2 + * debian/docs: Include upstream release note '0.33.2-from-0.33.1.md' + + -- Robert Edmonds Sat, 01 Jul 2023 18:51:02 -0400 + +bup (0.33.1-1) unstable; urgency=medium + + [ Rob Browning ] + * 0.33.1 +- conftest.py: switch to Path to support pytest 7+ +- conftest.py: restore support for pytest < 7 +- configure: handle relative MAKE paths +- test_get: remove vestigial debug messages +- configure: allow and prefer python3.11-config; ignore 3.6 +- buptest init: get quote from shlex not pipes +- test-comparative-split-join: accommodate varying HEAD names +- cirrus: move to freebsd 12.4 to fix rsync-related test failures +- compare-trees: add --features and disallow args with it and -h +- Restore posix1e default acls as default, not access; improve tests +- Fix ACL metadata format; delimit short form entries with commas +- Update docs for 0.33.1 release +- Update base_version for 0.33.1 release + + [ Robert Edmonds ] + * New upstream version 0.33.1 (Closes: #1038609) + * debian/docs: Include upstream release note '0.33.1-from-0.33.md' + + -- Robert Edmonds Sun, 18 Jun 2023 19:57:44 -0400 + bup (0.33-2) unstable; urgency=medium * Upload to unstable. diff -Nru bup-0.33/debian/docs bup-0.33.2/debian/docs --- bup-0.33/debian/docs2022-12-26 22:27:53.0 -0500 +++ bup-0.33.2/debian/docs 2023-07-08 01:17:38.0 -0400 @@ -1,2 +1,4 @@ README README.md +note/0.33.1-from-0.33.md +note/0.33.2-from-0.33.1.md diff -Nru bup-0.33/debian/patches/debian-changes bup-0.33.2/debian/patches/debian-changes --- bup-0.33/debian/patches/debian-changes 2022-12-26 22:27:53.0 -0500 +++ bup-0.33.2/debian/patches/debian-changes2023-07-08 01:17:38.0 -0400 @@ -3,8 +3,8 @@ in some VCS, and exported as a single patch instead of more manageable atomic patches. bup-0.33.orig/GNUmakefile -+++ bup-0.33/GNUmakefile +--- bup-0.33.2.orig/GNUmakefile bup-0.33.2/GNUmakefile @@ -61,7 +61,7 @@ else test_tmp := $(CURDIR)/test/tmp endif @@ -23,11 +23,11 @@ $(current_sampledata) $(current_sampledata): bup-0.33.orig/lib/bup/source_info.py -+++ bup-0.33/lib/bup/source_info.py +--- bup-0.33.2.orig/lib/bup/source_inf
Bug#1039556: ITP: volare -- tiling, tabbed Wayland compositor based on Sway
Package: wnpp Severity: wishlist Owner: Robert Edmonds * Package name: volare Version : No releases yet Upstream Author : Arnout Engelen * URL : https://codeberg.org/raboof/volare * License : MIT Programming Lang: C Description : tiling, tabbed Wayland compositor based on Sway Volare is a tabbed, tiling Wayland compositor based on Sway, with modifications to make its window management behavior similar to that of the Notion window manager. Many tiling window managers are "dynamic", meaning they automatically change the tiling layout as windows appear and disappear. Volare's behavior is more static, keeping the user's existing tiling layout in place without automatically rearranging the tiling layout as application windows are created, moved, or destroyed. -- Robert Edmonds edmo...@debian.org
Bug#1037287: AttributeError: 'NoneType' object has no attribute 'hardlink_target'
Nicholas Guriev wrote: > Since some time bup is unable to backup my data. This is apparently related to > hard links somehow. > bup "-d" > "/media/mymedia/a3907ce1-af8b-40b1-b26b-f37322e39382/barberry-kde-backups" > "save" "-n" "kup" "-vv" "/home/mymedia" "/home/mymedia/.steam/steam/config" > "/home/mymedia/.steam/steam/userdata" > Traceback (most recent call last): > File "/usr/lib/bup/cmd/bup-save", line 413, in > meta.hardlink_target = find_hardlink_target(hlink_db, ent) > AttributeError: 'NoneType' object has no attribute 'hardlink_target' > Exception ignored in: > Traceback (most recent call last): > File "/usr/lib/bup/cmd/../bup/git.py", line 722, in __del__ > File "/usr/lib/bup/cmd/../bup/git.py", line 919, in close > File "/usr/lib/bup/cmd/../bup/git.py", line 897, in _end > File "/usr/lib/bup/cmd/../bup/git.py", line 942, in write > NameError: name 'open' is not defined Hi, I'd suggest normal bug debugging steps like "bup fsck" or "bup index --clear" and if that doesn't fix the problem, try posting on the upstream bup mailing list (https://groups.google.com/g/bup-list). -- Robert Edmonds edmo...@debian.org
Bug#1038609: POSIX1e ACL correctness fixes (0.32.1, 0.33.1)
Package: bup Version: 0.32-3 Severity: important Tags: upstream X-Debbugs-Cc: r...@defaultvalue.org bup upstream has released two related point releases of bup (0.32.1, 0.33.1) which more correctly save and restore POSIX1e ACLs. bup 0.32 (oldstable) and bup 0.33 (stable, unstable) are currently affected and should be updated to the point releases. The upstream notes for 0.32.1 [0] and 0.33.1 [1] are reproduced below. [0]: https://github.com/bup/bup/blob/main/note/0.32.1-from-0.32.md [1]: https://github.com/bup/bup/blob/main/note/0.33.1-from-0.33.md Notable changes in 0.32.1 since 0.32 Bugs * POSIX1e ACLs should be restored more correctly now. Previously bup incorrectly restored default (`ACL_TYPE_DEFAULT`) ACLs as access acls (`ACL_TYPE_ACCESS`). When both existed, it restored the access ACL first and then the default ACL as an access ACL. Now, bup should restore each with the proper type. This issue only affects saves created on platforms where bup currently supports ACLs, so presumably mostly just saves created on Linux since the current ACL support depends on non-standard functions like `acl_extended(3)`. There is one remaining issue, which isn't fixed in this release, but is fixed in 0.33.1 (because fixing it here could create saves that are backward incompatible with 0.33). The problem is that in this version and older versions, bup stores ACLs in the `acl_to_any_text(3)` format with a newline delimiter, when the standard (and `acl_from_text(3)` which restore depends on) requires commas. This may cause restores that include ACLs (likely only those from Linux right now) to fail on some platforms (e.g. Cygwin). Notable changes in 0.33.1 since 0.33 Bugs * POSIX1e ACLs should be restored correctly now. Previously there were two problems. First, bup incorrectly restored default (`ACL_TYPE_DEFAULT`) ACLs as access acls (`ACL_TYPE_ACCESS`). When both existed, it restored the access ACL first and then the default ACL as an access ACL. Now, bup should restore each with the proper type. This issue only affects saves created on platforms where bup currently supports ACLs, so presumably mostly just saves created on Linux since the current ACL support depends on non-standard functions like `acl_extended(3)`. Second, bup stored ACLs in the `acl_to_any_text(3)` format with a newlne delimiter, when the standard (and `acl_from_text(3)` which restore depends on) requires commas. Now bup uses commas, and translates previously created saves during restore when possible. If a previously created ACL entry contains a comma, then bup will give up, report an error, and skip it. If nothing else, this could cause restores of relevant saves to fail on some platforms.
Bug#1036538: ITP: emptty -- Dead simple CLI Display Manager on TTY
Package: wnpp Severity: wishlist Owner: Robert Edmonds * Package name: emptty Version : 0.10.0-1 Upstream Author : Michal Tvrznik * URL : https://github.com/tvrzna/emptty * License : Expat Programming Lang: Go Description : text-based display manager for starting graphical sessions emptty is a simple, text-based display manager for starting Wayland or Xorg sessions from a virtual console. It allows the user to interactively select a specific desktop environment or window manager to start and remembers the user's selection. The types of sessions that can be started can be configured system-wide or by the user. -- Robert Edmonds edmo...@debian.org
Bug#992649: run-parts in /usr/bin breaks systemd-cron
Package: debianutils Version: 5.3-1 Severity: important Hi, systemd-cron's cron targets fail without being able to invoke /bin/run-parts, e.g.: ● cron-daily.service - systemd-cron daily script service Loaded: loaded (/lib/systemd/system/cron-daily.service; static) Active: failed (Result: exit-code) since Sat 2021-08-21 06:25:03 EDT; 41ms ago Docs: man:systemd.cron(7) Process: 833540 ExecStartPre=/lib/systemd-cron/boot_delay 5 (code=exited, status=0/SUCCESS) Process: 833541 ExecStart=/bin/run-parts --report /etc/cron.daily (code=exited, status=203/EXEC) Main PID: 833541 (code=exited, status=203/EXEC) CPU: 27ms Aug 21 06:25:03 chase systemd[1]: Starting systemd-cron daily script service... Aug 21 06:25:03 chase systemd[833541]: cron-daily.service: Failed to locate executable /bin/run-parts: No such file or directory Aug 21 06:25:03 chase systemd[833541]: cron-daily.service: Failed at step EXEC spawning /bin/run-parts: No such file or directory Aug 21 06:25:03 chase systemd[1]: cron-daily.service: Main process exited, code=exited, status=203/EXEC Aug 21 06:25:03 chase systemd[1]: cron-daily.service: Failed with result 'exit-code'. Aug 21 06:25:03 chase systemd[1]: Failed to start systemd-cron daily script service. Aug 21 06:25:03 chase systemd[1]: cron-daily.service: Triggering OnFailure= dependencies. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages debianutils depends on: ii libc6 2.31-16 debianutils recommends no packages. debianutils suggests no packages. -- no debconf information -- Robert Edmonds edmo...@debian.org
Bug#991419: new upstream (0.7.1)
Daniel Baumann wrote: > Package: ck > > Hi Robert > > Thank you for maintaining "ck" in Debian. > > One of my packages (dnsperf) requires ck which unfortunately is > currently not build on armel. I've locally built and verified the > current "ck" upstream version (0.7.1) on amd64/i386 and all arm* > architectures. > > I saw that your last upload of it was in 2017 and collected some dust > since. Are you still interested in maintaining "ck"? Do you like some help? > > Given it's a build-dependency of dnsperf (and a few other packages of > mine), I'd be happy to take the package over in case you're not > interested anymore. > > Regards, > Daniel Hi, Daniel: Unfortunately I don't have much time to spend on ck these days, and I don't have any packages that need it as a build dependency. Feel free to ITA. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#985616: Document change to unbound ".d" config file fragment behavior
Package: release-notes Severity: normal Hi, During the bullseye release cycle the default /etc/unbound/unbound.conf file was changed to use the newly introduced "include-toplevel:" directive rather than the "include:" directive. This should probably be mentioned in the bullseye release notes because it will break configurations where the user added a clauseless config file fragment to /etc/unbound/unbound.conf.d/. The text from /usr/share/doc/unbound/NEWS.Debian.gz about this change is quoted below. Thanks! unbound (1.11.0-1) unstable; urgency=medium The default Debian config file shipped in the unbound package has changed from using the "include:" directive to using the "include-toplevel:" directive in order to include the config file fragments in /etc/unbound/unbound.conf.d/*.conf into the unbound configuration. The "include-toplevel:" directive has been newly introduced in unbound 1.11.0 and it requires that any included config file fragment begin its own clause (e.g., "server:"). The existing "include:" directive that was used in previous Debian releases of the unbound package only performed textual inclusion, and it was possible to construct a set of config file fragments that depended on the presence or ordering of specific config file fragments in order to parse correctly. For instance, a config file fragment could have specified an option that can only appear in the "server:" clause, and rely on a previously included config file fragment to begin that clause. This behavior is no longer allowed by the use of the "include-toplevel:" directive because it is not robust against config file fragments being added, removed, or reordered. If you are upgrading the unbound package and you have installed any config file fragments into /etc/unbound/unbound.conf.d/ you should check that each config file fragment begins its own clause (e.g., "server:") and update each config file fragment as necessary to be compatible with the behavior of the "include-toplevel:" directive. If needed, the previous behavior can be restored by changing the following line in /etc/unbound/unbound.conf: include-toplevel: "/etc/unbound/unbound.conf.d/*.conf" to its previous setting: include: "/etc/unbound/unbound.conf.d/*.conf" -- Robert Edmonds Sun, 09 Aug 2020 19:39:01 -0400 -- Robert Edmonds edmo...@debian.org
Bug#985380: unblock: dnsviz/0.9.3-1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ca...@deccio.net
Hi,
I'd like to unblock the dnsviz package. The 0.9.3 upstream release
specifically targets the release of bullseye. Per the upstream author
(X-Debbugs-Cc'd):
"FYI, it looks like I'm going to need to push one more fix, as
version 0.9.3. There was some backwards incompatibility introduced
in dnspython 2.0 that I didn't find until after 0.9.2. Since
dnspython 2.0 is what is in bullseye, it will be important to have
that fix."
Further details are available at:
* https://github.com/dnsviz/dnsviz/issues/74
*
https://github.com/dnsviz/dnsviz/commit/37864bba6a90aaa634a9f867c32ed553b2780b9c
The debdiff is attached. It is very similar to the diff between the
upstream tags v0.9.2 and v0.9.3:
* https://github.com/dnsviz/dnsviz/compare/v0.9.2...v0.9.3
The bullseye freeze policy advises that,
"In most cases, it's not appropriate to upload a new upstream
release at this point. New upstream release usually contain
unrelated changes, which might be inappropriate or make review much
more difficult. Uploading a new upstream release is only appropriate
when the resulting debdiff doesn't contain changes that wouldn't be
in the debdiff of a targeted change."
In this case, the entirety of the changes in the new upstream release
contain the targeted fix (other than trivial changes due to the upstream
version number bump).
Thanks.
unblock dnsviz/0.9.3-1
--
Robert Edmonds
edmo...@debian.org
diff -Nru dnsviz-0.9.2/PKG-INFO dnsviz-0.9.3/PKG-INFO
--- dnsviz-0.9.2/PKG-INFO 2021-02-05 23:49:51.0 -0500
+++ dnsviz-0.9.3/PKG-INFO 2021-03-11 18:03:26.0 -0500
@@ -1,6 +1,6 @@
Metadata-Version: 1.1
Name: dnsviz
-Version: 0.9.2
+Version: 0.9.3
Summary: DNS analysis and visualization tool suite
Home-page: https://github.com/dnsviz/dnsviz/
Author: Casey Deccio
diff -Nru dnsviz-0.9.2/contrib/dnsviz.spec dnsviz-0.9.3/contrib/dnsviz.spec
--- dnsviz-0.9.2/contrib/dnsviz.spec 2021-02-05 23:49:19.0 -0500
+++ dnsviz-0.9.3/contrib/dnsviz.spec 2021-03-11 18:03:07.0 -0500
@@ -1,5 +1,5 @@
Name: dnsviz
-Version:0.9.2
+Version:0.9.3
Release:1%{?dist}
Summary:Tools for analyzing and visualizing DNS and DNSSEC behavior
@@ -58,6 +58,8 @@
%{_mandir}/man1/%{name}-query.1*
%changelog
+* Thu Mar 11 2021 Casey Deccio
+ 0.9.3 release
* Fri Feb 5 2021 Casey Deccio
0.9.2 release
* Tue Jan 19 2021 Casey Deccio
diff -Nru dnsviz-0.9.2/debian/changelog dnsviz-0.9.3/debian/changelog
--- dnsviz-0.9.2/debian/changelog 2021-02-06 17:55:58.0 -0500
+++ dnsviz-0.9.3/debian/changelog 2021-03-16 16:46:46.0 -0400
@@ -1,3 +1,10 @@
+dnsviz (0.9.3-1) unstable; urgency=medium
+
+ * New upstream version 0.9.3
+- Targeted upstream fix for dnspython 2.0.0
+
+ -- Robert Edmonds Tue, 16 Mar 2021 16:46:46 -0400
+
dnsviz (0.9.2-1) unstable; urgency=medium
* New upstream version 0.9.2
diff -Nru dnsviz-0.9.2/debian/patches/debian-changes dnsviz-0.9.3/debian/patches/debian-changes
--- dnsviz-0.9.2/debian/patches/debian-changes 2021-02-06 17:55:58.0 -0500
+++ dnsviz-0.9.3/debian/patches/debian-changes 2021-03-16 16:46:46.0 -0400
@@ -8,72 +8,72 @@
For full commit history and separated commits, see the packaging Git
repository.
dnsviz-0.9.2.orig/bin/dnsviz
-+++ dnsviz-0.9.2/bin/dnsviz
+--- dnsviz-0.9.3.orig/bin/dnsviz
dnsviz-0.9.3/bin/dnsviz
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
#
# This file is a part of DNSViz, a tool suite for DNS/DNSSEC monitoring,
# analysis, and visualization.
dnsviz-0.9.2.orig/contrib/digviz
-+++ dnsviz-0.9.2/contrib/digviz
+--- dnsviz-0.9.3.orig/contrib/digviz
dnsviz-0.9.3/contrib/digviz
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
#
# This file is a part of DNSViz, a tool suite for DNS/DNSSEC monitoring,
# analysis, and visualization.
dnsviz-0.9.2.orig/contrib/dnsviz-lg.cgi
-+++ dnsviz-0.9.2/contrib/dnsviz-lg.cgi
+--- dnsviz-0.9.3.orig/contrib/dnsviz-lg.cgi
dnsviz-0.9.3/contrib/dnsviz-lg.cgi
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
#
# This file is a part of DNSViz, a tool suite for DNS/DNSSEC monitoring,
# analysis, and visualization.
dnsviz-0.9.2.orig/dnsviz/commands/graph.py
-+++ dnsviz-0.9.2/dnsviz/commands/graph.py
+--- dnsviz-0.9.3.orig/dnsviz/commands/graph.py
dnsviz-0.9.3/dnsviz/commands/graph.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
#
# This file is a part of DNSViz, a tool suite for DNS/DNSSEC monitoring,
# analysis, and visualization.
dnsviz-0.9.2.orig/dnsviz/commands/grok.py
-+++ dnsviz-0.9.2/dnsviz/commands/grok.py
+--- dnsviz-0.9.3.orig/dnsviz/commands/grok.py
dnsviz-0.9.3/dnsviz/commands/grok.py
@@ -1,4 +1,4 @@
-#
Bug#982671: Supporting unbound in stretch by upgrading to 1.9
Markus Koschany wrote: > Hello, > > Am Mittwoch, den 17.02.2021, 14:09 -0500 schrieb Robert Edmonds: > > Hi, > > > > #982671 / #982672 is incorrectly reported against the python-unbound > > package. It should instead be against the unbound binary package because > > this functionality is in the unbound daemon. > > Please feel free to reassign and/or adjust the bug report as necessary. I get the following error message from the BTS. Do I need to do "reassign 982671 unbound1.9" instead? > reassign 982671 unbound 1.9.0-2+deb10u2~deb9u1 Bug #982671 [python-unbound] python-unbound: unbound doesn't start with python module enabled Bug #982672 [python-unbound] python-unbound: unbound doesn't start with python module enabled Bug reassigned from package 'python-unbound' to 'unbound'. Bug reassigned from package 'python-unbound' to 'unbound'. No longer marked as found in versions unbound1.9/1.9.0-2+deb10u2~deb9u1. No longer marked as found in versions unbound1.9/1.9.0-2+deb10u2~deb9u1. Ignoring request to alter fixed versions of bug #982671 to the same values previously set Ignoring request to alter fixed versions of bug #982672 to the same values previously set Bug #982671 [unbound] python-unbound: unbound doesn't start with python module enabled Bug #982672 [unbound] python-unbound: unbound doesn't start with python module enabled There is no source info for the package 'unbound' at version '1.9.0-2+deb10u2~deb9u1' with architecture '' --> Unable to make a source version for version '1.9.0-2+deb10u2~deb9u1' Marked as found in versions 1.9.0-2+deb10u2~deb9u1. Marked as found in versions 1.9.0-2+deb10u2~deb9u1. > thanks > We don't intend to build the python bindings for unbound1.9. This decision was > intentional, so here are the alternatives. > > 1. Don't upgrade unbound 1.6 if you are sure, you are not affected by the >existing security vulnerabilities. > > 2. I could remove the configure option --with-pyunbound and announce this with > a new DLA, this would it make explicit that the python bindings are not > supported. > > However the end result will always be the same. You can't use the existing > python bindings with the 1.9 version. > > Regards, > > Markus OK. I understand the src:unbound1.9 package in stretch does not support the Python bindings. Does LTS intend to continue supporting the embedded Python scripting support in the src:unbound1.9 package's daemon? -- Robert Edmonds edmo...@debian.org
Bug#982671: Supporting unbound in stretch by upgrading to 1.9
Markus Koschany wrote:
> Hi,
>
> Am Mittwoch, den 17.02.2021, 12:43 -0500 schrieb Robert Edmonds:
> [...]
> > Hi,
> >
> > It looks like #982671 / #982672 was assigned by the BTS to src:unbound
> > rather than src:unbound1.9. I attempted to re-assign the bug to
> > src:unbound1.9 with notfound/found but I don't think that worked since I
> > don't see it on
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=unbound1.9.
> >
> > This bug also should have been reported against the unbound binary
> > package built by src:unbound1.9, not python-unbound, because the bug
> > appears to be about src:unbound1.9's unbound daemon failing to start. My
> > understanding is that the embedded Python scripting support in the
> > unbound daemon (which is built on stretch against Python 3, not Python 2
> > anyway) does not require the python-unbound or python3-unbound packages,
> > which are unrelated Python extension module bindings for the APIs in the
> > C libunbound library.
> >
> > Also, it looks like the upload of unbound1.9 1.9.0-2+deb10u2~deb9u1
> > dropped the python-unbound and python3-unbound binary packages. It's not
> > clear why and it would be nice if the reason were documented in
> > debian/changelog.
> >
>
> python{3}-unbound is no longer supported in Stretch. See also DSA-4694-1. [1]
> We only support the unbound daemon, unbound-host, unbound-anchor and
> libunbound8. Since unbound does not require the python bindings, both packages
> were dropped from src:unbound1.9. I suggest to mark this bug as wontfix.
>
> Regards,
>
> Markus
>
> [1] https://lists.debian.org/debian-security-announce/2020/msg00098.html
Hi,
#982671 / #982672 is incorrectly reported against the python-unbound
package. It should instead be against the unbound binary package because
this functionality is in the unbound daemon. The error message cited in
the original report is an error message generated by the unbound daemon:
[123376:0] error: module init for module python failed
Based on the original report this failure occurred after the bug
reporter upgraded to src:unbound1.9's unbound package in oldstable.
The embedded Python scripting support is in the unbound daemon and
enabled by the the '--with-pythonmodule' parameter to the unbound
configure script. It results in this dependency in the built unbound
package:
$ dpkg-deb -I unbound_1.9.0-2+deb10u2~deb9u1_amd64.deb | grep '^ Depends:'
Depends: adduser, dns-root-data, lsb-base (>= 3.0-6), openssl,
unbound-anchor, init-system-helpers (>= 1.18~), libc6 (>= 2.17),
libevent-2.0-5 (>= 2.0.10-stable), libfstrm0 (>= 0.2.0), libprotobuf-c1
vv
(>= 1.0.1), libpython3.5 (>= 3.5.0~b1), libssl1.1 (>= 1.1.0),
^^
libsystemd0
The python{3,}-unbound packages implement the Python extension module
bindings for the C libunbound library. The Python extension module is
enabled by the '--with-pyunbound' parameter to the unbound configure
script.
--
Robert Edmonds
edmo...@debian.org
Bug#979840: dns-root-data: autopkgtest regression in testing: failed to query server 127.0.0.1@53
severity 979840 minor quit Paul Gevers wrote: > Source: dns-root-data > Version: 2019052802 > X-Debbugs-CC: debian...@lists.debian.org > Severity: serious > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainer(s), > > With a not so recent change (beginning 2020) somewhere outside your > package the autopkgtest of your package started to fail. I copied some > of the output at the bottom of this report. Can you please investigate > the situation and fix it? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation > > Paul > > https://ci.debian.net/data/autopkgtest/testing/amd64/d/dns-root-data/9516338/log.gz > > autopkgtest [17:42:10]: test baseline: [--- > ;; WARNING: response timeout for 127.0.0.1@53(UDP) > ;; WARNING: response timeout for 127.0.0.1@53(UDP) > ;; WARNING: response timeout for 127.0.0.1@53(UDP) > ;; ERROR: failed to query server 127.0.0.1@53(UDP) > autopkgtest [17:42:25]: test baseline: ---] Hi, I have investigated this report. The purpose of the dns-root-data package is to ship, as static content, the list of IANA DNS root nameserver IP addresses, and the IANA DNSSEC root zone trust anchor. According to https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation: It can be appropriate to file an RC bug against the depended-on package, if the regression amounts to an RC bug in the depending package, and to keep it open while the matter is investigated. That will prevent migration of an RC regression. I have confirmed that the current version of the package (2019052802) is shipping the correct root nameserver hints and root zone trust anchor content and that no RC regression exists, so I am lowering the severity of this bug report. The problem seems to be that the test depends on the Knot Resolver's kresd daemon, whose service unit is masked and is not started after installing the knot-resolver package. I would guess something like the following would fix the regression in the test: --- dns-root-data-2019052802/debian/tests/baseline.orig 2021-02-11 22:08:17.857773156 -0500 +++ dns-root-data-2019052802/debian/tests/baseline 2021-02-11 22:13:28.483653604 -0500 @@ -2,6 +2,9 @@ set -e -kdig @127.0.0.1 -t ns . +dnssec > root-nameservers-result +kresd --noninteractive --addr=127.53.53.53@53053 & + +kdig -p 53053 @127.53.53.53 -t ns . +dnssec > root-nameservers-result cat root-nameservers-result head -n1 < root-nameservers-result | grep -q '^;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: ' +head -n2 < root-nameservers-result | tail -1 | grep -q '^;; Flags: qr rd ra ad;' -- Robert Edmonds edmo...@debian.org
Bug#962459: unbound: constantly crashing after about 3 minutes since start
Kebert Martin wrote: > Applied '0001-Apply-a-series-of-fixes-for-Unbound-1.9.0-suggested-.patch' > > Result: > Oct 28 20:24:28 debian systemd[1]: Starting Unbound DNS server... > Oct 28 20:24:28 debian package-helper[464]: /var/lib/unbound/root.key has > content > Oct 28 20:24:28 debian package-helper[464]: fail: the anchor is NOT ok and > could not be fixed > Oct 28 20:24:28 debian unbound[468]: [468:0] notice: init module 0: subnet > Oct 28 20:24:28 debian unbound[468]: [468:0] notice: init module 1: validator > Oct 28 20:24:28 debian unbound[468]: [468:0] notice: init module 2: iterator > Oct 28 20:24:28 debian systemd[1]: Started Unbound DNS server. > Oct 28 20:24:28 debian unbound[468]: [468:0] info: start of service (unbound > 1.9.0). > ... > Oct 28 20:31:31 debian kernel: unbound[470]: segfault at 1b0 ip > 7fdb28876e48 sp 7fdb26fd6cf0 error 4 in libevent-2.1.so.6.0.2 > [7fdb28857000+54000] > [...] Hi, Kebert: Thanks for checking that. Sorry it didn't work, and apologies for the delay in getting back to you. We're now looking into the possibility of updating the version of unbound in buster to a newer upstream release that most likely already includes the right combination of fixes for this issue, rather than trying to backport the right set of fixes needed to the 1.9.0 release. If you have an opportunity, could you give the candidate unbound package available here a try? https://people.debian.org/~edmonds/unbound/1.9.6-0+deb10u0/ Thanks! -- Robert Edmonds edmo...@debian.org
Bug#973052: (unbound unaccountably crashes inside libevent (Assertion nread >= 0 failed in evmap_io_del_))
Daniel Kahn Gillmor wrote: > Hi Robert-- > > thanks for the followup! > > On Wed 2020-10-28 02:56:55 -0400, Robert Edmonds wrote: > > I've never been able to reproduce this bug, but your branch looks good > > to me as far as backporting this commit to 1.9.0. It's commit > > 225534e5ab22d16ab32fa1011733f3c69c7b28ba in the upstream repo which was > > released in 1.9.1. I don't have any objection if you want to propose a > > stable update for unbound with just this fix. Personally I've been > > keeping unbound in buster-backports up to date with testing lately and I > > don't have any buster machines running the version of unbound in buster > > :-) > > Over on https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4227 > upstream suggested two different things: > > - upgrade to 1.9.2, (which incorporates this and several other bugfixes), or > > - cherry-pick a list of other commits which they think are also >relevant to this specific fix: > > 348cbab016f824a336b65d0091310fe5cd58e762 > 2b47ca080eb91e209fb86cd1dc90a6aff32e2a1f > >and four more, related to spoolbuf: > > 0b77c9d6763686264d44dfd926c8cb4f2f03a43a > 6067ce6d2b82ce2e80055e578fdfd7ba3e67c523 > af6c5dea43fc63452d49b2339e607365b6652987 > a08fe8ca609b651c8d8c8379780aad508d492421 OK, I made a patch incorporating those fixes recommended by upstream and sent them to #962459. Looks like that doesn't work at all. > I'm assuming that the release team would prefer that we go the latter > route (cherry-picked patches), but i haven't tried to get a direct > verdict from them on that. If I recall correctly, back when lenny was oldstable, a major upstream update (1.0.2 → 1.4.6) was allowed in order to correct a security problem that was infeasible to backport. I don't think we could justify pushing the latest upstream version into stable, but I'm not sure picking a random 1.9.x release is the right thing either. Upstream recommends that users run their latest release because every new release contains bug fixes and improvements, of course. So I'm fine with uploading each new upstream release to unstable and then (five days later) to buster-backports, for users that want to run the latest upstream release on buster. I don't think there's a particularly strong justification for Unbound users to run whatever random version was current ~6 months before a Debian stable release other than, well, that's what Debian stable shipped with. > I confess i don't really understand the way that unbound's buster > packaging is working -- i think it's neither git-dpm nor gbp -- so i > don't exactly know how i'd assemble an update for the next buster point > release without overhauling it. (i'd be fine with overhauling it to use > gbp (as i think the unstable version of the packaging is) as long as > you're ok with that, but i also don't know whether that would make the > changes more unpleasant for the release team. > > Any suggestions? Overhauling the packaging in the buster branch would probably make things unpleasant for stable reviewers, so I would not recommend doing that. The way the packaging works in buster is that patches to the code are directly applied to the git repository and the "single-debian-patch" option is used. Like, if you want to make a change, you just make the change, and the changes are stored in git, instead of using git to store patch files that contain the changes. Apparently this is bad because there is tooling that interacts very poorly with this style of packaging (I think it's gbp-import-orig's '--merge-mode=replace' which intentionally destroys all the changes outside the debian/ directory). I think that was the root cause of #923314. -- Robert Edmonds edmo...@debian.org
Bug#962459: unbound: constantly crashing after about 3 minutes since start
Kebert Martin wrote: > Hi, > I tried the patch "p1_and_2.diff" from #973052. > I'm not saying it was extensive test, but 7 minutes after start I got first > crash: > Oct 28 17:35:26 debian systemd[1]: Started Unbound DNS server. > Oct 28 17:35:26 debian unbound[450]: [450:0] info: start of service (unbound > 1.9.0). > ... > Oct 28 17:42:26 debian systemd[1]: unbound.service: Main process exited, code= > killed, status=11/SEGV > Oct 28 17:42:26 debian systemd[1]: unbound.service: Failed with result > 'signal'. > Oct 28 17:42:26 debian systemd[1]: unbound.service: Service RestartSec=100ms > expired, scheduling restart. > Oct 28 17:42:26 debian systemd[1]: unbound.service: Scheduled restart job, > restart counter is at 1. > ... > and 10 minutes later flood (about 30/sec) of these messages: > ... > Oct 28 17:52:49 debian unbound[1885]: [warn] Epoll ADD(1) on fd 52 failed. Old > events were 0; read change was 1 (add); w > rite change was 0 (none); close change was 0 (none): Bad file descriptor > Oct 28 17:52:49 debian unbound[1885]: [1885:3] error: read (in tcp s): Bad > file > descriptor for port > ... > > and "unbound" stopped responding to "unbound-control" (even simple > "unbound-control status" hangs). > I can't decide whether it was caused by this patch or whether it is someting > different. > Anyway I installed version 1.10 back which works. Hi, Kebert: Instead of the "p1_and_2.diff" patch, can you try the attached patch which includes additional fixes recommended by upstream? If this works for you we can propose updating the version of unbound in buster with these fixes. Thanks! -- Robert Edmonds edmo...@debian.org >From 0bf0258a54b9e7fd7d596bed3412bbf12ba532b6 Mon Sep 17 00:00:00 2001 From: Robert Edmonds Date: Wed, 28 Oct 2020 13:36:17 -0400 Subject: [PATCH] Apply a series of fixes for Unbound 1.9.0 suggested by upstream Per https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=4227#c8, upstream recommends applying the following commits against 1.9.0: 348cbab016f824a336b65d0091310fe5cd58e762 2b47ca080eb91e209fb86cd1dc90a6aff32e2a1f 0b77c9d6763686264d44dfd926c8cb4f2f03a43a 6067ce6d2b82ce2e80055e578fdfd7ba3e67c523 af6c5dea43fc63452d49b2339e607365b6652987 a08fe8ca609b651c8d8c8379780aad508d492421 However, commit 0b77c9d6763686264d44dfd926c8cb4f2f03a43a contains a complete revert of the code changes in cae8361dcd2809c8e266d259370c9ab8660c2c0e (added post-1.9.0), so I applied that patch as well in order to avoid needing to manually resolve the textual conflict when attempting to apply 0b77c9d6763686264d44dfd926c8cb4f2f03a43a to 1.9.0. Most hunks applied cleanly or with a small offset, excluding the changelog entries. The git-apply session was as follows: $ git describe debian/1.9.0-2+deb10u2 $ git apply --verbose --exclude=doc/Changelog \ /tmp/up/348cbab016f824a336b65d0091310fe5cd58e762.diff \ /tmp/up/2b47ca080eb91e209fb86cd1dc90a6aff32e2a1f.diff \ /tmp/up/cae8361dcd2809c8e266d259370c9ab8660c2c0e.diff \ /tmp/up/0b77c9d6763686264d44dfd926c8cb4f2f03a43a.diff \ /tmp/up/6067ce6d2b82ce2e80055e578fdfd7ba3e67c523.diff \ /tmp/up/af6c5dea43fc63452d49b2339e607365b6652987.diff \ /tmp/up/a08fe8ca609b651c8d8c8379780aad508d492421.diff Skipped patch 'doc/Changelog'. Checking patch util/netevent.c... Applied patch util/netevent.c cleanly. Skipped patch 'doc/Changelog'. Checking patch config.h.in... Hunk #1 succeeded at 83 (offset -3 lines). Hunk #2 succeeded at 167 (offset -3 lines). Checking patch configure... Hunk #1 succeeded at 19010 (offset -3 lines). Checking patch configure.ac... Hunk #1 succeeded at 1197 (offset -3 lines). Checking patch util/ub_event.c... Applied patch config.h.in cleanly. Applied patch configure cleanly. Applied patch configure.ac cleanly. Applied patch util/ub_event.c cleanly. Skipped patch 'doc/Changelog'. Checking patch services/listen_dnsport.c... Applied patch services/listen_dnsport.c cleanly. Skipped patch 'doc/Changelog'. Checking patch services/listen_dnsport.c... Hunk #1 succeeded at 1779 (offset -7 lines). Hunk #2 succeeded at 1857 (offset -7 lines). Applied patch services/listen_dnsport.c cleanly. Skipped patch 'doc/Changelog'. Checking patch services/listen_dnsport.c... Hunk #1 succeeded at 1746 (offset -6 lines). Checking patch services/mesh.c... Applied patch services/listen_dnsport.c cleanly. Applied patch services/mesh.c cleanly. Skipped patch 'doc/Changelog'. Checking patch daemon/worker.c... Hunk #1 succeeded at 770 (offset -2 lines). Checking patch util/netevent.c... Hunk #1 succeeded at 1551 (offset -16 lines). Hunk #2 succeeded at 1617 (offset -16 lines). Applied patch daemon/worker.c cleanly. Ap
Bug#943060: ifupdown-multi: Python2 removal in sid/bullseye
Moritz Mühlenhoff wrote: > On Wed, Oct 23, 2019 at 02:33:26AM +, mo...@debian.org wrote: > > Source: ifupdown-multi > > Version: 0.1.1 > > Severity: normal > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2removal > > > > Python2 becomes end-of-live upstream, and Debian aims to remove > > Python2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > Hi Robert, > ifupdown-multi is dead upstream (last commit seven years ago), are you > planning > to port it yourself or should it just be removed? Hi, Moritz: I still use this script and am the original author. I should have some time in the next few days to port this. Thanks for the reminder. -- Robert Edmonds edmo...@debian.org
Bug#973052: (unbound unaccountably crashes inside libevent (Assertion nread >= 0 failed in evmap_io_del_))
Daniel Kahn Gillmor wrote: > I've pushed the patch in #973052 to a new branch named bug-973052 in the > https://salsa.debian.org/dns-team/unbound repo (on top of > branches/1.9.0-2_deb10). > > Hopefully one of the other DNS folks will review it and merge it if it > looks reasonable. Not sure whether we should release a new version with > just this fix, but it might be worth proposing it. Hi, Daniel: I've never been able to reproduce this bug, but your branch looks good to me as far as backporting this commit to 1.9.0. It's commit 225534e5ab22d16ab32fa1011733f3c69c7b28ba in the upstream repo which was released in 1.9.1. I don't have any objection if you want to propose a stable update for unbound with just this fix. Personally I've been keeping unbound in buster-backports up to date with testing lately and I don't have any buster machines running the version of unbound in buster :-) -- Robert Edmonds edmo...@debian.org
Bug#971968: RM: libxs -- ROM; no reverse deps, no users, no upstream
Package: ftp.debian.org Severity: normal Hi, I'd like to request the removal of libxs from unstable. It has no reverse dependencies and a very low popcon count (<10). It was a shortlived fork of ZeroMQ that has been abandoned upstream since ~2013. It also has an FTBFS bug on a release architecture (#865178) and requires maintenance in order to avoid blocking a library transition in another package (#971957). Thanks! -- Robert Edmonds edmo...@debian.org
Bug#950754: unbound: fails to parse old config file with do-not-query-localhost
Kurt Roeckx wrote: > Hi, > > After upgrade to 1.9.6-1, unbound did no longer start. It did not > log anything about this in any log file. > > I have a config that says: > do-not-query-localhost: no > > It now returns a syntax error for that. Hi, Kurt: Thanks for your bug report. In unbound 1.9.6-1 / 1.9.6-2, the config file fragment /etc/unbound/unbound.conf.d/qname-minimisation.conf was removed, because its contents were made redundant due to upstream changing the default value for the qname-minimisation setting. Its contents previously were: server: # Send minimum amount of information to upstream servers to enhance # privacy. Only sends minimum required labels of the QNAME and sets # QTYPE to NS when possible. # See RFC 7816 "DNS Query Name Minimisation to Improve Privacy" for # details. qname-minimisation: yes Because of the textual inclusion behavior of the "include:" directive used in /etc/unbound/unbound.conf, it looks like your "do-not-query-localhost: no" setting was relying on this fragment to begin the "server:" clause. You should update your config file fragment (if you haven't already) to: server: do-not-query-localhost: no The textual inclusion behavior of "include:" makes it fragile against these kinds of changes, so I discussed the issue with upstream (https://github.com/NLnetLabs/unbound/issues/161) and they ended up implementing a new "include-toplevel:" directive that requires each config file fragment to begin a clause. Going forward, this should make it more robust for the Debian unbound package to add or remove config file fragments in /etc/unbound/unbound.conf.d/ without affecting users' configurations if they've installed their own config file fragments, but it does require users to update their config file fragments to declare a clause if they don't already. The unbound 1.11.0-1 package will switch /etc/unbound/unbound.conf to using the "include-toplevel:" directive and he following announcement will appear in the /usr/share/doc/unbound/NEWS.Debian.gz file: unbound (1.11.0-1) unstable; urgency=high The default Debian config file shipped in the unbound package has changed from using the "include:" directive to using the "include-toplevel:" directive in order to include the config file fragments in /etc/unbound/unbound.conf.d/*.conf into the unbound configuration. The "include-toplevel:" directive has been newly introduced in unbound 1.11.0 and it requires that any included config file fragment begin its own clause (e.g., "server:"). The existing "include:" directive that was used in previous Debian releases of the unbound package only performed textual inclusion, and it was possible to construct a set of config file fragments that depended on the presence or ordering of specific config file fragments in order to parse correctly. For instance, a config file fragment could have specified an option that can only appear in the "server:" clause, and rely on a previously included config file fragment to begin that clause. This behavior is no longer allowed by the use of the "include-toplevel:" directive because it is not robust against config file fragments being added, removed, or reordered. If you are upgrading the unbound package and you have installed any config file fragments into /etc/unbound/unbound.conf.d/ you should check that each config file fragment begins its own clause (e.g., "server:") and update each config file fragment as necessary to be compatible with the behavior of the "include-toplevel:" directive. If needed, the previous behavior can be restored by changing the following line in /etc/unbound/unbound.conf: include-toplevel: "/etc/unbound/unbound.conf.d/*.conf" to its previous setting: include: "/etc/unbound/unbound.conf.d/*.conf" -- Robert Edmonds Sun, 09 Aug 2020 19:39:01 -0400 -- Robert Edmonds edmo...@debian.org
Bug#936251: bup: Python2 removal in sid/bullseye
Sandro Tosi wrote: > User: debian-pyt...@lists.debian.org > Usertags: -py2keep > > the argument to set pykeep was that the app is popular enough; > according to https://qa.debian.org/popcon.php?package=bup it has ~230 > installations, declining; removing the tag > > On Fri, 30 Aug 2019 07:12:26 + Matthias Klose wrote: > > Package: src:bup > > Version: 0.29.3-2 > > Severity: normal > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2removal > > Hey Robert, i looked at recent changes to the upstream repo, in > particular > https://github.com/bup/bup/commit/64e04395957f148bd41d3506bc603a9b1122c7df > where they enabled tests on py3 too, as a good indication the code is > progressing in the right direction: do you think it's already at a > stage where a git snapshot could be uploaded to unstable? bup has an extensive and aggressive test suite that sometimes experiences arch-specific test failures. For a new upstream release (including a new git snapshot) I would like to have the first upload(s) go to experimental to verify the test suite across all architectures before uploading to unstable. Since it is a backup tool, I'd also like to avoid uploading git snapshots to unstable. -- Robert Edmonds edmo...@debian.org
Bug#937483: pymtbl: Python2 removal in sid/bullseye
Moritz Mühlenhoff wrote: > On Fri, Aug 30, 2019 at 07:34:31AM +, Matthias Klose wrote: > > Package: src:pymtbl > > Version: 0.4.0-1 > > Severity: normal > > Tags: sid bullseye > > User: debian-pyt...@lists.debian.org > > Usertags: py2removal > > > > Python2 becomes end-of-live upstream, and Debian aims to remove > > Python2 from the distribution, as discussed in > > https://lists.debian.org/debian-python/2019/07/msg00080.html > > There's no movement on https://github.com/farsightsec/pymtbl/issues/4, the > last > commit is from 2017 and there are no reverse deps, let's remove? > > Cheers, > Moritz Sounds good to me. -- Robert Edmonds edmo...@debian.org
Bug#961447: bup: 0.30.1 released, fixing notable bugs
Rob Browning wrote: > Just released 0.30.1, including some notable bug fixes. I'd recommend > replacing the version in sid if feasible: > > https://github.com/bup/bup/blob/0.30.x/note/0.30.1-from-0.30.md > > Perhaps worth mentioning that 0.30.* still doesn't support python 3. > We're finishing up python 3 support for the next non-Z version (likely > 0.31, hopefully "soon"). Hi, Rob: One of our build dependencies python-pylibacl has already removed its python2 module (#938073). It looks like bup can function without pylibacl. Is it safe to ship a bup 0.30.1 package without pylibacl support? -- Robert Edmonds edmo...@debian.org
Bug#921538: Fails to start since upgrade to 1.9.0-1
Simon Deziel wrote: > On 2019-02-06 11:12 a.m., Ryan Kavanagh wrote: > > Since the upgrade to 1.9.0-1, unbound fails to start. Purging the > > package and reinstalling does not fix the issue. The errors seem to be > > due to being unable to read various configuration files. > > > > Feb 06 11:01:12 zeta unbound[28647]: [28647:0] error: unable to open > > /var/lib/unbound/root.key for reading: No such file or directory > > Feb 06 11:01:12 zeta package-helper[28648]: [1549468872] > > unbound-checkconf[28651:0] error: Could not open > > /etc/unbound//etc/unbound/unbound.conf: No such file or director > > It seems like chroot'ing to /etc/unbound is attempted. To workaround you > can try this: > > cat << EOF > /etc/unbound/unbound.conf.d/chroot.conf > server: > chroot: "" > EOF > service unbound restart Automatic chroot'ing has been disabled in the unbound Debian package for a while, by this commit: https://salsa.debian.org/dns-team/unbound/commit/66bb04a0869e315f76c4b4efe8632914d860686c It looks like that change was lost in the 1.9.0-1 upload, compare these two revisions: https://salsa.debian.org/dns-team/unbound/blob/debian/1.8.1-1/util/config_file.c#L163-165 https://salsa.debian.org/dns-team/unbound/blob/debian/1.9.0-1/util/config_file.c#L169-171 Probably it's better to use the --with-chroot-dir= argument to configure rather than directly patching the source to change the default. -- Robert Edmonds edmo...@debian.org
Bug#916754: [20181218] debian.gtisc.gatech.edu: broken DNS
Peter Palfrader wrote: > Hi! > > it seems we cannot resolve debian.gtisc.gatech.edu currently. > https://mirror-master.debian.org/status/mirror-info/debian.gtisc.gatech.edu.html > > The problem appears to be a broken DNS configuration that puts all of > the nameservers for gtisc.gatech.edu in the same AS. That is not the root cause. Those nameservers are on the same edge switch as the mirror. It looks like there is a multi-day power outage due to a planned switchgear replacement. https://support.cc.gatech.edu/alerts/ccb-power-outage-dec-18-21-2018 I would try to CNAME debian.gtisc.gatech.edu elsewhere but I'm afraid the only online secondary nameserver is configured to AXFR the zone from servers that are ... powered off. -- Robert Edmonds edmo...@debian.org
Bug#914165: virtualbox: Please ship rdesktop-vrdp utility
Package: virtualbox Version: 5.2.22-dfsg-1 Severity: wishlist Hi, VirtualBox supports remote display of VMs using the (V)RDP protocol, and in particular the VRDP protocol has extensions like remote USB that don't appear to be available in RDP clients other than the 'rdesktop-vrdp' one that VirtualBox ships. If the Debian virtualbox package could ship the rdesktop-vrdp utility it would be appreciated. The source package is already building it. The patch below will ship it in the virtualbox binary package. Thanks! diff --git a/debian/virtualbox.install b/debian/virtualbox.install index fc8a83be1..29d9df584 100644 --- a/debian/virtualbox.install +++ b/debian/virtualbox.install @@ -37,3 +37,6 @@ out/bin/sdk/bindings/xpcom/python /usr/lib/virtualbox/sdk/bindings/xpcom out/bin/VBoxCreateUSBNode.sh /lib/udev out/bin/VBoxSysInfo.sh /usr/share/virtualbox debian/vboxweb.service /lib/systemd/system/ + +out/bin/rdesktop-vrdp /usr/bin +out/bin/rdesktop-vrdp-keymaps /usr/share/virtualbox -- Robert Edmonds edmo...@debian.org
Bug#891801: stretch-pu: package unbound/1.6.0-3+deb9u2
Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On 2018-07-14 07:46, Salvatore Bonaccorso wrote: > > Control: tags -1 - moreinfo > > > > On Fri, Mar 02, 2018 at 05:49:52PM +, Adam D. Barratt wrote: > > > Control: tags -1 + moreinfo > > > > > > On Wed, 2018-02-28 at 17:47 -0500, Robert Edmonds wrote: > > > > I would like to fix a DNSSEC validation bug (CVE-2017-15105) in the > > > > unbound package shipped in stretch. After discussion with the > > > > security > > > > team, this bug was deemed minor enough that the fix could be shipped > > > > in > > > > a point release: > > > > > > > > https://security-tracker.debian.org/tracker/CVE-2017-15105 > > > > > > > > > > According to the above Security Tracker entry, this issue has not yet > > > been fixed in unstable. Assuming that's correct, I'm afraid that's a > > > blocker for looking at an update in stable. > > > > This happened later on with the 1.7.1-1 upload. > > Thanks, Salvatore. Robert, please feel free to upload. > > Regards, > > Adam Uploaded. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#901015: transition: protobuf
Hi, I've released a new upstream version of protobuf-c that fixes the FTBFS issue with protobuf 3.6, which fixes #900621. I will upload it to unstable shortly. László Böszörményi (GCS) wrote: > On Thu, Jul 12, 2018 at 10:14 AM Pirate Praveen > wrote: > > On Fri, 6 Jul 2018 10:55:03 +0200 > > =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= > > wrote: > > > The most problematic point is the protobuf-c dependency package. It > > > was developed (and packaged) by one of us (an other DD), Robert S. > > > Edmonds. It is the most complete C language implementation of Protocol > > > Buffers. While it has a newer upstream release in Git than the > > > packaged version, it's still not compatible with protobuf 3.6.0.1 > > > which is in experimental. > [...] > > What do you think about providing protobuf3.0 in parallel to updating > > protobuf to 3.6? That way we can move ahead with gitlab and provide more > > time for either updating protobuf-c or porting packages to protobluff. > > We can drop protobuf3.0 when protobuf-c issue is resolved. > Actually I would like to investigate every possibility. > 1) Check the list of protobuf-c main contributors[1] if any of them > can / want to continue its development. > 2) Try to update protobuf-c for version 3.6 of protobuf, but I can't > be its upstream developer on the long run. > 3) Patch protobuf-c to use the implementation of scoped_array in Boost. > 4) At least check the required porting needs of dependencies to > protobluff. Ask their maintainers if they want / can do the porting. > Maybe they know other alternatives. > > If these fail and RMs ACK to carry two versions of protobuf then of > course, do it. Emilio? > How quick do you need to solve this GitLab update? I guess, quick. -- Robert Edmonds edmo...@debian.org
Bug#891801: stretch-pu: package unbound/1.6.0-3+deb9u2
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I would like to fix a DNSSEC validation bug (CVE-2017-15105) in the
unbound package shipped in stretch. After discussion with the security
team, this bug was deemed minor enough that the fix could be shipped in
a point release:
https://security-tracker.debian.org/tracker/CVE-2017-15105
Please see attached a debdiff for unbound 1.6.0-3+deb9u2 containing the
backported fix from upstream version 1.6.8. I'd like to have this
considered for the upcoming stable point release.
Details on the bug and its impact are available in this upstream
advisory:
https://unbound.net/downloads/CVE-2017-15105.txt
I have cherry-picked two commits (svn r4441, r4528) from the upstream
repository containing the fix and a test case. Those upstream commits
are available here:
https://github.com/NLnetLabs/unbound/commit/2a6250e3fb3ccd6e9a0a16b6908c5cfb76d8d6f3
https://github.com/NLnetLabs/unbound/commit/eff62cecac1388214032906eb6944ceb9c0e6d41
(There was a minor conflict when merging the cherry-picked commit r4441
due to the renaming of some internal types in svn r3989.)
A very similar fix has already been shipped for wheezy-lts in
1.4.17-3+deb7u3.
Thanks!
--
Robert Edmonds
edmo...@debian.org
diff -Nru unbound-1.6.0/debian/changelog unbound-1.6.0/debian/changelog
--- unbound-1.6.0/debian/changelog 2017-08-27 00:43:42.0 -0400
+++ unbound-1.6.0/debian/changelog 2018-02-28 17:00:51.0 -0500
@@ -1,3 +1,12 @@
+unbound (1.6.0-3+deb9u2) stretch; urgency=high
+
+ * Cherry-pick upstream commit svn r4441, "patch for CVE-2017-15105:
+vulnerability in the processing of wildcard synthesized NSEC records."
+ * Cherry-pick upstream commit svn r4528, "Added tests with wildcard
+expanded NSEC records (CVE-2017-15105 test)".
+
+ -- Robert Edmonds <edmo...@debian.org> Wed, 28 Feb 2018 17:00:51 -0500
+
unbound (1.6.0-3+deb9u1) stretch; urgency=high
* Cherry-pick upstream commit svn r4301, "Fix install of trust anchor
diff -Nru unbound-1.6.0/debian/patches/debian-changes
unbound-1.6.0/debian/patches/debian-changes
--- unbound-1.6.0/debian/patches/debian-changes 2017-08-27 00:43:42.0
-0400
+++ unbound-1.6.0/debian/patches/debian-changes 2018-02-28 17:00:51.0
-0500
@@ -5,14 +5,12 @@
information below has been extracted from the changelog. Adjust it or drop
it.
.
- unbound (1.6.0-3+deb9u1) stretch; urgency=high
+ unbound (1.6.0-3+deb9u2) stretch; urgency=high
.
- * Cherry-pick upstream commit svn r4301, "Fix install of trust anchor
- when two anchors are present, makes both valid. Checks hash of DS but
- not signature of new key. This fixes installs between sep11 and oct11
- 2017."
- * debian/control: unbound: Add versioned dependency on dns-root-data (>=
- 2017072601~) for KSK-2017 in RFC 5011 state VALID.
+ * Cherry-pick upstream commit svn r4441, "patch for CVE-2017-15105:
+ vulnerability in the processing of wildcard synthesized NSEC records."
+ * Cherry-pick upstream commit svn r4528, "Added tests with wildcard
+ expanded NSEC records (CVE-2017-15105 test)".
Author: Robert Edmonds <edmo...@debian.org>
---
@@ -26,7 +24,7 @@
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: <no|not-needed|url proving that it has been forwarded>
Reviewed-By:
-Last-Update: 2017-08-27
+Last-Update: 2018-02-28
--- unbound-1.6.0.orig/acx_python.m4
+++ unbound-1.6.0/acx_python.m4
@@ -79,6 +77,165 @@
+echo "Setup success. Certificates created."
exit 0
+--- unbound-1.6.0.orig/testcode/unitverify.c
unbound-1.6.0/testcode/unitverify.c
+@@ -186,7 +186,9 @@ verifytest_rrset(struct module_env* env,
+ ntohs(rrset->rk.rrset_class));
+ }
+ setup_sigalg(dnskey, sigalg); /* check all algorithms in the dnskey */
+- sec = dnskeyset_verify_rrset(env, ve, rrset, dnskey, sigalg, );
++ /* ok to give null as qstate here, won't be used for answer section. */
++ sec = dnskeyset_verify_rrset(env, ve, rrset, dnskey, sigalg, ,
++ LDNS_SECTION_ANSWER, NULL);
+ if(vsig) {
+ printf("verify outcome is: %s %s\n", sec_status_to_string(sec),
+ reason?reason:"");
+--- /dev/null
unbound-1.6.0/testdata/val_nodata_failwc.rpl
+@@ -0,0 +1,71 @@
++; config options
++; The island of trust is at nsecwc.nlnetlabs.nl
++server:
++ trust-anchor: "nsecwc.nlnetlabs.nl. 10024 IN DS 565 8 2
0C15C04C022700C8713028F6F64CF2343DE627B8F83CDA1C421C65DB 52908A2E"
++ val-override-date: "20181202115531"
++ target-fetch-policy: "0 0 0 0 0"
++ fake-sha1: yes
++ trust-anchor-signaling: no
++stub-zone:
++ name: "nsecwc.nlnetlabs.nl"
++ stub-addr: "185.49.140.60"
++
Bug#891705: [Pkg-dns-devel] Bug#891705: Bug#891705: Apparmor policy prevents chown/chmod of the Unix control socket
Simon Deziel wrote: > On 2018-02-28 11:48 AM, Simon Deziel wrote: > > Yes, I'm working on a pull request/merge proposal via salsa.debian.org. > > I'll be proposing a fix for all 3 Apparmor related bugs with the Unbound > > profile. Shouldn't be too long. Thanks! > > I couldn't find a way to do the merge proposal through the WebUI of > salsa (maybe because I'm a -guest). Please see the refreshed Apparmor > profile at [1]. Feedback is welcome of course! > > Regards, > Simon > > 1: https://salsa.debian.org/sdeziel-guest/unbound/tree/apparmor-refresh Hi, Simon: I get a 404 on that URL, and your repository doesn't show up under: https://salsa.debian.org/users/sdeziel-guest/projects Maybe your GitLab visibility settings are misconfigured. Can you just email the patches to the bug report? -- Robert Edmonds edmo...@debian.org
Bug#891705: [Pkg-dns-devel] Bug#891705: Apparmor policy prevents chown/chmod of the Unix control socket
Simon Deziel wrote: > Without the fix, ls -l returns this: Hi, Simon: Did you mean to include the fix in your bug report? -- Robert Edmonds edmo...@debian.org
Bug#882731: [Pkg-dns-devel] Bug#882731: apparmor policy only accepts root.key in /var/lib/unbound
Simon Deziel wrote: > On 2017-11-27 09:22 AM, Peter Palfrader wrote: > > On Mon, 27 Nov 2017, Simon Deziel wrote: > > > >> On 2017-11-26 03:31 AM, Peter Palfrader wrote: > >>> The apparmor policy for unbound allows access to > >>> /var/lib/unbound/root.key*, but it does not allow access to any > >>> other dynamically updated key the admin might have put there, > >>> such as debian.org.key on DSA infrastructure. > >>> > >>> Please allow access to all key files. > >> > >> Please see the attached patch. > > > >># chrooted paths > >>/var/lib/unbound/** r, > >> + owner /var/lib/unbound/*.key* rw, > >>owner /var/lib/unbound/**/*.key* rw, > > > > This would allow /var/lib/unbound/root.key "twice", once via root.key, > > once via *.key. > > Indeed, this patch should be better, thanks Peter. Hi, I'm a little bit confused here. The unbound daemon runs as user 'unbound', thus it should have read-write permission to the directory /var/lib/unbound/, because that's what the permission on the directory is. Is the apparmor policy intentionally overriding this? There's no requirement that an auto-trust-anchor-file be configured with a filename that ends in ".key". Does the apparmor policy break unbound if a sysadmin doesn't follow this convention? -- Robert Edmonds edmo...@debian.org
Bug#886662: wireguard-dkms should depend on libelf-dev
Daniel Kahn Gillmor wrote: > make: Entering directory '/usr/src/linux-headers-4.14.0-3-amd64' > /usr/src/linux-headers-4.14.0-3-common/Makefile:947: *** "Cannot generate ORC > metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel > or elfutils-libelf-devel". Stop. > Makefile:146: recipe for target 'sub-make' failed > make[1]: *** [sub-make] Error 2 > Makefile:8: recipe for target 'all' failed > make: *** [all] Error 2 > make: Leaving directory '/usr/src/linux-headers-4.14.0-3-amd64' > 0 root@sid:~# > > I'll fix this shortly. Hi, Daniel: You may want to hold off on fixing this in wireguard. It looks like this is a regression in src:linux (#886474). Given this failure is coming from the kernel build system apparently before the module itself even starts building, it would seem to affect all out-of-tree kernel module packages. -- Robert Edmonds edmo...@debian.org
Bug#877683: [Pkg-dns-devel] Bug#877683: jessie version of dns-root-data lacks new ksk in root.ds
Sergio Gelato wrote: > Package: dns-root-data > Version: 2017072601~deb8u1 > Severity: serious > > The version of this package that is currently in jessie-updates still only > lists the old key 19036 in /usr/share/dns/root.ds. Confirmed, I see the two keys in /usr/share/dns/root.key but not in root.ds. > If I understood correctly, > starting a week from now the root zone will only be signed with the new key > 20326. The root KSK rollover was postponed: https://www.icann.org/news/announcement-2017-09-27-en The root zone is currently being signed with the same KSK it always has been signed with. The roll might be re-scheduled and performed in the first quarter of 2018, but there is currently no definite date for the rollover. -- Robert Edmonds edmo...@debian.org
Bug#873371: stretch-pu: package unbound/1.6.0-3+deb9u1
Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Sun, 2017-08-27 at 09:19 +0100, Adam D. Barratt wrote: > > Control: block -1 by 873054 > > > > On Sun, 2017-08-27 at 01:25 -0400, Robert Edmonds wrote: > > > There is a bug in the unbound package shipped in stretch (1.6.0-3) > > > that > > > will cause DNS resolution to fail on systems that install the > > > unbound > > > package between September 11 and October 11, 2017. The upstream > > > developers have released 1.6.5 with a fix for this problem: > [...] > > > Additionally, since new installs of the unbound package initialize > > > the > > > autotrust anchor file for the DNS root (/var/lib/unbound/root.key) > > > from > > > a copy shipped in the dns-root-data package > > > (/usr/share/dns/root.key), > > > the dns-root-data package in stretch needs to be updated to > > > transition > > > the root zone trust anchor KSK-2017 to the RFC 5011 "VALID" state. > > > (The > > > stretch-pu request for the dns-root-data package is #873054.) > > > Accordingly, the proposed unbound 1.6.0-3+deb9u1 implements a > > > versioned > > > dependency on the dns-root-data package that would be shipped in > > > #873054. > > > > That means that we'd also need to release dns-root-data via -updates, > > otherwise most users won't be able to install the fixed unbound. It > > also imposes an ordering on the p-u requests, so adding a blocking > > relationship to indicate that. > > That happened now, please feel free to upload. Uploaded. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#849308: wireguard: Wireguard should not transition to stable yet
Daniel Kahn Gillmor wrote: > Now, of course we could let it drop into testing for the moment by > reducing the severity of this bug, and then cranking the severity back > up before the release, but that feels a little bit like cheating, no? > > All that said, i do see the appeal of having wider distribution, i'm > just not sure how to do that within the structure of the debian APT > archive. > > Any suggestions? Debian users have a powerful package manager at their disposal that lets them run testing but cherry-pick packages from unstable, e.g. see "Tracking Testing or Unstable" in the apt_preferences(5) manpage. That seems like the appropriate solution if wireguard doesn't have a stable wire protocol yet. So far I've even had success using the wireguard packages from unstable on stretch, just by pinning unstable. -- Robert Edmonds edmo...@debian.org
Bug#873054: stretch-pu: package dns-root-data/2017072601~deb9u1
Robert Edmonds wrote: > Adam D. Barratt wrote: > > Control: tags -1 +confirmed -moreinfo > > > > On Thu, 2017-08-24 at 08:55 +0200, Ondřej Surý wrote: > > > I forgot to attach the debdiff and rest. So here it is. > > > > Please go ahead. > > Hi, > > Given that September 11 is coming up in a few days and this package is > needed for #873371, I've gone ahead and uploaded > dns-root-data/2017072601~deb9u1 on behalf of the pkg-dns team. > > Thanks! Ah, OK, looks like it was already uploaded according to https://release.debian.org/proposed-updates/stable.html. Sorry for the noise! -- Robert Edmonds edmo...@debian.org
Bug#873054: stretch-pu: package dns-root-data/2017072601~deb9u1
Adam D. Barratt wrote: > Control: tags -1 +confirmed -moreinfo > > On Thu, 2017-08-24 at 08:55 +0200, Ondřej Surý wrote: > > I forgot to attach the debdiff and rest. So here it is. > > Please go ahead. Hi, Given that September 11 is coming up in a few days and this package is needed for #873371, I've gone ahead and uploaded dns-root-data/2017072601~deb9u1 on behalf of the pkg-dns team. Thanks! -- Robert Edmonds edmo...@debian.org signature.asc Description: PGP signature
Bug#873466: jessie-pu: package unbound/1.4.22-3+deb8u3
Adam D. Barratt wrote: > On Mon, 2017-08-28 at 00:38 -0400, Robert Edmonds wrote: > > I'd like to update jessie's unbound with a fix for the same RFC 5011 > > issue described in #873371 for stretch, fast-tracked via the *-updates > > mechanism due to the time component of the bug. Please see attached a > > debdiff for unbound 1.4.22-3+deb8u3. > > > > The fix for jessie requires an additional patch adding the root zone > > trust anchor KSK-2017 to the unbound-anchor utility. This change is > > nearly identical to a freeze exemption approved for stretch, #855635. > > Please go ahead. Uploaded. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#873466: jessie-pu: package unbound/1.4.22-3+deb8u3
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu
Hi,
I'd like to update jessie's unbound with a fix for the same RFC 5011
issue described in #873371 for stretch, fast-tracked via the *-updates
mechanism due to the time component of the bug. Please see attached a
debdiff for unbound 1.4.22-3+deb8u3.
The fix for jessie requires an additional patch adding the root zone
trust anchor KSK-2017 to the unbound-anchor utility. This change is
nearly identical to a freeze exemption approved for stretch, #855635.
Thanks!
--
Robert Edmonds
edmo...@debian.org
diff -Nru unbound-1.4.22/debian/changelog unbound-1.4.22/debian/changelog
--- unbound-1.4.22/debian/changelog 2016-07-04 15:58:35.0 -0400
+++ unbound-1.4.22/debian/changelog 2017-08-28 00:17:29.0 -0400
@@ -1,3 +1,14 @@
+unbound (1.4.22-3+deb8u3) jessie; urgency=high
+
+ * Cherry-pick upstream commit svn r4301, "Fix install of trust anchor
+when two anchors are present, makes both valid. Checks hash of DS but
+not signature of new key. This fixes installs between sep11 and oct11
+2017."
+ * Cherry-pick upstream commit svn r4000, "Include root trust anchor id
+20326 in unbound-anchor".
+
+ -- Robert Edmonds <edmo...@debian.org> Mon, 28 Aug 2017 00:17:29 -0400
+
unbound (1.4.22-3+deb8u2) jessie; urgency=medium
* debian/unbound.init: Add "pidfile" magic comment (Closes: #807132)
diff -Nru unbound-1.4.22/debian/patches/debian-changes
unbound-1.4.22/debian/patches/debian-changes
--- unbound-1.4.22/debian/patches/debian-changes2016-07-04
16:06:41.0 -0400
+++ unbound-1.4.22/debian/patches/debian-changes2017-08-28
00:18:52.0 -0400
@@ -5,13 +5,15 @@
information below has been extracted from the changelog. Adjust it or drop
it.
.
- unbound (1.4.22-3+deb8u2) jessie; urgency=medium
+ unbound (1.4.22-3+deb8u3) jessie; urgency=high
.
- * debian/unbound.init: Add "pidfile" magic comment (Closes: #807132)
- * debian/unbound.init: Call start-stop-daemon with --retry for 'stop'
- action (patch from Julien Cristau)
+ * Cherry-pick upstream commit svn r4301, "Fix install of trust anchor
+ when two anchors are present, makes both valid. Checks hash of DS but
+ not signature of new key. This fixes installs between sep11 and oct11
+ 2017."
+ * Cherry-pick upstream commit svn r4000, "Include root trust anchor id
+ 20326 in unbound-anchor".
Author: Robert Edmonds <edmo...@debian.org>
-Bug-Debian: https://bugs.debian.org/807132
---
The information above should follow the Patch Tagging Guidelines, please
@@ -24,7 +26,7 @@
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: <no|not-needed|url proving that it has been forwarded>
Reviewed-By:
-Last-Update: 2016-07-04
+Last-Update: 2017-08-28
--- unbound-1.4.22.orig/acx_python.m4
+++ unbound-1.4.22/acx_python.m4
@@ -229,6 +231,20 @@
/**
* The query must store NS records from referrals as parentside RRs
+--- unbound-1.4.22.orig/smallapp/unbound-anchor.c
unbound-1.4.22/smallapp/unbound-anchor.c
+@@ -239,7 +239,10 @@ static const char*
+ get_builtin_ds(void)
+ {
+ return
+-". IN DS 19036 8 2
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5\n";
++/* anchor 19036 is from 2010 */
++/* anchor 20326 is from 2017 */
++". IN DS 19036 8 2
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5\n"
++". IN DS 20326 8 2
E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D\n";
+ }
+
+ /** print hex data */
--- unbound-1.4.22.orig/smallapp/unbound-control-setup.sh
+++ unbound-1.4.22/smallapp/unbound-control-setup.sh
@@ -157,6 +157,6 @@ chmod o-rw $SVR_BASE.pem $SVR_BASE.key $
@@ -259,3 +275,25 @@
cfg->control_ifs = NULL;
cfg->control_port = UNBOUND_CONTROL_PORT;
cfg->minimal_responses = 0;
+--- unbound-1.4.22.orig/validator/autotrust.c
unbound-1.4.22/validator/autotrust.c
+@@ -1557,6 +1557,11 @@ key_matches_a_ds(struct module_env* env,
+ verbose(VERB_ALGO, "DS match attempt failed");
+ continue;
+ }
++ /* match of hash is sufficient for bootstrap of trust point */
++ (void)reason;
++ (void)ve;
++ return 1;
++ /* no need to check RRSIG, DS hash already matched with source
+ if(dnskey_verify_rrset(env, ve, dnskey_rrset,
+ dnskey_rrset, key_idx, ) == sec_status_secure) {
+ return 1;
+@@ -1564,6 +1569,7 @@ key_matches_a_ds(struct module_env* env,
+ verbose(VERB_ALGO, "DS match failed because the key "
+ "does not verify the keyset: %s", reason);
+ }
++ */
+ }
+ return 0;
+ }
signature.asc
Description: PGP signature
Bug#873371: stretch-pu: package unbound/1.6.0-3+deb9u1
Adam D. Barratt wrote: > I'm assuming that this also affects the unbound package shipping in > jessie currently? Are you planning on fixing the issue there as well? Yes, will open a jessie-pu bug shortly. The fix there is a bit simpler since the dns-root-data method of initializing the root trust anchor was introduced after jessie. -- Robert Edmonds edmo...@debian.org
Bug#873371: stretch-pu: package unbound/1.6.0-3+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Hi,
There is a bug in the unbound package shipped in stretch (1.6.0-3) that
will cause DNS resolution to fail on systems that install the unbound
package between September 11 and October 11, 2017. The upstream
developers have released 1.6.5 with a fix for this problem:
https://unbound.nlnetlabs.nl/pipermail/unbound-users/2017-August/004883.html
https://unbound.nlnetlabs.nl/pipermail/unbound-users/2017-August/004884.html
After discussing this issue with the security team, it was suggested
that a fix be released via a stable point release, as well as being
fast-tracked via the *-updates mechanism, due to the time component of
the bug. Please see attached a debdiff for unbound 1.6.0-3+deb9u1
containing the backported fix from upstream version 1.6.5.
Additionally, since new installs of the unbound package initialize the
autotrust anchor file for the DNS root (/var/lib/unbound/root.key) from
a copy shipped in the dns-root-data package (/usr/share/dns/root.key),
the dns-root-data package in stretch needs to be updated to transition
the root zone trust anchor KSK-2017 to the RFC 5011 "VALID" state. (The
stretch-pu request for the dns-root-data package is #873054.)
Accordingly, the proposed unbound 1.6.0-3+deb9u1 implements a versioned
dependency on the dns-root-data package that would be shipped in
#873054.
Thanks!
--
Robert Edmonds
edmo...@debian.org
diff -Nru unbound-1.6.0/debian/changelog unbound-1.6.0/debian/changelog
--- unbound-1.6.0/debian/changelog 2017-02-19 20:04:34.0 -0500
+++ unbound-1.6.0/debian/changelog 2017-08-27 00:43:42.0 -0400
@@ -1,3 +1,14 @@
+unbound (1.6.0-3+deb9u1) stretch; urgency=high
+
+ * Cherry-pick upstream commit svn r4301, "Fix install of trust anchor
+when two anchors are present, makes both valid. Checks hash of DS but
+not signature of new key. This fixes installs between sep11 and oct11
+2017."
+ * debian/control: unbound: Add versioned dependency on dns-root-data (>=
+2017072601~) for KSK-2017 in RFC 5011 state VALID.
+
+ -- Robert Edmonds <edmo...@debian.org> Sun, 27 Aug 2017 00:43:42 -0400
+
unbound (1.6.0-3) unstable; urgency=medium
* Cherry-pick upstream commit svn r4000, "Include root trust anchor id
diff -Nru unbound-1.6.0/debian/control unbound-1.6.0/debian/control
--- unbound-1.6.0/debian/control2017-02-19 20:04:34.0 -0500
+++ unbound-1.6.0/debian/control2017-08-27 00:43:42.0 -0400
@@ -96,7 +96,7 @@
Architecture: any
Depends:
adduser,
- dns-root-data,
+ dns-root-data (>= 2017072601~),
openssl,
unbound-anchor,
${misc:Depends},
diff -Nru unbound-1.6.0/debian/patches/debian-changes
unbound-1.6.0/debian/patches/debian-changes
--- unbound-1.6.0/debian/patches/debian-changes 2017-02-19 20:04:34.0
-0500
+++ unbound-1.6.0/debian/patches/debian-changes 2017-08-27 00:43:42.0
-0400
@@ -5,12 +5,15 @@
information below has been extracted from the changelog. Adjust it or drop
it.
.
- unbound (1.6.0-3) unstable; urgency=medium
+ unbound (1.6.0-3+deb9u1) stretch; urgency=high
.
- * Cherry-pick upstream commit svn r4000, "Include root trust anchor id
- 20326 in unbound-anchor". (Closes: #855484)
+ * Cherry-pick upstream commit svn r4301, "Fix install of trust anchor
+ when two anchors are present, makes both valid. Checks hash of DS but
+ not signature of new key. This fixes installs between sep11 and oct11
+ 2017."
+ * debian/control: unbound: Add versioned dependency on dns-root-data (>=
+ 2017072601~) for KSK-2017 in RFC 5011 state VALID.
Author: Robert Edmonds <edmo...@debian.org>
-Bug-Debian: https://bugs.debian.org/855484
---
The information above should follow the Patch Tagging Guidelines, please
@@ -23,7 +26,7 @@
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: <no|not-needed|url proving that it has been forwarded>
Reviewed-By:
-Last-Update: 2017-02-20
+Last-Update: 2017-08-27
--- unbound-1.6.0.orig/acx_python.m4
+++ unbound-1.6.0/acx_python.m4
@@ -118,3 +121,25 @@
free($2);
}
;
+--- unbound-1.6.0.orig/validator/autotrust.c
unbound-1.6.0/validator/autotrust.c
+@@ -1571,6 +1571,11 @@ key_matches_a_ds(struct module_env* env,
+ verbose(VERB_ALGO, "DS match attempt failed");
+ continue;
+ }
++ /* match of hash is sufficient for bootstrap of trust point */
++ (void)reason;
++ (void)ve;
++ return 1;
++ /* no need to check RRSIG, DS hash already matched with source
+ if(dnskey_verify_rrset(env, ve, dnskey_rrset,
+ dnskey_rrset, key_idx, ) == sec_status_secure) {
+ return 1;
+@@ -1578,6 +1583,7 @@ key_m
Bug#871437: Please ship a .pc file in the libsnappy-dev package
Package: libsnappy-dev Version: 1.1.6-2 Severity: wishlist Hi, Please ship a .pc file in the libsnappy-dev package. It looks like snappy 1.1.6 ships both an autotools and CMake build system, but the Debian package now uses the CMake build system, which doesn't support installing a .pc file. However, there is an upstream pull request to re-add .pc support to the CMake build system: https://github.com/google/snappy/pull/51. Thanks! -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libsnappy-dev depends on: ii libsnappy1v5 1.1.6-2 libsnappy-dev recommends no packages. libsnappy-dev suggests no packages. -- no debconf information -- Robert Edmonds edmo...@debian.org
Bug#855118: wrk: only loops and burns CPU
Christos Trochalakis wrote: > I plan to upload it as an nmu on Monday unless Robert wants to prepare > the upload himself. I have just pushed those fixes to the packaging repo > (nmu branch). > > https://anonscm.debian.org/cgit/collab-maint/wrk.git/log/?h=nmu Thanks, just uploaded these changes as 4.0.2-2. -- Robert Edmonds edmo...@debian.org
Bug#870571: ITP: avro-c -- Apache Avro C
Package: wnpp Severity: wishlist Owner: Robert Edmonds <edmo...@debian.org> * Package name: avro-c Version : 1.8.2 Upstream Author : The Apache Software Foundation * URL : http://avro.apache.org/ * License : Apache-2.0 Programming Lang: C Description : Apache Avro C (avro-c) library Apache Avro is a data serialization system. Avro provides rich data structures; a binary data format; and a container file format, to store Avro-encoded data persistently. . This package provides the "avro-c" implementation of Apache Avro in C. The C implementation supports: . * binary encoding/decoding of all primitive and complex data types * storage to an Avro Object Container File * schema resolution, promotion and projection * validating and non-validating mode for writing Avro data . The C implementation of Avro lacks RPC support. -- Robert Edmonds edmo...@debian.org signature.asc Description: PGP signature
Bug#867192: [Pkg-dns-devel] Bug#867192: let systemd know about the pid file
Simon Deziel wrote: > When unbound is stopped, its PID file is left behind causing subsequent > service starts to complain like that: > > unbound[178]: [178:0] warning: did not exit gracefully last time (124) > > Please find a patch that tells systemd where the PID is so that it can > delete it once unbound is stopped. Hi, Simon: Are you sure about this? When I "systemctl stop unbound", "systemctl start unbound", I get the following output in the journal: Jul 14 18:12:52 chase systemd[1]: Stopping Unbound DNS server... Jul 14 18:12:52 chase unbound[26190]: [26190:0] info: service stopped (unbound 1.6.4). Jul 14 18:12:52 chase unbound[26190]: [26190:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting Jul 14 18:12:52 chase unbound[26190]: [26190:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 Jul 14 18:12:52 chase systemd[1]: Stopped Unbound DNS server. Jul 14 18:13:00 chase systemd[1]: Starting Unbound DNS server... Jul 14 18:13:00 chase package-helper[26343]: /var/lib/unbound/root.key has content Jul 14 18:13:00 chase package-helper[26343]: success: the anchor is ok Jul 14 18:13:00 chase unbound[26347]: [26347:0] notice: init module 0: validator Jul 14 18:13:00 chase unbound[26347]: [26347:0] notice: init module 1: iterator Jul 14 18:13:00 chase unbound[26347]: [26347:0] info: start of service (unbound 1.6.4). Jul 14 18:13:00 chase systemd[1]: Started Unbound DNS server. It also looks like unbound truncates the pidfile when it shuts down? -- Robert Edmonds edmo...@debian.org
Bug#867192: [Pkg-dns-devel] Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: let systemd know about the pid file
Daniel Kahn Gillmor wrote: > On Fri 2017-07-14 16:25:26 -0400, Robert Edmonds wrote: > > Well, we would append the "-p /run/unbound.pid" bit to DAEMON_OPTS in > > the sysvinit script unconditionally, something like: > > > > [...] > > # Override this variable by editing or creating /etc/default/unbound. > > DAEMON_OPTS="" > > > > if [ -f /etc/default/unbound ]; then > > . /etc/default/unbound > > fi > > > > DAEMON_OPTS="$DAEMON_OPTS -p $PIDFILE" > > [...] > > > > No changes to the interface/contract. In fact this seems less broken to > > me, because we hardcode the path to the pidfile in the sysvinit script. > > Currently, if you set 'pidfile' yourself to some other value in the > > Unbound config then start-stop-daemon looks in the wrong place for the > > pidfile. > > I understand what you're saying from the point of view of debian, though > it still makes it a little bit strange because then anyone who manually > puts DAEMON_OPTS="-p /foo/bar" in /etc/default/unbound has it get > overridden. I guess we could override the variable like: DAEMON_OPTS="-p ... $DAEMON_OPTS" so that if DAEMON_OPTS="-p ..." appears in /etc/default/unbound, the setting in /etc/default/unbound would take precedence. But if you're trying to override the pidfile path, this has never actually worked without editing the sysvinit script, so I don't care too much about this use case. > But i was thinking about the issue from upstream -- they have to > coordinate their daemon changes with everyone using unbound, and the > semantics of running "unbound -c foo.conf" will now change if we change > the default, since the default path for the pidfile itself is currently > compiled in (if you don't specify pidfile in the config file it'll still > create a pidfile, i think). > > One way to make your approach more feasible (without changing upstream's > expected contracts generically) would be to something like (untested): > > ./configure --with-pidfile= > > (that is, the empty pidfile). Then anyone on a debian system without a > pidfile directive in the .conf just wouldn't get a pidfile (since > daemon/unbound.c tests pidfile[0]). if we did that, then adding your > proposed implementation to the init script would make sense -- because > there'd be no public expectation that -p is something you'd manually > supply in DAEMON_OPTS. I guess we're saying that "-p /foo/bar" should > take precedence over 'pidfile: "/baz/qux"' in the config file, right? Yeah, exactly. -- Robert Edmonds edmo...@debian.org
Bug#867192: [Pkg-dns-devel] Bug#867192: Bug#867192: Bug#867192: Bug#867192: Bug#867192: let systemd know about the pid file
Daniel Kahn Gillmor wrote: > On Fri 2017-07-14 14:19:01 -0400, Robert Edmonds wrote: > > Hm, that could work (but then we have to carry around "-p" in the > > service unit forever). I was thinking of a command-line parameter that > > takes an argument to the pidfile path (like "-p /run/unbound.pid") that > > takes precedence over the 'pidfile' value from the config file and the > > compiled in 'pidfile' default value. And then we set the default value > > for 'pidfile' to "" so that Unbound doesn't make a pidfile by default, > > and append "-p /run/unbound.pid" to $DAEMON_OPTS in /etc/init.d/unbound. > > I figured if we went that way we'd get complaints about changing the > expected interface/contract with existing users of unbound -- you > upgrade the main binary on a system that *doesn't* have a > sensible/modern process manager, and then all of a sudden you don't get > the pidfile protections by default! Well, we would append the "-p /run/unbound.pid" bit to DAEMON_OPTS in the sysvinit script unconditionally, something like: [...] # Override this variable by editing or creating /etc/default/unbound. DAEMON_OPTS="" if [ -f /etc/default/unbound ]; then . /etc/default/unbound fi DAEMON_OPTS="$DAEMON_OPTS -p $PIDFILE" [...] No changes to the interface/contract. In fact this seems less broken to me, because we hardcode the path to the pidfile in the sysvinit script. Currently, if you set 'pidfile' yourself to some other value in the Unbound config then start-stop-daemon looks in the wrong place for the pidfile. -- Robert Edmonds edmo...@debian.org
Bug#867192: [Pkg-dns-devel] Bug#867192: Bug#867192: Bug#867192: Bug#867192: let systemd know about the pid file
Daniel Kahn Gillmor wrote: > On Fri 2017-07-14 12:32:57 -0400, Robert Edmonds wrote: > > So we either need to configure systemd to delete Unbound's pidfile, or > > we could develop and contribute a patch upstream that allows overriding > > the pidfile via the command-line. > > ok, how about something like this: > > https://github.com/NLnetLabs/unbound/pull/1 Hm, that could work (but then we have to carry around "-p" in the service unit forever). I was thinking of a command-line parameter that takes an argument to the pidfile path (like "-p /run/unbound.pid") that takes precedence over the 'pidfile' value from the config file and the compiled in 'pidfile' default value. And then we set the default value for 'pidfile' to "" so that Unbound doesn't make a pidfile by default, and append "-p /run/unbound.pid" to $DAEMON_OPTS in /etc/init.d/unbound. BTW, I don't think upstream really monitors that GitHub repository, it's a git-svn mirror. Posting patches to the mailing list or bugzilla seems to be their thing. -- Robert Edmonds edmo...@debian.org
Bug#867192: [Pkg-dns-devel] Bug#867192: Bug#867192: let systemd know about the pid file
Daniel Kahn Gillmor wrote: > On Tue 2017-07-11 21:45:22 -0400, Simon Deziel wrote: > > Having a PID file seems to be the easiest way to make both systemd and > > SysV happy. > > fwiw, i think that systemd would be happier without a pidfile. using a > pidfile introduces a failure mode (as we see here) that is entirely > unnecessary in a system with proper process supervision. > > The fact that systemd *can* do something about a pidfile doesn't mean > that anyone should prefer it. I really hope we can drop pidfiles where > we don't need them. Unfortunately, we have to continue supporting the sysvinit script (the only plausible "compelling reason" to remove the sysvinit script per #746715 I can think of would be the removal of sysvinit itself from the archive), and the only way to configure Unbound's 'pidfile' parameter is via the config. So we either need to configure systemd to delete Unbound's pidfile, or we could develop and contribute a patch upstream that allows overriding the pidfile via the command-line. Then we could disable the pidfile by default (for modern init systems), and enable the pidfile via the command-line (for sysvinit) in the init script. -- Robert Edmonds edmo...@debian.org
Bug#867828: [Pkg-dns-devel] Bug#867828: fails to bind ipv6 interface
Peter Palfrader wrote: > knot does not listen on all configured addresses after system boot. Hi, Peter: This sounds like knot is being started before DAD completes on the interface. But I was under the impression this was fixed in ifupdown with the fix for #705996. Does 'journalctl -b -u networking.service' show a "Waiting for DAD" message like this? root@li:~# journalctl -b -u networking.service -- Logs begin at Wed 2016-12-28 14:39:21 EST, end at Sun 2017-07-09 16:08:32 EDT. -- Jul 09 16:08:01 li systemd[1]: Starting Raise network interfaces... Jul 09 16:08:02 li ifup[559]: Waiting for DAD... Done Jul 09 16:08:02 li systemd[1]: Started Raise network interfaces. root@li:~# The version of knot that you're using will attempt to perform a non-local bind on the UDP socket, but not the TCP socket, which is pending an upstream fix: https://gitlab.labs.nic.cz/labs/knot/merge_requests/740 But the non-local bind shouldn't be necessary in the first place, hm. Just in case, can you also verify that knot is definitely being started after networking has been brought up? Something like: journalctl -b -o short-monotonic -u networking.service -u knot.service should show it. -- Robert Edmonds edmo...@debian.org
Bug#866804: [Pkg-dns-devel] Bug#866804: unbound: please start with Type=forking to wait for successful initialisation
Peter Colberg wrote: > Forking to the background (Type=forking) is the recommended way to > signal to systemd that a daemon has initialised successfully and is > ready for operation; at least for daemons without explicit systemd > support (Type=notify). Hi, Peter: Since the latest upstream release supports sd_notify() we'll probably switch to Type=notify instead of using Type=forking. -- Robert Edmonds edmo...@debian.org
Bug#864730: unbound: malformed packet DoS when "use-caps-for-id" enabled
Source: unbound
Tags: security
Unbound has a faulty assertion that can be triggered remotely when the
"use-caps-for-id" option is enabled (it is disabled in the default
configs shipped by upstream and Debian) when a response is received from
a nameserver. It was fixed in the upstream 1.6.3 release, and the
corresponding patch from the upstream SVN repository is attached.
--
Robert Edmonds
edmo...@debian.org
From c2a5986416194109df7a6be7e964571fc2e068c5 Mon Sep 17 00:00:00 2001
From: wouter <wouter@be551aaa-1e26-0410-a405-d3ace91eadb9>
Date: Tue, 13 Jun 2017 13:55:40 +
Subject: [PATCH] - Fix #1280: Unbound fails assert when response from
authoritative contains malformed qname. When 0x20 caps-for-id is enabled,
when assertions are not enabled the malformed qname is handled correctly. -
tag for 1.6.3
git-svn-id: http://unbound.nlnetlabs.nl/svn/tags/release-1.6.3@4223 be551aaa-1e26-0410-a405-d3ace91eadb9
---
doc/Changelog | 6 ++
services/outside_network.c | 2 +-
testdata/fwd_malformed.tpkg | Bin 0 -> 1481 bytes
3 files changed, 7 insertions(+), 1 deletion(-)
create mode 100644 testdata/fwd_malformed.tpkg
diff --git a/doc/Changelog b/doc/Changelog
index 2a90abe3..8f8d6dae 100644
--- a/doc/Changelog
+++ b/doc/Changelog
@@ -1,3 +1,9 @@
+13 June 2017: Wouter
+ - Fix #1280: Unbound fails assert when response from authoritative
+ contains malformed qname. When 0x20 caps-for-id is enabled, when
+ assertions are not enabled the malformed qname is handled correctly.
+ - tag for 1.6.3
+
13 April 2017: Wouter
- Fix #1250: inconsistent indentation in services/listen_dnsport.c.
- tag for 1.6.2rc1
diff --git a/services/outside_network.c b/services/outside_network.c
index 88fc5a91..426e87b3 100644
--- a/services/outside_network.c
+++ b/services/outside_network.c
@@ -1549,7 +1549,7 @@ serviced_check_qname(sldns_buffer* pkt, uint8_t* qbuf, size_t qbuflen)
return 0;
while(len1 != 0 || len2 != 0) {
if(LABEL_IS_PTR(len1)) {
- d1 = sldns_buffer_at(pkt, PTR_OFFSET(len1, *d1));
+ d1 = sldns_buffer_begin(pkt)+PTR_OFFSET(len1, *d1);
if(d1 >= sldns_buffer_at(pkt, sldns_buffer_limit(pkt)))
return 0;
len1 = *d1++;
diff --git a/testdata/fwd_malformed.tpkg b/testdata/fwd_malformed.tpkg
new file mode 100644
index ..82a11ac23d8882be2813bd0bba3c1b47429af4c1
GIT binary patch
literal 1481
zcmV;)1vdI0iwFR=qd!>y1MOICbJ|7_<}3Frw&1ao=}49YLKrt5+koq&33hA}r_**A
zp*uh^=+u)GOr}4+djg49m&`b^Cyh3-bhmf+?7i*7u6kqI8QH@g7b8Yh>Wcl`R~HS%
zvP}8bEmK>3Cz8`kx^7v9Ue?Mv4WE{k1M}-oWnH2mv;{zJ%%hNr`}=Kc|4ya1cK*v6
zhkLz;+K>lasg&<M|FUk*hxdMPJcD|!yJud%>w@`Im$z{DpeY9x=(E)U#rQUjCZ
zi{M2gB^(H5)1U@A$-5pdzh^rPYlfw2_z$%{7hw$0Q#GObI5zkoRlgagxXD
z#GH@|#4HrBvrBvK5CIC2*X5B%Rn(x~83@k9X&;0To;_mI8s&<|L*?&?iHS1gjy)Xk
zAe@3rV~*_y3f@%3r8StafM9uS3#xqP9>Yb=kW_?9T5L)Ms?s$aAGa^!=@$rj>ce;f
z+2;Q=a2{-9oBx}dmH59A>vgNFRWkp73^}y}){4Dk>D
Bug#864283: unblock: dns-root-data/2017041102
Ondřej Surý wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package dns-root-data > > Dear release team, > > Robert Edmonds has prepared patch to fix the regression caused by > dns-root-data package in dnsmasq, so the root.ds format can now be > parsed by both dnsmasq in testing and in unstable. > > Thanks goes to Robert to thinking better than me and preparing the > fix. > > unblock dns-root-data/2017041102 Hi, release team: There are further details about the fix in the commit message: https://anonscm.debian.org/cgit/pkg-dns/dns-root-data.git/commit/?id=be97d5a000cc592cacc50623883fb2d67f2b7432 This will fix the following bugs in stretch: #860064, #858506, #860274, #864016 Since this restores compatibility with the version of dnsmasq in stretch, it will also obsolete the unblock request for dnsmasq: #864085 The following transcript of a stretch machine running dnsmasq exhibits the buggy behavior with dns-root-data 2017041101 (testing) and the fixed behavior with dns-root-data 2017041102 (unstable). Thanks! root@845s:~# dpkg -l dnsmasq dns-root-data Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---== hi dns-root-data 2015052300+h+1 all DNS root data including root zone and DNSSEC key ii dnsmasq2.76-5 all Small caching DNS proxy and DHCP/TFTP server root@845s:~# systemctl -l -n0 status dnsmasq ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2017-06-06 10:46:39 EDT; 1h 2min ago Main PID: 8015 (dnsmasq) CGroup: /system.slice/dnsmasq.service └─8015 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -r /run/dnsmasq/resolv.conf -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 root@845s:~# apt install dns-root-data/stretch Reading package lists... Done Building dependency tree Reading state information... Done Selected version '2017041101' (Debian:testing [all]) for 'dns-root-data' The following held packages will be changed: dns-root-data (2015052300+h+1 => 2017041101) The following packages will be upgraded: dns-root-data (2015052300+h+1 => 2017041101) 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 4,670 B of archives. After this operation, 38.9 kB disk space will be freed. Do you want to continue? [Y/n] y Get:1 http://ftp.us.debian.org/debian stretch/main amd64 dns-root-data all 2017041101 [4,670 B] Fetched 4,670 B in 0s (25.3 kB/s) Reading changelogs... Done apt-listchanges: Changelogs --- dns-root-data (2017041101) unstable; urgency=medium * Fix parse-root-anchors.sh in non-dash shells (Closes: #862252) * Update to 2017041101 version of root zone * Remove timestamps from root.key to make the build reproducible * Shell syntax cleanup -- Ondřej Surý <ond...@debian.org> Mon, 29 May 2017 14:05:37 +0200 dns-root-data (2017020200) unstable; urgency=medium * Update to 2016102001 version of the root.zone * Add KSK-2017 (valid from 2017-02-02) into root.key file * Reduce number of IANA files as they don't exist at upstream anymore * draft-icann-dnssec-trust-anchor is now RFC 7958 * Update all other IANA DNSSEC files to 2017-02-02 versions * Strip the GPG verification as IANA doesn't provide the GPG signatures anymore * Rewrite DS creation check to xml2 and ldnsutils, as neither xmllint nor bind9utils handle multiple DNSKEY in one file correctly -- Ondřej Surý <ond...@debian.org> Wed, 22 Mar 2017 09:06:08 +0100 apt-listchanges: Do you want to continue? [Y/n] y (Reading database ... 51072 files and directories currently installed.) Preparing to unpack .../dns-root-data_2017041101_all.deb ... Unpacking dns-root-data (2017041101) over (2015052300+h+1) ... Setting up dns-root-data (2017041101) ... root@845s:~# systemctl -l -n0 status dnsmasq ● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2017-06-06 10:46:39 EDT; 1h 3min ago Main PID: 8015 (dnsmasq) CGroup: /system.slice/dnsmasq.service └─8015 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid
Bug#864016: [Pkg-dns-devel] Bug#864016: dns-root-data: Upgrade breaks dnsmasq
Robert Luberda wrote: > Upgraded dns-root-data should declare "Breaks: dnsmasq (<< 2.77-1~)", > see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863896#15 A "Breaks" doesn't really make sense here. There are only cosmetic differences between the root.ds file format generated by previous versions of dns-root-data and the current version in testing/unstable. If we're going to make another dns-root-data upload for stretch we should just switch the format to something that dnsmasq in testing can understand. Something like this in root.ds would support both the ad hoc sed parsers in dnsmasq 2.76-5 (testing) and dnsmasq 2.77-1: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d The attached patch implements this format. (BTW, I'm not sure what's going on with the just-uploaded sed parser in dnsmasq 2.77-2. It generates the message "sed: -e expression #1, char 103: Invalid range end" when I try to run it.) -- Robert Edmonds edmo...@debian.org >From bf353876ab64a7c3afe9c72ea8019d6df89bbf42 Mon Sep 17 00:00:00 2001 From: Robert Edmonds <edmo...@debian.org> Date: Tue, 6 Jun 2017 00:55:19 -0400 Subject: [PATCH] Change DS creation to omit TTL and use spaces instead of tabs (Closes: #864016) The version of dnsmasq in testing (currently 2.76-5) and which will apparently be released with stretch uses the following sed parser to convert the root.ds file in dns-root-data to command-line arguments for dnsmasq: sed -e s/". IN DS "/--trust-anchor=.,/ -e s/" "/,/g $ROOT_DS This chokes on the root.ds file shipped in the dns-root-data 2017041101 package. (See #858506 and #860064.) Consequently dnsmasq 2.77-1 shipped the following parser: sed -e s/"^.*DS[\t ]"/--trust-anchor=.,/ -e s/" "/,/g $ROOT_DS This commit relaxes the format of the root.ds file so that it can be parsed by the init script in both dnsmasq 2.76-5 and dnsmasq 2.77-1, by removing the TTL field (which doesn't make much sense for a trust anchor anyway) and converting the tab characters to spaces. This results in the following root.ds content: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Both the dnsmasq 2.76-5 and 2.77-1 parsers convert the above root.ds content to the following dnsmasq command-line arguments: --trust-anchor=.,19036,8,2,49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d For comparison, previous versions of dns-root-data (before we started shipping the second trust anchor for the KSK rollover) formatted the root.ds file like this: . IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 This commit also adds a workaround in debian/rules to munge the output of ldns-key2ds so that the diff comparison will succeed. --- debian/rules | 2 +- parse-root-anchors.sh | 4 +--- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/debian/rules b/debian/rules index 16893f5..b697fc0 100755 --- a/debian/rules +++ b/debian/rules @@ -18,7 +18,7 @@ override_dh_auto_build: ./parse-root-anchors.sh < root-anchors.xml > root-anchors.ds # Create key from downloaded root.key - /usr/bin/ldns-key2ds -n -2 root.key > root.ds + /usr/bin/ldns-key2ds -n -2 root.key | sed -e 's/\t/ /g' -e 's/ 172800//' > root.ds # Compare the DS from root.key and from root-anchors.xml diff root-anchors.ds root.ds diff --git a/parse-root-anchors.sh b/parse-root-anchors.sh index 3f96d69..4281534 100755 --- a/parse-root-anchors.sh +++ b/parse-root-anchors.sh @@ -2,8 +2,6 @@ unset ZONE KTAG ALGO DTYPE DIGEST -TTL=172800 - export IFS="=" xml2 | while read -r KEY VAL; do case "$KEY" in @@ -17,7 +15,7 @@ xml2 | while read -r KEY VAL; do echo "Missing some KeyDigest parameter" exit 1 fi - printf "%s\t%s\tIN\tDS\t%s %s %s %s\n" "$ZONE" "$TTL" "$KTAG" "$ALGO" "$DTYPE" "$DIGEST" + printf "%s IN DS %s %s %s %s\n" "$ZONE" "$KTAG" "$ALGO" "$DTYPE" "$DIGEST" unset KTAG ALGO DTYPE DIGEST ;; esac -- 2.11.0
Bug#861523: bup: FTBFS: t/test-ls.sh:64 '1977-09-05-135600 latest' = '1977-09-05-125600 latest' FAILED
Christoph Biedl wrote: > tags 861523 moreinfo unreproducible > thanks > > Chris Lamb wrote... > > > ! t/test-ls.sh:64 '1977-09-05-135600 latest' = '1977-09-05-125600 > > latest' FAILED > > I was unable to reproduce your report. Can you please re-check? > > Christoph Hi, Chris: I can't reproduce this either. I tried building with root and non-root users, and with the timezone set to Europe/London. Could you share more details about the build environment? (Especially what filesystem is being used.) -- Robert Edmonds edmo...@debian.org
Bug#860335: linux: [armhf] ahci_mvebu module is missing from sata-modules udeb
Package: linux Version: 4.9.18-1 Severity: normal Tags: d-i patch Hi, The sata-modules udeb on armhf is missing the "ahci_mvebu" module. This prevents, e.g., installing Debian to an mSATA SSD installed in a Marvell Armada 385 SoC based system like the Turris Omnia. I was able to complete an install using the d-i stretch rc3 release after manually copying ahci_mvebu.ko to the running installer environment and modprobe'ing it, so I think the attached patch will fix this problem. (See #860286 for the installation report.) Thanks! -- Robert Edmonds edmo...@debian.org >From efa1c34a255f9ead2dd3591bb076b5b9d9c05110 Mon Sep 17 00:00:00 2001 From: Robert Edmonds <edmo...@debian.org> Date: Fri, 14 Apr 2017 12:55:13 -0400 Subject: [PATCH] [armhf] sata-modules: Add module required for Turris Omnia mSATA --- debian/installer/armhf/modules/armhf-armmp/sata-modules | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/installer/armhf/modules/armhf-armmp/sata-modules b/debian/installer/armhf/modules/armhf-armmp/sata-modules index 70d5e3674..a1b457370 100644 --- a/debian/installer/armhf/modules/armhf-armmp/sata-modules +++ b/debian/installer/armhf/modules/armhf-armmp/sata-modules @@ -3,6 +3,7 @@ ahci_platform ahci_imx ahci_sunxi ahci_tegra +ahci_mvebu sata_highbank # SATA PHYs -- 2.11.0
Bug#860286: installation-reports: Turris Omnia (stretch rc3; missing "ahci_mvebu.ko" module)
0x0100 0x0300:$filesize 0x0200' setenv debbootcmd 'i2c dev 1; i2c read 0x2a 0x9 1 0x00F0; setexpr.b rescue *0x00F0; if test $rescue -ge 2; then echo BOOT RESCUE; run rescueboot; else if test $rescue -ge 1; then echo BOOT eMMC TurrisOS FS; run mmcboot; else echo BOOT Debian FS; run debboot; fi; fi' setenv bootcmd "$debbootcmd" saveenv boot The machine then successfully booted Debian. [0] https://wiki.debian.org/InstallingDebianOn/TurrisOmnia -- Robert Edmonds edmo...@debian.org
Bug#859337: [Pkg-dns-devel] Bug#859337: Bug#859337: unbound: 1.6.0-3 breaks resolving deb.debian.org
Julien Cristau wrote: > On 04/02/2017 10:07 AM, Robert Edmonds wrote: > > Julien Cristau wrote: > >> Package: unbound > >> Version: 1.6.0-3 > >> Severity: grave > >> > >> Hi, > >> > >> after upgrading from 1.6.0-2 to 1.6.0-3 unbound can't seem to be able to > >> resolve deb.debian.org. Upping the verbosity I get the feeling it's > >> alternating between querying deb.debian.org DS and static.debian.org DS, > >> never going up to debian.org DS. Downgrading makes things work again. > >> > >> Apr 2 15:49:55 tomate unbound: [685:0] info: resolving deb.debian.org. A > >> IN > >> Apr 2 15:49:55 tomate unbound: [685:0] info: resolving deb.debian.org. A > >> IN > >> Apr 2 15:49:55 tomate unbound: [685:0] info: resolving deb.debian.org. > >> DS IN > >> Apr 2 15:49:56 tomate unbound: [685:0] info: response for > >> deb.debian.org. DS IN > >> Apr 2 15:49:56 tomate unbound: [685:0] info: reply from <.> 4.2.2.1#53 > > > > Hi, Julien: > > > > Are you forwarding queries to 4.2.2.1? > > > Looks like it's in the domain-name-servers dhcp option on this network, > so yes (through dnssec-trigger). > > > Could you send your unbound.conf and any conf.d files and I'll try to > > replicate the problem? > > > unbound.conf says > include: "/etc/unbound/unbound.conf.d/*.conf" > > The entries in unbound.conf.d set "qname-minimisation: yes" and > "auto-trust-anchor-file: "/var/lib/unbound/root.key"" > > And then dnssec-trigger sets the forwarding. Hi, Julien: It's very unlikely that this was a regression introduced in 1.6.0-3. The only change between 1.6.0-2 and 1.6.0-3 was to cherry-pick the updated root trust anchor for the upcoming DNSSEC root KSK rollover, which should have no impact on DNSSEC validation until that rollover actually begins. More likely, I would guess that there is some problem with the 4.2.2.1 resolver from your location that breaks DNSSEC validation, and when you downgraded to 1.6.0-2, the forwarding configuration got lost somehow and Unbound started performing full recursion. You can test whether forwarding is enabled for the running Unbound by running 'unbound-control forward' as root, which should print something like "4.2.2.1" or "off (using root hints)". If I recall correctly, Unbound requires that the upstream resolver itself perform DNSSEC validation, and the 4.2.2.1 nameserver doesn't perform DNSSEC validation, at least the instance that I queried. (The 4.2.2.x nameservers are anycasted.) You might try posting to the unbound-users mailing list (https://open.nlnetlabs.nl/mailman/listinfo/unbound-users) about your issue, since the upstream developers are generally pretty good about helping users debug DNSSEC validation issues. -- Robert Edmonds edmo...@debian.org
Bug#859337: [Pkg-dns-devel] Bug#859337: unbound: 1.6.0-3 breaks resolving deb.debian.org
Julien Cristau wrote: > Package: unbound > Version: 1.6.0-3 > Severity: grave > > Hi, > > after upgrading from 1.6.0-2 to 1.6.0-3 unbound can't seem to be able to > resolve deb.debian.org. Upping the verbosity I get the feeling it's > alternating between querying deb.debian.org DS and static.debian.org DS, > never going up to debian.org DS. Downgrading makes things work again. > > Apr 2 15:49:55 tomate unbound: [685:0] info: resolving deb.debian.org. A IN > Apr 2 15:49:55 tomate unbound: [685:0] info: resolving deb.debian.org. A IN > Apr 2 15:49:55 tomate unbound: [685:0] info: resolving deb.debian.org. > DS IN > Apr 2 15:49:56 tomate unbound: [685:0] info: response for > deb.debian.org. DS IN > Apr 2 15:49:56 tomate unbound: [685:0] info: reply from <.> 4.2.2.1#53 Hi, Julien: Are you forwarding queries to 4.2.2.1? Could you send your unbound.conf and any conf.d files and I'll try to replicate the problem? -- Robert Edmonds edmo...@debian.org
Bug#859296: unblock: bup/0.29-3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Hi,
I'd like to request a freeze unblock for bup 0.29-3. This package
contains a targeted fix (recommended by upstream) from the bup 0.29.1
release for RC bug #859295. This bug affects testing and can cause
serious data loss, potentially corrupting a bup backup repository in
certain situations if the 'bup gc' command is used. The source debdiff
is attached.
unblock bup/0.29-3
Thanks!
--
Robert Edmonds
edmo...@debian.org
diff -Nru bup-0.29/debian/changelog bup-0.29/debian/changelog
--- bup-0.29/debian/changelog 2017-01-01 14:42:37.0 -0500
+++ bup-0.29/debian/changelog 2017-04-01 14:38:19.0 -0400
@@ -1,3 +1,11 @@
+bup (0.29-3) unstable; urgency=medium
+
+ [ Tim Riemenschneider ]
+ * Safeguard against deleting new pack-file (f.e. with threshold=0)
+(Closes: #859295)
+
+ -- Robert Edmonds <edmo...@debian.org> Sat, 01 Apr 2017 14:38:19 -0400
+
bup (0.29-2) unstable; urgency=medium
[ James Cowgill ]
diff -Nru bup-0.29/debian/patches/debian-changes
bup-0.29/debian/patches/debian-changes
--- bup-0.29/debian/patches/debian-changes 2017-01-01 14:42:37.0
-0500
+++ bup-0.29/debian/patches/debian-changes 2017-04-01 14:38:19.0
-0400
@@ -5,15 +5,13 @@
information below has been extracted from the changelog. Adjust it or drop
it.
.
- bup (0.29-2) unstable; urgency=medium
+ bup (0.29-3) unstable; urgency=medium
.
- [ James Cowgill ]
- * Build-Depend on tzdata to fix FTBFS. (Closes: #839498)
- .
- [ Robert Edmonds ]
- * debian/changelog: Acknowledge 0.28.1-1.1 NMU
+ [ Tim Riemenschneider ]
+ * Safeguard against deleting new pack-file (f.e. with threshold=0)
+ (Closes: #859295)
Author: Robert Edmonds <edmo...@debian.org>
-Bug-Debian: https://bugs.debian.org/839498
+Bug-Debian: https://bugs.debian.org/859295
---
The information above should follow the Patch Tagging Guidelines, please
@@ -26,7 +24,7 @@
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: <no|not-needed|url proving that it has been forwarded>
Reviewed-By:
-Last-Update: 2017-01-01
+Last-Update: 2017-04-01
--- bup-0.29.orig/Makefile
+++ bup-0.29/Makefile
@@ -63,7 +61,7 @@
+++ bup-0.29/config/config.h.tmp
@@ -0,0 +1,27 @@
+/*
-+ * configuration for bup, generated Sun Jan 1 19:47:37 UTC 2017
++ * configuration for bup, generated Sat Apr 1 18:42:19 UTC 2017
+ * by pbuilder@chase
+ */
+#ifndef __AC_BUP_D
@@ -98,6 +96,43 @@
-COMMIT='$Format:%H$'
-NAMES='$Format:%d$'
-DATE='$Format:%ci$'
-+COMMIT='5c71e0f3540c7950185f2747efce4b7ef5b29980'
-+NAMES=' (HEAD -> branches/0.29, tag: debian/0.29-2)'
-+DATE='2017-01-01 14:43:38 -0500'
++COMMIT='3cf1801c6937bd0b07cd42eadf14dcb684a6f788'
++NAMES=' (HEAD -> branches/0.29, tag: debian/0.29-3)'
++DATE='2017-04-01 14:39:51 -0400'
+--- bup-0.29.orig/lib/bup/gc.py
bup-0.29/lib/bup/gc.py
+@@ -135,6 +135,8 @@ def sweep(live_objects, existing_count,
+ if verbosity and new_pack_prefix:
+ log('created ' + basename(new_pack_prefix) + '\n')
+ for p in ns.stale_files:
++if new_pack_prefix and p.startswith(new_pack_prefix):
++continue # Don't remove the new pack file
+ if verbosity:
+ log('removing ' + basename(p) + '\n')
+ os.unlink(p)
+--- bup-0.29.orig/t/test-gc.sh
bup-0.29/t/test-gc.sh
+@@ -219,4 +219,23 @@ WVPASSEQ 1 $(echo "$only_in_before" | wc
+ WVPASSEQ 1 $(echo "$only_in_after" | wc -l)
+ WVPASSEQ 1 $(echo "$in_both" | wc -l)
+
++WVSTART "gc (threshold 0)"
++
++WVPASS rm -rf "$BUP_DIR"
++WVPASS bup init
++WVPASS rm -rf src && mkdir src
++WVPASS echo 0 > src/0
++WVPASS echo 1 > src/1
++
++WVPASS bup index src
++WVPASS bup save -n src-1 src
++
++packs_before="$(ls "$BUP_DIR/objects/pack/"*.pack)" || exit $?
++WVPASS bup gc -v $GC_OPTS --threshold 0 2>&1 | tee gc.log
++packs_after="$(ls "$BUP_DIR/objects/pack/"*.pack)" || exit $?
++# Check that the pack was rewritten, but not removed (since the
++# result-pack is equal to the source pack)
++WVPASSEQ 1 "$(grep -cE '^rewriting ' gc.log)"
++WVPASSEQ "$packs_before" "$packs_after"
++
+ WVPASS rm -rf "$tmpdir"
signature.asc
Description: PGP signature
Bug#859295: bup: Fix possible 'bup gc --threshold=0' data loss
Package: bup
Version: 0.29-2
Severity: critical
Justification: possibility of serious data loss
Hi,
The bup 0.29.1 release contains a fix for a bug that can cause serious
data loss (dbda0e98074b8b6ec20f4bdf5479b2847cc8eb0e, attached). From the
upstream release notes:
Notable changes in 0.29.1 as compared to 0.29
=
May require attention
-
* Running gc with a --threshold of 0 no longer runs the risk of
corrupting the repository. (The default threshold is 10).
Previously, gc could delete a packfile after rewriting it when the
packfile didn't change.
This commit should be cherry-picked for stretch.
--
Robert Edmonds
edmo...@debian.org
>From dbda0e98074b8b6ec20f4bdf5479b2847cc8eb0e Mon Sep 17 00:00:00 2001
From: Tim Riemenschneider <g...@tim-riemenschneider.de>
Date: Mon, 6 Mar 2017 23:08:46 +0100
Subject: [PATCH] Saveguard against deleting new pack-file (f.e. with
threshold=0)
Signed-off-by: Tim Riemenschneider <g...@tim-riemenschneider.de>
[r...@defaultvalue.org: wrap comment line in test-gc.sh; adjust comment
whitespace in gc.py]
Reviewed-by: Rob Browning <r...@defaultvalue.org>
Tested-by: Rob Browning <r...@defaultvalue.org>
---
lib/bup/gc.py | 2 ++
t/test-gc.sh | 19 +++
2 files changed, 21 insertions(+)
diff --git a/lib/bup/gc.py b/lib/bup/gc.py
index c0a1c0e..395094a 100644
--- a/lib/bup/gc.py
+++ b/lib/bup/gc.py
@@ -135,6 +135,8 @@ def sweep(live_objects, existing_count, cat_pipe, threshold, compression,
if verbosity and new_pack_prefix:
log('created ' + basename(new_pack_prefix) + '\n')
for p in ns.stale_files:
+if new_pack_prefix and p.startswith(new_pack_prefix):
+continue # Don't remove the new pack file
if verbosity:
log('removing ' + basename(p) + '\n')
os.unlink(p)
diff --git a/t/test-gc.sh b/t/test-gc.sh
index 82be29c..2739ae7 100755
--- a/t/test-gc.sh
+++ b/t/test-gc.sh
@@ -219,4 +219,23 @@ WVPASSEQ 1 $(echo "$only_in_before" | wc -l)
WVPASSEQ 1 $(echo "$only_in_after" | wc -l)
WVPASSEQ 1 $(echo "$in_both" | wc -l)
+WVSTART "gc (threshold 0)"
+
+WVPASS rm -rf "$BUP_DIR"
+WVPASS bup init
+WVPASS rm -rf src && mkdir src
+WVPASS echo 0 > src/0
+WVPASS echo 1 > src/1
+
+WVPASS bup index src
+WVPASS bup save -n src-1 src
+
+packs_before="$(ls "$BUP_DIR/objects/pack/"*.pack)" || exit $?
+WVPASS bup gc -v $GC_OPTS --threshold 0 2>&1 | tee gc.log
+packs_after="$(ls "$BUP_DIR/objects/pack/"*.pack)" || exit $?
+# Check that the pack was rewritten, but not removed (since the
+# result-pack is equal to the source pack)
+WVPASSEQ 1 "$(grep -cE '^rewriting ' gc.log)"
+WVPASSEQ "$packs_before" "$packs_after"
+
WVPASS rm -rf "$tmpdir"
--
2.11.0
Bug#855635: unblock: unbound/1.6.0-3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Hi,
I'd like to request a freeze unblock for unbound 1.6.0-3. The only
difference between 1.6.0-2 (testing) and 1.6.0-3 (unstable) is that I've
cherry-picked an update from upstream that adds the DNSSEC trust anchor
for the new key-signing key generated for the root. See bug #855484 for
more details.
See https://www.icann.org/resources/pages/ksk-rollover for details about
the root DNSSEC key-signing key rollover.
(If this change is approved, you should verify that the debdiff matches
what is in the source package in the archive, and that the trust anchors
in the package match what is published by IANA at
https://data.iana.org/root-anchors/root-anchors.xml.)
unblock unbound/1.6.0-3
Thanks!
--
Robert Edmonds
edmo...@debian.org
diff -Nru unbound-1.6.0/debian/changelog unbound-1.6.0/debian/changelog
--- unbound-1.6.0/debian/changelog 2016-12-18 15:00:12.0 -0500
+++ unbound-1.6.0/debian/changelog 2017-02-19 20:04:34.0 -0500
@@ -1,3 +1,10 @@
+unbound (1.6.0-3) unstable; urgency=medium
+
+ * Cherry-pick upstream commit svn r4000, "Include root trust anchor id
+20326 in unbound-anchor". (Closes: #855484)
+
+ -- Robert Edmonds <edmo...@debian.org> Sun, 19 Feb 2017 20:04:34 -0500
+
unbound (1.6.0-2) unstable; urgency=high
[ Helmut Grohne ]
diff -Nru unbound-1.6.0/debian/patches/debian-changes
unbound-1.6.0/debian/patches/debian-changes
--- unbound-1.6.0/debian/patches/debian-changes 2016-12-18 15:00:12.0
-0500
+++ unbound-1.6.0/debian/patches/debian-changes 2017-02-19 20:04:34.0
-0500
@@ -5,12 +5,12 @@
information below has been extracted from the changelog. Adjust it or drop
it.
.
- unbound (1.6.0-2) unstable; urgency=high
+ unbound (1.6.0-3) unstable; urgency=medium
.
- [ Helmut Grohne ]
- * Only use fake_dsa when HAVE_SSL is defined (Closes: #848339)
+ * Cherry-pick upstream commit svn r4000, "Include root trust anchor id
+ 20326 in unbound-anchor". (Closes: #855484)
Author: Robert Edmonds <edmo...@debian.org>
-Bug-Debian: https://bugs.debian.org/848339
+Bug-Debian: https://bugs.debian.org/855484
---
The information above should follow the Patch Tagging Guidelines, please
@@ -23,7 +23,7 @@
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: <no|not-needed|url proving that it has been forwarded>
Reviewed-By:
-Last-Update: 2016-12-18
+Last-Update: 2017-02-20
--- unbound-1.6.0.orig/acx_python.m4
+++ unbound-1.6.0/acx_python.m4
@@ -52,6 +52,20 @@
If turned off, the server does not listen for control commands.
.TP 5
.B control\-interface: \fI
+--- unbound-1.6.0.orig/smallapp/unbound-anchor.c
unbound-1.6.0/smallapp/unbound-anchor.c
+@@ -241,7 +241,10 @@ static const char*
+ get_builtin_ds(void)
+ {
+ return
+-". IN DS 19036 8 2
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5\n";
++/* anchor 19036 is from 2010 */
++/* anchor 20326 is from 2017 */
++". IN DS 19036 8 2
49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5\n"
++". IN DS 20326 8 2
E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D\n";
+ }
+
+ /** print hex data */
--- unbound-1.6.0.orig/smallapp/unbound-control-setup.sh.in
+++ unbound-1.6.0/smallapp/unbound-control-setup.sh.in
@@ -155,6 +155,6 @@ chmod o-rw $SVR_BASE.pem $SVR_BASE.key $
signature.asc
Description: PGP signature
Bug#855484: unbound: Missing trust anchor for root KSK-2017 key
Package: unbound
Version: 1.6.0-2
Severity: serious
Justification: package maintainer's opinion
Hi,
I'd like to update the DNSSEC root trust anchor embedded in the
unbound-anchor utility. This is used to bootstrap DNSSEC trust for the
unbound DNS server. The current trust anchor is for the 2010 DNSSEC KSK,
which is scheduled to be replaced this year and retired in 2018
(https://www.icann.org/resources/pages/ksk-rollover).
Upstream svn commit r4000 (post-1.6.0), attached for review, updates
unbound-anchor to include the additional trust anchor.
An unbound server that was offline during the KSK rollover can still
obtain the 2017 KSK securely by using unbound-anchor's out-of-band
fallback mechanism based on HTTP and S/MIME, but by including the trust
anchor for the 2017 key in the unbound package that ships with stretch
we can avoid having this rarely used code path exercised.
--
Robert Edmonds
edmo...@debian.org
From eae8248dd18575b06eb4f899bf9485734a1b8cec Mon Sep 17 00:00:00 2001
From: wouter <wouter@be551aaa-1e26-0410-a405-d3ace91eadb9>
Date: Tue, 7 Feb 2017 15:22:31 +
Subject: [PATCH] - Include root trust anchor id 20326 in unbound-anchor.
git-svn-id: http://unbound.nlnetlabs.nl/svn/trunk@4000 be551aaa-1e26-0410-a405-d3ace91eadb9
---
doc/Changelog | 3 +++
smallapp/unbound-anchor.c | 5 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/doc/Changelog b/doc/Changelog
index 6564b8e1..9831607e 100644
--- a/doc/Changelog
+++ b/doc/Changelog
@@ -1,3 +1,6 @@
+7 February 2017: Wouter
+ - Include root trust anchor id 20326 in unbound-anchor.
+
6 February 2017: Wouter
- Fix compile on solaris of the fix to use $host detect.
diff --git a/smallapp/unbound-anchor.c b/smallapp/unbound-anchor.c
index 68ff3ccc..2828088d 100644
--- a/smallapp/unbound-anchor.c
+++ b/smallapp/unbound-anchor.c
@@ -241,7 +241,10 @@ static const char*
get_builtin_ds(void)
{
return
-". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5\n";
+/* anchor 19036 is from 2010 */
+/* anchor 20326 is from 2017 */
+". IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5\n"
+". IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D\n";
}
/** print hex data */
--
2.11.0
signature.asc
Description: PGP signature
Bug#854449: [Pkg-dns-devel] Bug#854449: dns-root-data: New root keys and hint file changes
Christian Hofstaedtler wrote: > Dear Maintainers, > > IANA has published new hint files and new root keys. > It'd be good if those would be updated for stretch. Hi, I've pushed a branch KSK-2017 to the dns-root-data repository that partially(?) addresses this: https://anonscm.debian.org/cgit/pkg-dns/dns-root-data.git/log/?h=KSK-2017 This branch causes the package to ship the two DS records in the root.ds file, but I'm not sure if we should also be shipping two DNSKEY records in the root.key file? (I wasn't able to get unbound-anchor to produce two DNSKEY records.) Also, I updated the hints root.hints file (which also closes #818291). Ondřej, can you review? (All the commits on that branch should be signed with my PGP key.) -- Robert Edmonds edmo...@debian.org signature.asc Description: PGP signature
Bug#853751: [Pkg-dns-devel] Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations
Steven Chamberlain wrote: > Hi, > > This bug has become important, since src:unbound became part of the > build-essential closure (due to Build-Depends of gnutls28). So this is > now a blocking issue for rebootstrapping kfreebsd and hurd. Hi, Steven: Thanks for this patch. Is this needed before stretch releases? (IIUC, kfreebsd and hurd are not release architectures?) > You could perhaps use libbsd unconditionally - on linux arches too - and > then the copy in compat/ would no longer be used. > > There is a long history of software embedding copies of arc4random, and > then forgetting to maintain them. There is a longer discussion of that > here: https://wiki.debian.org/arc4random > > I hold the opinion that packages should use the libbsd implementation > whereever possible, and then in Debian we would only need to maintain it > in one place, to the benefit of all reverse-deps. I agree with this reasoning, but I'd rather have the libbsd support in an upstream Unbound release rather than in the Debian package. I'll see about producing a patch suitable for upstream. -- Robert Edmonds edmo...@debian.org
Bug#852356: ck builds with -sse2 on i386
Adrian Bunk wrote: > On i386 software in Debian must run on machines that have > no SSE (and not even MMX). > > Removing the "-msse -msse2" builds for me. Hi, Adrian: I'm traveling this week and I'll be away from my PGP key. If you have a patch suitable for an NMU please feel free to upload it (no need to go through DELAYED). Otherwise I'll take a look when I get back. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#844147: ck: FTBFS: build timeout
Lucas Nussbaum wrote:
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> The full build log is available from:
>http://aws-logs.debian.net/2016/11/11/ck_0.4.4-1_unstable.log
>
> This failure happens on a CPU with TSX extensions available, but is not
> reproducible on a machine without them. For context, I recommend reading the
> thread starting at https://lists.debian.org/debian-devel/2016/11/msg00210.html
>
> The node used is an Amazon EC2 VM with 64 cores. /proc/cpuinfo says:
>model: 79
>model name : Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz
>stepping : 1
Hi, Lucas:
If I understand the upstream source correctly, TSX support is not
enabled unless --enable-rtm is explicitly passed to the configure
script, which we don't do for the Debian build. According to your build
log, RTM is disabled:
RTM = CK_MD_RTM_DISABLE
So I'm confused as to how TSX support in the build system's CPU could be
the cause. I think your FTBFS might actually be due to #764827 ("ck:
upper bound on cores being used in tests"). It looks like building on
systems with a high number of cores can cause the test suite to take an
unreasonable amount of time, so I've uploaded 0.5.2-2 which limits the
number of cores used to a small value.
Could you retry your build with ck >= 0.5.2-2 once it hits the archive?
Thanks!
--
Robert Edmonds
edmo...@debian.org
Bug#848339: [Pkg-dns-devel] Bug#848339: missing fake_dsa symbol makes reverse dependencies FTBFS
Helmut Grohne wrote:
> It turns out that the fake_dsa symbol (whose name is too generic to be
> used in a shared library imo) is only defined when HAVE_SSL is defined
> (because it works around limitations in openssl >= 1.1). The only
> remaining place that uses it unconditionally is the configuration
> parser. Thus fixing that one, fixes the problem. Please consider
> applying the attached patch. I'd appreciate a timely solution as this
> bug breaks architecture bootstrap qa.
Hi, Helmut:
Just uploaded unbound 1.6.0-2 with your patch. Thanks!
As far as fake_dsa being too generic to be used in a shared library as
an exported symbol name, I agree, but in this case it's an undefined
symbol reference. TTBOMK, the unbound build system only export symbols
appearing in the file libunbound/ubsyms.def, and they all have an
appropriate shared library prefix ("ub_").
--
Robert Edmonds
edmo...@debian.org
Bug#847130: [Pkg-dns-devel] Bug#847130: please add a build profile for building without python
Helmut Grohne wrote: > Hi Robert, > > On Sun, Dec 11, 2016 at 01:35:33PM -0500, Robert Edmonds wrote: > > This patch looks OK to me. Do you want me to apply it to the next > > unbound upload? > > Yes, please. Johannes had a positive reply and it works out pretty well > for me now (i.e. unbound indeed cross builds to all sorts of > architectures). > > Helmut OK, thanks. I will apply the patch to the next upload (either 1.5.10-4 or 1.6.0-1 depending on the upstream release schedule), which should be in the next week or so, in time to make the soft freeze cut-off for stretch. -- Robert Edmonds edmo...@debian.org
Bug#847130: [Pkg-dns-devel] Bug#847130: please add a build profile for building without python
Helmut Grohne wrote: > I ask the readers of d-cross@l.d.o to consider this solution. In case > there are no objections in a reasonable amount of time (e.g. a week), I > ask Robert Edmonds to apply the patch to unbound. In the mean time, I'll > apply in rebootstrap to remove any urgency from this issue. Having it > fixed in stretch would be nice nonetheless. Hi, Helmut: This patch looks OK to me. Do you want me to apply it to the next unbound upload? -- Robert Edmonds edmo...@debian.org
Bug#844608: [Pkg-protobuf-devel] Bug#844608: Looking for sponsor for protobuf NMU
László Böszörményi (GCS) wrote: > Found this, seems to be solvable. But next time I'll do test builds > on several architectures before upload. In the past I've found it easier to upload protobuf to experimental first when testing FTBFS fixes, or just new upstream releases. There's always the risk that something will break on an architecture that you didn't test :-( -- Robert Edmonds edmo...@debian.org
Bug#845941: [Pkg-dns-devel] Bug#845941: unbound FTCBFS: uninstallable python Build-Depends, configures for the build architecture
Helmut Grohne wrote: > Can you apply the attached patch? Hi, Helmut: Applied and uploaded. Thanks again! -- Robert Edmonds edmo...@debian.org
Bug#845518: protobuf-c-compiler cannot be executed during cross compilation
Helmut Grohne wrote: > Package: protobuf-c-compiler > Version: 1.2.1-1 > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > Control: affects -1 + src:collectd src:criu src:dnstap-ldns src:libgadu > src:ocserv src:php-pinba src:riemann-c-client src:unbound > > protobuf-c-compiler is a build tool that is quite similar to flex and > bison in some aspects: You run it during a build and use the resulting C > source code together with a library in your application. When cross > compiling this means that you need a build architecture > protobuf-c-compiler and the corresponding host architecture library. > What currently happens in practise is that you get the host architecture > protofbuf-c-compiler. Thus running it fails. Hi, Helmut: Thanks for the detailed write-up in this bug report. I think I prefer your first solution the best, because if I understand the second solution correctly, it causes the libprotobuf-c-dev package to depend on the package which provides the protobuf-c compiler, and at least in theory the protobuf-c library has some functionality which is usable without the compiler. I will upload a new protobuf-c package with your patch shortly. Some comments on the dependency chain below. > Unfortunately, protobuf-c-compiler is something we need for bringing up > new architectures. The dependency chain is wicked. login is essential > and built from shadow. shadow Build-Depends on libaudit-dev, which is > built from audit. audit Build-Depends on libprelude-dev, which is built > from libprelude. libprelude Build-Depends on libgnutls28-dev, which is > built from gnutls28. Since very recently gnutls28 Build-Depends on > libunbound-dev, which is built from unbound. unbound Build-Depends on > protobuf-c-compiler. See? Wicked. If this were the end of the dependency chain, then OK, we can upload a fixed protobuf-c and that's it. But it's not the end of the chain; protobuf-c build-depends on src:protobuf, and protobuf has a long history of being difficult to get building on all architectures at the same time (for instance, just have a look at the current buildd logs). Should we (Debian) look at how to get protobuf out of the dependency chain for bringing up new architectures? I'm at least partially responsible for this chain. Unbound build-depends on src:protobuf-c because of an optional feature which I turned on in the unbound build (--enable-dnstap) that requires protobuf-c. I also implemented changes in unbound (#828699) that allowed gnutls28 to build-depend on libunbound-dev for DANE support. Both of these are nice features to have and there are at least some users who would be disappointed if they were removed. Looking farther up the chain I see the audit → libprelude-dev build-dependency is due to --with-prelude being enabled in the audit build. Perhaps this feature could be targeted, similarly to #840262? I also wonder if the audisp-prelude plugin [0] could be split from src:audit and built by a separate source package. (It looks like the upstream developers prefer a monolithic repository, though.) [0] https://github.com/linux-audit/audit-userspace/tree/master/audisp/plugins/prelude -- Robert Edmonds edmo...@debian.org
Bug#845378: [Pkg-dns-devel] Bug#845378: unbound: Resolvconf script is not executable
Christoph Pleger wrote: > > The resolvconf update.d hook for unbound is somewhat problematic, so it > > is disabled by default. Enabling or disabling a resolvconf update.d hook > > is done by setting or clearing the executable bit on the hook. > > But when the executable bit is not set and resolvconf is installed, the > user ends up with no usable nameserver configuration after installation of > unbound, because resolv.conf only contains 127.0.0.1 (for the local > unbound) as nameserver entry and without further configuration unbound > does not know how to resolve names. Yes, it does? In the default configuration Unbound performs recursion to resolve names. -- Robert Edmonds edmo...@debian.org
Bug#839960: libzstd: new upstream release 1.1.0, plus pzstd
Source: libzstd Version: 1.0.0-1 Severity: wishlist Hi, It would be nice to have the new 1.1.0 release in the archive (https://github.com/facebook/zstd/releases/tag/v1.1.0), especially if the new 'pzstd' utility (parallel, multi-threaded version of zstd, like pigz for gzip) could be included in the package too. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#839613: O: python-pefile
Package: wnpp Severity: normal
Bug#839611: O: python-pcs
Package: wnpp Severity: normal
Bug#839612: O: python-pypcap
Package: wnpp Severity: normal
Bug#839610: O: ncap
Package: wnpp Severity: normal
Bug#835170: [Pkg-protobuf-devel] Bug#835170: transition: protobuf
Dmitry Smirnov wrote: > On Tuesday, 23 August 2016 8:51:23 PM AEST Adam D. Barratt wrote: > > That's not an excuse for causing disruption in unstable. > > I'm not sure when it is OK to cause disruption in unstable. For example > uploading new GCC seems to cause a lot of problems despite attempts to > mitigate FTBFS. It's a very easy rule for protobuf, since protobuf has a non-trivial set of reverse build-dependencies: every ABI bump for protobuf needs a corresponding, coordinated ABI transition. For previous protobuf transitions (2.5.0, 2.6.0), please review #726165 and #760343. It's not as simple as just uploading a new release to unstable. Probably it should have been uploaded to experimental first, to check that the package would build and pass its test suite on all architectures. (E.g., see #572923 for an example of architecture-specific breakage in protobuf.) > Also do you have a clue why protobuf FTBFS on build servers? I'm unable to > reproduce the problem... I built it on amd64 in an up-to-date sid pbuilder chroot and it failed in the same manner as it did on all the buildd's. -- Robert Edmonds edmo...@debian.org
Bug#834114: libzstd: new upstream version available
Package: libzstd Version: 0.5.1-1 Severity: wishlist Hi! Any chance zstd could be updated to the newest upstream release? I've pasted the NEWS entries since 0.5.1 below. Thanks! v0.8.0 Improved : better speed on clang and gcc -O2, thanks to Eric Biggers New : Build on FreeBSD and DragonFly, thanks to JrMarino Changed : modified API : ZSTD_compressEnd() Fixed : legacy mode with ZSTD_HEAPMODE=0, by Christopher Bergqvist Fixed : premature end of frame when zero-sized raw block, reported by Eric Biggers Fixed : large dictionaries (> 384 KB), reported by Ilona Papava Fixed : checksum correctly checked in single-pass mode Fixed : combined --test amd --rm, reported by Andreas M. Nilsson Modified : minor compression level adaptations Updated : compression format specification to v0.2.0 changed : zstd.h moved to /lib directory v0.7.4 Added : homebrew for Mac, by Daniel Cade Added : more examples Fixed : segfault when using small dictionaries, reported by Felix Handte Modified : default compression level for CLI is now 3 Updated : specification, to v0.1.1 v0.7.3 New : compression format specification New : `--` separator, stating that all following arguments are file names. Suggested by Chip Turner. New : `ZSTD_getDecompressedSize()` New : OpenBSD target, by Juan Francisco Cantero Hurtado New : `examples` directory fixed : dictBuilder using HC levels, reported by Bartosz Taudul fixed : legacy support from ZSTD_decompress_usingDDict(), reported by Felix Handte fixed : multi-blocks decoding with intermediate uncompressed blocks, reported by Greg Slazinski modified : removed "mem.h" and "error_public.h" dependencies from "zstd.h" (experimental section) modified : legacy functions no longer need magic number v0.7.2 fixed : ZSTD_decompressBlock() using multiple consecutive blocks. Reported by Greg Slazinski. fixed : potential segfault on very large files (many gigabytes). Reported by Chip Turner. fixed : CLI displays system error message when destination file cannot be created (#231). Reported by Chip Turner. v0.7.1 fixed : ZBUFF_compressEnd() called multiple times with too small `dst` buffer, reported by Christophe Chevalier fixed : dictBuilder fails if first sample is too small, reported by Руслан Ковалёв fixed : corruption issue, reported by cj modified : checksum enabled by default in command line mode v0.7.0 New : Support for directory compression, using `-r`, thanks to Przemyslaw Skibinski New : Command `--rm`, to remove source file after successful de/compression New : Visual build scripts, by Christophe Chevalier New : Support for Sparse File-systems (do not use space for zero-filled sectors) New : Frame checksum support New : Support pass-through mode (when using `-df`) API : more efficient Dictionary API : `ZSTD_compress_usingCDict()`, `ZSTD_decompress_usingDDict()` API : create dictionary files from custom content, by Giuseppe Ottaviano API : support for custom malloc/free functions New : controllable Dictionary ID New : Support for skippable frames v0.6.1 New : zlib wrapper API, thanks to Przemyslaw Skibinski New : Ability to compile compressor / decompressor separately Changed : new lib directory structure Fixed : Legacy codec v0.5 compatible with dictionary decompression Fixed : Decoder corruption error (#173) Fixed : null-string roundtrip (#176) New : benchmark mode can select directory as input Experimental : midipix support, VMS support v0.6.0 Stronger high compression modes, thanks to Przemyslaw Skibinski API : ZSTD_getFrameParams() provides size of decompressed content New : highest compression modes require `--ultra` command to fully unleash their capacity Fixed : zstd cli return error code > 0 and removes dst file artifact when decompression fails, thanks to Chip Turner -- Robert Edmonds edmo...@debian.org
Bug#833961: wireguard-dkms: kernel module fails to build
Package: wireguard-dkms Version: 0.0.20160808-experimental1 Severity: important Hi! It looks like the kernel module in wireguard-dkms is failing to build on an up-to-date sid system. root@debian:~# apt install wireguard-dkms Reading package lists... Done Building dependency tree Reading state information... Done Recommended packages: wireguard-tools (0.0.20160808-experimental1) The following NEW packages will be installed: wireguard-dkms (0.0.20160808-experimental1) 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 85.5 kB of archives. After this operation, 464 kB of additional disk space will be used. Get:1 http://deb.debian.org/debian experimental/main amd64 wireguard-dkms all 0.0.20160808-experimental1 [85.5 kB] Fetched 85.5 kB in 0s (1,073 kB/s) Selecting previously unselected package wireguard-dkms. (Reading database ... 66002 files and directories currently installed.) Preparing to unpack .../wireguard-dkms_0.0.20160808-experimental1_all.deb ... Unpacking wireguard-dkms (0.0.20160808-experimental1) ... Setting up wireguard-dkms (0.0.20160808-experimental1) ... Loading new wireguard-0.0.20160808 DKMS files... First Installation: checking all kernels... Building only for 4.6.0-1-amd64 Building initial module for 4.6.0-1-amd64 Error! Bad return status for module build on kernel: 4.6.0-1-amd64 (x86_64) Consult /var/lib/dkms/wireguard/0.0.20160808/build/make.log for more information. root@debian:~# cat /var/lib/dkms/wireguard/0.0.20160808/build/make.log DKMS make.log for wireguard-0.0.20160808 for kernel 4.6.0-1-amd64 (x86_64) Wed Aug 10 14:58:42 PDT 2016 make: Entering directory '/usr/src/linux-headers-4.6.0-1-amd64' LD /var/lib/dkms/wireguard/0.0.20160808/build/built-in.o CC [M] /var/lib/dkms/wireguard/0.0.20160808/build/main.o CC [M] /var/lib/dkms/wireguard/0.0.20160808/build/noise.o CC [M] /var/lib/dkms/wireguard/0.0.20160808/build/device.o CC [M] /var/lib/dkms/wireguard/0.0.20160808/build/peer.o CC [M] /var/lib/dkms/wireguard/0.0.20160808/build/timers.o CC [M] /var/lib/dkms/wireguard/0.0.20160808/build/data.o CC [M] /var/lib/dkms/wireguard/0.0.20160808/build/send.o CC [M] /var/lib/dkms/wireguard/0.0.20160808/build/receive.o /var/lib/dkms/wireguard/0.0.20160808/build/data.c:47:30: fatal error: selftest/counter.h: No such file or directory compilation terminated. /usr/src/linux-headers-4.6.0-1-common/scripts/Makefile.build:296: recipe for target '/var/lib/dkms/wireguard/0.0.20160808/build/data.o' failed make[3]: *** [/var/lib/dkms/wireguard/0.0.20160808/build/data.o] Error 1 make[3]: *** Waiting for unfinished jobs /usr/src/linux-headers-4.6.0-1-common/Makefile:1446: recipe for target '_module_/var/lib/dkms/wireguard/0.0.20160808/build' failed make[2]: *** [_module_/var/lib/dkms/wireguard/0.0.20160808/build] Error 2 Makefile:146: recipe for target 'sub-make' failed make[1]: *** [sub-make] Error 2 Makefile:8: recipe for target 'all' failed make: *** [all] Error 2 make: Leaving directory '/usr/src/linux-headers-4.6.0-1-amd64' root@debian:~# -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wireguard-dkms depends on: ii dkms 2.2.0.3-5 Versions of packages wireguard-dkms recommends: pn wireguard-tools wireguard-dkms suggests no packages. -- no debconf information -- Robert Edmonds edmo...@debian.org
Bug#828177: jessie-pu: package unbound/1.4.22-3+deb8u2
Adam D. Barratt wrote: > On Mon, 2016-07-04 at 16:11 -0400, Robert Edmonds wrote: > > +unbound (1.4.22-3+deb8u2) jessie; urgency=medium > > + > > + * debian/unbound.init: Add "pidfile" magic comment (Closes: #807132) > > + * debian/unbound.init: Call start-stop-daemon with --retry for 'stop' > > +action (patch from Julien Cristau) > > Sorry for the delay in getting back to you; please go ahead. Uploaded. Thanks! -- Robert Edmonds edmo...@debian.org
Bug#832394: Broken $PATH is propagated to hook scripts
Package: resolvconf
Version: 1.79
Severity: important
The /sbin/resolvconf script resets the PATH environment variable to
"/sbin:/bin" before running update scripts. This breaks at least the
postfix package's update-libc.d script:
==> /etc/resolvconf/update-libc.d/postfix <==
#!/bin/sh -e
# we only need to copy this in if the service is already running.
# if it's not running, it'll get picked up by the init script on start.
service postfix status >/dev/null 2>&1 || exit 0
QUEUEDIR="$(/usr/sbin/postconf -h queue_directory 2>/dev/null || true)"
if [ -n "$QUEUEDIR" ]; then
cp /etc/resolv.conf ${QUEUEDIR}/etc/resolv.conf
service postfix reload >/dev/null 2>&1 || exit 0
fi
exit 0
The 'service' command is located in /usr/sbin, so it isn't found when
the update-libc.d script runs under resolvconf. The script silently
exits instead without executing its update of the postfix chroot's copy
of /etc/resolv.conf.
On an up-to-date sid system with unbound 1.5.9-1, postfix 3.1.0-4, and
resolvconf 1.79, I get the following resolv.conf file contents after
booting the system:
root@unbound:~# head - /etc/resolv.conf
/var/spool/postfix/etc/resolv.conf
==> /etc/resolv.conf <==
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
==> /var/spool/postfix/etc/resolv.conf <==
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
root@unbound:~#
--
Robert Edmonds
edmo...@debian.org
Bug#826241: [Pkg-dns-devel] Bug#826241: Bug#826241: Bug#826241: Bug#826241: Bug#826241: unbound: Provide $named facility under systemd
Michael Biebl wrote: > Am 09.07.2016 um 23:36 schrieb Robert Edmonds: > > But it looks like “systemctl restart unbound“ takes 90 seconds to > > complete, though it eventually exits with return code 0. When “systemctl > > restart unbound“ is running, I see the following initially printed to > > the journal: > > .. > > > I'm not quite sure what the issue is. Any ideas? This is on an > > up-to-date stretch VM, with these unbound packages installed: > > > > https://people.debian.org/~edmonds/build/unbound/1.5.9-2/ > > > > along with resolvconf and postfix from testing. > > > I did test those packages on a clean, up-to-date stretch system, where I ran > apt install unbound resolvconf postfix > reboot > > systemctl restart unbound > > That worked just fine without delay. Hi, Michael: It appears postfix introduced native systemd unit files in version 3.1.0-3.1, which migrated to testing a day before your email, and a few days after mine. So you must have been testing postfix with the new unit files, and I was testing postfix with the old sysvinit scripts. So we were both testing on up-to-date stretch systems :-) > So I'm unable to reproduce the problem and from my POV the packages > would be good to go. OK, I'll try it again. I installed a fresh stretch VM from scratch. I have these packages installed: * unreleased unbound (from p.d.o/~edmonds/build/unbound/1.5.9-2/) * postfix 3.1.0-3.1 * resolvconf 1.79 I do see “systemctl restart unbound” returning instantly now, and unbound-resolvconf.service is running and causing /etc/resolv.conf to be updated. However, it looks like the copy of resolv.conf inside postfix's chroot *is not being updated*, which appears to be the whole point of postfix's resolvconf hook. If that doesn't happen, then postfix won't have working name resolution(!). Here is with a freshly booted system: root@unbound:~# stat '--format=%n: %y' /etc/resolvconf/run/resolv.conf /var/spool/postfix/etc/resolv.conf /etc/resolvconf/run/resolv.conf: 2016-07-16 17:35:53.37200 + /var/spool/postfix/etc/resolv.conf: 2016-07-16 17:35:52.98400 + root@unbound:~# head -999 /etc/resolv.conf /var/spool/postfix/etc/resolv.conf ==> /etc/resolv.conf <== # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search hsd1.ga.comcast.net ==> /var/spool/postfix/etc/resolv.conf <== # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN root@unbound:~# It looks like postfix is starting early enough that it copies resolv.conf into its chroot before resolv.conf has usable content, and then when resolvconf does get updated, the postfix resolvconf hook either isn't being invoked, or is being invoked but is not successfully performing the copy. Manually restarting unbound also doesn't cause postfix's copy of resolv.conf to be updated: root@unbound:~# systemctl restart unbound root@unbound:~# stat '--format=%n: %y' /etc/resolvconf/run/resolv.conf /var/spool/postfix/etc/resolv.conf /etc/resolvconf/run/resolv.conf: 2016-07-16 17:38:51.287627372 + /var/spool/postfix/etc/resolv.conf: 2016-07-16 17:35:52.98400 + root@unbound:~# head -999 /etc/resolv.conf /var/spool/postfix/etc/resolv.conf ==> /etc/resolv.conf <== # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search hsd1.ga.comcast.net ==> /var/spool/postfix/etc/resolv.conf <== # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN root@unbound:~# When I run the postfix resolvconf hook by hand, it does cause the postfix chroot's resolv.conf to be updated: root@unbound:~# head -999 /etc/resolv.conf /var/spool/postfix/etc/resolv.conf ==> /etc/resolv.conf <== # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search hsd1.ga.comcast.net ==> /var/spool/postfix/etc/resolv.conf <== # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN root@unbound:~# sh -x /etc/resolvconf/update-libc.d/postfix + service postfix status + /usr/sbin/postconf -h queue_directory + QUEUEDIR=/var/spool/postfix + [ -n /var/spool/postfix ] + cp /etc/resolv.conf /var/spool/postfix/etc/resolv.c
Bug#826241: [Pkg-dns-devel] Bug#826241: Bug#826241: Bug#826241: Bug#826241: unbound: Provide $named facility under systemd
Michael Biebl wrote: > Am 05.07.2016 um 01:36 schrieb Robert Edmonds: > > I tested this (actually your later version with the typo fix), but it > > seems unbound-resolvconf.service starts, but then immediately stops: > > .. > > > Do we need to set “RemainAfterExit=yes” in unbound-resolvconf.service? > > RemainAfterExit=yes is typically used for Type=oneshot services. But in > this specific case, where we use Type=simple deliberately even though we > don't start a long running process, RemainAfterExit=yes seems like the > correct fix. Hi, Michael: This almost works. I have “systemctl stop unbound“ and “systemctl start unbound“ working correctly with unbound, resolvconf, and postfix installed. But it looks like “systemctl restart unbound“ takes 90 seconds to complete, though it eventually exits with return code 0. When “systemctl restart unbound“ is running, I see the following initially printed to the journal: Jul 09 21:25:08 debian systemd[1]: Stopping Unbound DNS server via resolvconf... Jul 09 21:25:08 debian systemd[1]: Stopped target Host and Network Name Lookups. Jul 09 21:25:08 debian systemd[1]: Stopping Host and Network Name Lookups. “systemctl list-jobs“ shows the following, with job 228 highlighted: JOB UNIT TYPESTATE 227 nss-lookup.target start waiting 228 unbound-resolvconf.service restart running 166 unbound.servicerestart waiting 229 postfix.servicereload waiting 4 jobs listed. and I see this familiar group of processes in the process tree: [...] /bin/sh -e /usr/lib/unbound/package-helper resolvconf_stop [...] \_ run-parts --arg=-d --arg=lo.unbound /etc/resolvconf/update.d [...] \_ run-parts /etc/resolvconf/update-libc.d [...] \_ /bin/sh -e /etc/resolvconf/update-libc.d/postfix [...] \_ /bin/sh -e /etc/init.d/postfix reload [...] \_ /bin/systemctl --no-pager reload postfix.service Then, about 90 seconds after “systemctl restart unbound“ is executed, the following is written to the journal: Jul 09 21:26:38 debian systemd[1]: unbound-resolvconf.service: Stopping timed out. Terminating. Jul 09 21:26:38 debian systemd[1]: Stopped Unbound DNS server via resolvconf. Jul 09 21:26:38 debian systemd[1]: unbound-resolvconf.service: Unit entered failed state. Jul 09 21:26:38 debian systemd[1]: unbound-resolvconf.service: Failed with result 'timeout'. Jul 09 21:26:38 debian unbound[1631]: [1631:0] info: service stopped (unbound 1.5.9). Jul 09 21:26:38 debian unbound[1631]: [1631:0] info: server stats for thread 0: 2 queries, 0 answers from cache, 2 recursions, 0 prefetch Jul 09 21:26:38 debian unbound[1631]: [1631:0] info: server stats for thread 0: requestlist max 2 avg 1 exceeded 0 jostled 0 Jul 09 21:26:38 debian unbound[1631]: [1631:0] info: average recursion processing time 2.150202 sec Jul 09 21:26:38 debian unbound[1631]: [1631:0] info: histogram of recursion processing times Jul 09 21:26:38 debian unbound[1631]: [1631:0] info: [25%]=0 median[50%]=0 [75%]=0 Jul 09 21:26:38 debian unbound[1631]: [1631:0] info: lower(secs) upper(secs) recursions Jul 09 21:26:38 debian unbound[1631]: [1631:0] info:1.002.00 1 Jul 09 21:26:38 debian unbound[1631]: [1631:0] info:2.004.00 1 Jul 09 21:26:38 debian systemd[1]: Stopping Unbound DNS server... Jul 09 21:26:38 debian systemd[1]: Stopped Unbound DNS server. Jul 09 21:26:38 debian systemd[1]: Starting Unbound DNS server... Jul 09 21:26:38 debian package-helper[1897]: /var/lib/unbound/root.key has content Jul 09 21:26:38 debian package-helper[1897]: success: the anchor is ok Jul 09 21:26:38 debian systemd[1]: Started Unbound DNS server. Jul 09 21:26:38 debian systemd[1]: Started Unbound DNS server via resolvconf. Jul 09 21:26:38 debian systemd[1]: Reached target Host and Network Name Lookups. Jul 09 21:26:38 debian systemd[1]: Reloading LSB: Postfix Mail Transport Agent. Jul 09 21:26:38 debian unbound[1909]: [1909:0] notice: init module 0: validator Jul 09 21:26:38 debian unbound[1909]: [1909:0] notice: init module 1: iterator Jul 09 21:26:38 debian unbound[1909]: [1909:0] info: start of service (unbound 1.5.9). Jul 09 21:26:38 debian postfix[1917]: Postfix is running with backwards-compatible default settings Jul 09 21:26:38 debian postfix[1917]: See http://www.postfix.org/COMPATIBILITY_README.html for details Jul 09 21:26:38 debian postfix[1917]: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload" Jul 09 21:26:38 debian postfix/master[1783]: reload -- version 3.1.0, configuration /etc/postfix Jul 09 21:26:38 debian postfix[1911]: Reloading Postfix configuration...done. Jul 09 21:26:38 debian systemd[1]: Reloaded LSB: Postfix Mail Transport Agent. Jul 09 21:26:38 debian systemd[1]: Reloading LSB: Postfix Mail Transport Agent. Jul 09 21:26:38 debian postfix[1972]: P
Bug#826241: [Pkg-dns-devel] Bug#826241: Bug#826241: Bug#826241: unbound: Provide $named facility under systemd
Michael Biebl wrote: > Ok, I guess I have the missing ingredient now. We need to make the > unbound-resolvconf.service unit use Type=simple not oneshot. > oneshot blocks until the started process has completed, with Type=simple > we don't block. Hi, Michael: I tested this (actually your later version with the typo fix), but it seems unbound-resolvconf.service starts, but then immediately stops: ● unbound-resolvconf.service - Unbound DNS server via resolvconf Loaded: loaded (/lib/systemd/system/unbound-resolvconf.service; enabled; vendor preset: enabled) Active: inactive (dead) since Mon 2016-07-04 23:27:10 UTC; 10s ago Process: 1416 ExecStop=/usr/lib/unbound/package-helper resolvconf_stop (code=exited, status=0/SUCCESS) Process: 1387 ExecStart=/usr/lib/unbound/package-helper resolvconf_start (code=exited, status=0/SUCCESS) Main PID: 1387 (code=exited, status=0/SUCCESS) Jul 04 23:27:10 debian systemd[1]: Started Unbound DNS server via resolvconf. Jul 04 23:27:10 debian package-helper[1387]: executing resolvconf_start Jul 04 23:27:10 debian package-helper[1416]: executing resolvconf_stop (I inserted an echo at the top of the package-helper script just to verify.) This is not what we need, because the local Unbound gets added to /etc/resolv.conf (when ExecStart runs) and then immediately removed a split second later (when ExecStop runs). Do we need to set “RemainAfterExit=yes” in unbound-resolvconf.service? Thanks! -- Robert Edmonds edmo...@debian.org
Bug#818370: [Pkg-dns-devel] Bug#818370: Fails to bind ports but suggests it started
martin f krafft wrote: > also sprach martin f krafft <madd...@debian.org> [2016-03-16 15:05 +0100]: > > I have no idea why it failed to bind the port on ::1. Nothing else > > has this port bound. > > The loopback interface was not up. I can replicate this bug with unbound 1.5.8-1, but not with 1.5.9-1. It looks like it was fixed by: * debian/unbound.init: Add "pidfile" magic comment (Closes: #807132) This is with 1.5.9-1: root@debian:~# systemctl stop unbound.service root@debian:~# systemctl status unbound.service ● unbound.service Loaded: loaded (/etc/init.d/unbound; generated; vendor preset: enabled) Drop-In: /run/systemd/generator/unbound.service.d └─50-insserv.conf-$named.conf, 50-unbound-$named.conf Active: inactive (dead) since Mon 2016-07-04 22:47:42 UTC; 1s ago Docs: man:systemd-sysv-generator(8) Process: 2650 ExecStop=/etc/init.d/unbound stop (code=exited, status=0/SUCCESS) Process: 2535 ExecStart=/etc/init.d/unbound start (code=exited, status=0/SUCCESS) Main PID: 2547 (code=exited, status=0/SUCCESS) Jul 04 22:47:03 debian unbound[2547]: [2547:0] notice: init module 1: iterator Jul 04 22:47:03 debian unbound[2547]: [2547:0] info: start of service (unbound 1.5.9). Jul 04 22:47:03 debian unbound[2535]: Starting DNS server: unbound. Jul 04 22:47:03 debian systemd[1]: Started unbound.service. Jul 04 22:47:42 debian systemd[1]: Stopping unbound.service... Jul 04 22:47:42 debian unbound[2547]: [2547:0] info: service stopped (unbound 1.5.9). Jul 04 22:47:42 debian unbound[2547]: [2547:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions,...refetch Jul 04 22:47:42 debian unbound[2547]: [2547:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 Jul 04 22:47:42 debian unbound[2650]: Stopping DNS server: unbound. Jul 04 22:47:42 debian systemd[1]: Stopped unbound.service. Hint: Some lines were ellipsized, use -l to show in full. root@debian:~# ifdown lo root@debian:~# systemctl start unbound.service Job for unbound.service failed because of unavailable resources or another system error. See "systemctl status unbound.service" and "journalctl -xe" for details. root@debian:~# systemctl status -l unbound.service ● unbound.service Loaded: loaded (/etc/init.d/unbound; generated; vendor preset: enabled) Drop-In: /run/systemd/generator/unbound.service.d └─50-insserv.conf-$named.conf, 50-unbound-$named.conf Active: failed (Result: resources) since Mon 2016-07-04 22:47:56 UTC; 24s ago Docs: man:systemd-sysv-generator(8) Process: 2650 ExecStop=/etc/init.d/unbound stop (code=exited, status=0/SUCCESS) Process: 2692 ExecStart=/etc/init.d/unbound start (code=exited, status=0/SUCCESS) Main PID: 2547 (code=exited, status=0/SUCCESS) Jul 04 22:47:55 debian systemd[1]: Starting unbound.service... Jul 04 22:47:56 debian unbound-anchor[2699]: /var/lib/unbound/root.key has content Jul 04 22:47:56 debian unbound-anchor[2699]: success: the anchor is ok Jul 04 22:47:56 debian unbound[2692]: Starting DNS server: unbound[1467672476] unbound[2703:0] error: can't bind socket: Cannot assign requested address for ::1 Jul 04 22:47:56 debian unbound[2692]: [1467672476] unbound[2703:0] fatal error: could not open ports Jul 04 22:47:56 debian unbound[2692]: failed! Jul 04 22:47:56 debian systemd[1]: unbound.service: PID file /run/unbound.pid not readable (yet?) after start: No such file or directory Jul 04 22:47:56 debian systemd[1]: Failed to start unbound.service. Jul 04 22:47:56 debian systemd[1]: unbound.service: Unit entered failed state. Jul 04 22:47:56 debian systemd[1]: unbound.service: Failed with result 'resources'. root@debian:~# -- Robert Edmonds edmo...@debian.org
Bug#828699: [Pkg-dns-devel] Bug#828699: libunbound2: please compile against libnettle
brian m. carlson wrote: > Currently, GnuTLS cannot be compiled with DANE support as that would > require linking against libunbound2; that is unsuitable since > libunbound2 links against OpenSSL. As of unbound 1.5.7, compiling > against libnettle is supported for libunbound2. Doing so would allow > GnuTLS (and other GPL-licensed software) to make use of libunbound2. > Could you please do so? Hi, brian: It turns out libunbound won't build against the version of nettle in testing/unstable. I've submitted a fix upstream: https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=788 I'll wait to hear back from upstream before patching it in Debian. -- Robert Edmonds edmo...@debian.org
Bug#518002: [Pkg-dns-devel] Bug#518002: Add apparmor profile for unbound
Nicolas Braud-Santoni wrote: > On Mon, Feb 22, 2016 at 11:08:30AM -0500, Simon Deziel wrote: > > > Note that Simon and Nicolas have refreshed this profile recently: > > > https://code.launchpad.net/~sdeziel/apparmor-profiles/refresh-unbound/+merge/268924 > > > > It was further refreshed for unbound 1.5.7: > > https://bazaar.launchpad.net/~apparmor-dev/apparmor-profiles/master/view/head:/ubuntu/16.04/usr.sbin.unbound > > It was again touched up very recently. > > I tested the last revision (168.1.1) on Debian sid, > and did not encounter any issues. > > It is, however, missing the usual local/usr.sbin.haveged include. > I will send a patch back upstream. > > In any case, it seems reasonable to add the profile (with the local > include) now. > > > Sorry this bug somewhat fell to the wayside, but I would rather > see this added now rather than never ;) > > > Best, > > nicoo Hi, nicoo: I'd be happy to ship an apparmor profile for unbound in the Debian package. Can you please send a patch that applies to the master branch of the packaging repository? https://anonscm.debian.org/cgit/pkg-dns/unbound.git/ -- Robert Edmonds edmo...@debian.org
Bug#828177: jessie-pu: package unbound/1.4.22-3+deb8u2
Robert Edmonds wrote: > Julien Cristau wrote: > > May I take the opportunity to ask you to also fix the 'stop' action from > > the init script? > > > > We've been using this patch on the debian.org hosts for a year now. > > Previously restarting the service would quite often result in no running > > unbound, because (AIUI) systemd doesn't use the init script 'restart' > > action (uses stop && start instead), the 'stop' action would not wait > > for the process to actually die before returning, and then 'start' would > > say "I'm already running, nothing to do". > > Wow, thanks for pointing that out. Yes, I'd be happy to fix that one too > in a stable update. Here is the updated debdiff for the package I'd like to upload to jessie. diff -Nru unbound-1.4.22/debian/changelog unbound-1.4.22/debian/changelog --- unbound-1.4.22/debian/changelog 2016-02-21 18:43:22.0 -0500 +++ unbound-1.4.22/debian/changelog 2016-07-04 15:58:35.0 -0400 @@ -1,3 +1,11 @@ +unbound (1.4.22-3+deb8u2) jessie; urgency=medium + + * debian/unbound.init: Add "pidfile" magic comment (Closes: #807132) + * debian/unbound.init: Call start-stop-daemon with --retry for 'stop' +action (patch from Julien Cristau) + + -- Robert Edmonds <edmo...@debian.org> Mon, 04 Jul 2016 15:58:01 -0400 + unbound (1.4.22-3+deb8u1) jessie; urgency=medium * iterator/iter_hints.c: Update hints for H.ROOT-SERVERS.NET diff -Nru unbound-1.4.22/debian/patches/debian-changes unbound-1.4.22/debian/patches/debian-changes --- unbound-1.4.22/debian/patches/debian-changes2016-02-22 10:58:04.0 -0500 +++ unbound-1.4.22/debian/patches/debian-changes2016-07-04 16:06:41.0 -0400 @@ -5,12 +5,13 @@ information below has been extracted from the changelog. Adjust it or drop it. . - unbound (1.4.22-3+deb8u1) jessie; urgency=medium + unbound (1.4.22-3+deb8u2) jessie; urgency=medium . - * iterator/iter_hints.c: Update hints for H.ROOT-SERVERS.NET - (Closes: #815370) + * debian/unbound.init: Add "pidfile" magic comment (Closes: #807132) + * debian/unbound.init: Call start-stop-daemon with --retry for 'stop' + action (patch from Julien Cristau) Author: Robert Edmonds <edmo...@debian.org> -Bug-Debian: https://bugs.debian.org/815370 +Bug-Debian: https://bugs.debian.org/807132 --- The information above should follow the Patch Tagging Guidelines, please @@ -23,7 +24,7 @@ Bug-Ubuntu: https://launchpad.net/bugs/ Forwarded: <no|not-needed|url proving that it has been forwarded> Reviewed-By: -Last-Update: +Last-Update: 2016-07-04 --- unbound-1.4.22.orig/acx_python.m4 +++ unbound-1.4.22/acx_python.m4 diff -Nru unbound-1.4.22/debian/unbound.init unbound-1.4.22/debian/unbound.init --- unbound-1.4.22/debian/unbound.init 2016-02-21 18:43:22.0 -0500 +++ unbound-1.4.22/debian/unbound.init 2016-07-04 15:58:35.0 -0400 @@ -7,6 +7,7 @@ # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 ### END INIT INFO +# pidfile: /run/unbound.pid NAME=unbound DESC="recursive DNS server" @@ -121,7 +122,7 @@ stop) if $UNBOUND_ENABLE; then log_daemon_msg "Stopping $DESC" "$NAME" -if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --name $NAME; then +if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --name $NAME --retry 5; then do_resolvconf_stop log_end_msg 0 else -- Robert Edmonds edmo...@debian.org
Bug#829366: doesn't allow for creation of keys with 90-year expiry
Luke Faraone wrote: > Creating a key that expires in 89 years correctly sets an expiry of 2105, but > attempting to set an expiry of 90 years or greater results in an expirty date > that wraps around to 1970. > > Curiously, the time on such wrapped-around expiries is always 13:09:41. This is the Y2106 problem: representing a timestamp using an *unsigned* 32-bit integer number of seconds since the Unix epoch only allows representing ~136 years since 1970. If you use a *signed* 32-bit integer you get the more famous Y2038 problem. There are other instances of the Y2106 bug in the archive, e.g. BIND's struct isc_time also represents seconds since the epoch with an unsigned int. -- Robert Edmonds edmo...@debian.org
Bug#828177: jessie-pu: package unbound/1.4.22-3+deb8u2
Julien Cristau wrote: > May I take the opportunity to ask you to also fix the 'stop' action from > the init script? > > We've been using this patch on the debian.org hosts for a year now. > Previously restarting the service would quite often result in no running > unbound, because (AIUI) systemd doesn't use the init script 'restart' > action (uses stop && start instead), the 'stop' action would not wait > for the process to actually die before returning, and then 'start' would > say "I'm already running, nothing to do". Wow, thanks for pointing that out. Yes, I'd be happy to fix that one too in a stable update. > --- /tmp/unbound-1.4.22/debian/unbound.init 2016-02-22 01:43:22.0 > +0200 > +++ modules/unbound/files/unbound.init 2015-05-17 16:50:09.699383800 +0200 > @@ -121,7 +121,7 @@ > stop) > if $UNBOUND_ENABLE; then > log_daemon_msg "Stopping $DESC" "$NAME" > -if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE > --name $NAME; then > +if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE > --name $NAME --retry 5; then > do_resolvconf_stop > log_end_msg 0 > else > > Cheers, > Julien -- Robert Edmonds edmo...@debian.org
