Bug#1072644: new upstream (3.8.4)
Package: rspamd Hi, rspamd 3.8.4 has been released back in February - it would be nice if you could update the package in Debian. Regards, Daniel
Bug#1068953: new upstream (10.0)
On 5/2/24 10:30, David Lamparter wrote: I've managed to get sbuild crosscompile to work for hppa and found the problem (it's a missing "XREF_SETUP()" line, not that the error message would give any hint to that...) yay! I'll put a -2 together later today. nice, feel free to ping me when done to sponsor it. Regards, Daniel
Bug#1068953: new upstream (10.0)
On 4/30/24 12:56, David Lamparter wrote: Ok, for the time being I've instead decided to use this as a kick in my ass to finally do the NM procedure to become a Debian Maintainer... https://nm.debian.org/process/1284/ hehe, nice ;) I have no idea what kind of timescale that works on, but I probably can't get to hppa debugging right off anyway can take from anywhere between a few days and a couple of months, depending on the availability of $people and you providing/fulfilling the requirements. worst case I'd ping you later? anytime, sure. Regards, Daniel
Bug#1067077: frr: FTBFS on armel: /usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to `__atomic_store_8'
Hi David, On 4/30/24 18:21, David Lamparter wrote: flipped libatomic to be linked unconditionally. it's not harmful to do so on architectures that don't need it, but imho its cleaner to only be linked on affected architectures (armel m68k powerpc sh4). https://github.com/FRRouting/frr/commits/debian/master/ nice, thanks! Do you want to do anything else with it or should I go mark it as -1? my last attempt from yesterday didn't work (after a long time it took to build on the armel porterbox), so -1 looks good like that. Regards, Daniel
Bug#1068951: new upstream (6.x)
Hi, On 4/30/24 18:12, Jakub Ružička wrote: Secondary reason for that was that there is no upgrade path from 5.x to 6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6. For that, the package probably needs a different name (like knot-resolver6) imho this should be handled in the package (e.g. by showing a debconf note or so) and be included in the trixie release notes. renaming the binary package doesn't really solve much and is more suited for (library) transitions, i.e. if there were several knot-resolver-module-* packages or so. also (I haven't looked at it), is it worthwile to (with users consent) to "try" to guess with (some parts of) the old config to generate the new config from? So what do you suggest? generally, the amount of binary packages should be limited to a minimum - oiow there needs to be a reason why an additional binary package is added. some of them are: * saving relative excessive amount of diskspace (e.g. large documentation can be split into a -doc package) * different parts have different dependencies and/or particulary long dependency chains (e.g. gtk parts of a cli tool) therefore, imho the following binary packages make sense here: * knot-resolver * knot-resolver-doc * knot-resolver-module-dnstap * knot-resolver-module-http Note that -dbg packages are generated automatically and don't need to be specified in control (I'll provide a commit for that). Regards, Daniel
Bug#1068951: new upstream (6.x)
On 4/29/24 19:50, Daniel Baumann wrote: pushing to the repo requires me to be added to the salsa project.. would you mind adding me? in the meantime, I've pushed to here: https://git.progress-linux.org/users/daniel.baumann/debian/todo/knot-resolver/log/ before I'll continue: what's the idea of adding knot-resolver-manager binary package? I can't think of a reason why one would use kresd (knot-resolver-core) without the manager, and thus, would fold knot-resolver-manager and knot-resolver-core (back) into knot-resolver. But probably I'm missing something.. Regards, Daniel
Bug#1068951: new upstream (6.x)
On 4/23/24 14:45, Jakub Ružička wrote: Awesome, I've forwarded your words of praise to the hard-working Knot Resolver team :) (jftr: we switched in 2015 from cisco ncr to unbound, and in 2016 from unbound to knot-resolver.. and are super happy ever since) I'm actually quite interested in (the nightmares of) python packaging hehe :) Cool, I've already mental-marked you as a person I'm gonna bother with reviewing my v6 changes even before your willing reply :) no problem, looking forward to it :) IOW ~/src/knot-resolver/distro/pkg/deb and ~/debian/knot-resolver/debian should be as close as possible. +1 Feel free to push your changes (if any) to debian/experimental or use your branch as you prefer, I'm always eager to learn how other DDs do things. pushing to the repo requires me to be added to the salsa project.. would you mind adding me? Regards, Daniel
Bug#1068953: new upstream (10.0)
On 4/29/24 18:31, David Lamparter wrote: Did you run into issues that forced you up to 2.1.148? The "officially listed" (= in configure.ac) requirement is 2.1.128, if we(upstream) missed something I'd look into getting that listed minimum bumped up too. Rechecking the frr 10 announcement.. says indeed 2.1.128 not 2.1.148. totally my fault, I'm very sorry about that! (I'm running frr 10 with 2.1.148 here since some days now with no issues though) Is there some way to debug this? You can ask for (hppa) porterbox access; accounts to porterboxes are given to non-DD/DMs too: https://dsa.debian.org/doc/guest-account/ If you send me the data requested there, I'll sign it so you can get access. Regards, Daniel
Bug#1068953: new upstream (10.0)
Hi David, On 4/29/24 16:56, David Lamparter wrote: I can't do uploads myself (not a DM/DD) no problem - I'm happy to sponsor your uploads if you want me to ;) FRR definitely requires libyang 2.1.128. hm, frr 10 needs libyang2 2.1.148. which, as you noted, is already uploaded so for now - situation is fine. I really need to merge master back into the debian branches on the FRR repo to pick that up, I can probably get to that today or tomorrow. that would be nice; and again, happy to help/to sponsor any uploads. There's also a bit of a problem in #1067077 I've fixed that already, just waiting some more minutes on the build to finish on the armel porterbox. Regards, Daniel
Bug#1067077: frr: FTBFS on armel: /usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to `__atomic_store_8'
tag 1067077 +pending thanks Hi, my initial attempt in 10.0-0.2 to link with libatomic didn't work, I've fixed that locally but a build to confirming on an armel porterbox is runnning before uploading 10.0-0.3 in some minutes.. Regards, Daniel
Bug#1069995: VCSWatch: underlaying system doesn't support TLS1.3
Package: qa.debian.org Severity: wishlist Hi, I've switched off TLS1.2 on my git server (to see what would be brocken), one of them is VCSWatch: Error: fatal: unable to access 'https://git.progress-linux.org/users/daniel.baumann/debian/packages/aio-eapi/': gnutls_handshake() failed: Error in protocol version It would be nice if the qa.debian.org system (I assume) could be updated to bullseye or newer which supports TLS1.3. Regards, Daniel
Bug#1068951: new upstream (6.x)
Hi, On 4/23/24 13:58, Jakub Ružička wrote: but we've agreed the time has come to get extra testing & feedback through Debian experimental. yay, thanks! [ we use knot-resolver at work for the central resolvers for the university, and we love it. kresd 6 offers some nice improvements for us, so looking forward testing it (via local bookworm-backports we maintain) ] The only blocker for that is missing python3-json-schema-for-humans needed for docs build which I intend to package later - for now I guess I'll just disable the docs build. (just as an offer) I'll maintain a bunch of python modules already and don't mind another, so I can upload that later today if this is any help. I'm hitting boundaries of my Debian knowledge so it's slow. I'm happy to help if you want. For example, upstream package uses meson directly and builds in meson_deb dir, but debian package uses debhelper with obj-x86_64-linux-gnu dir and I don't know howto properly reference it from d/rules without relying on shady strings. I didn't find a branch on the salsa repo, where would I find the current 6.x state to send patches against? Regards, Daniel
Bug#1067025: dokuwiki: Please package the new upstream version 2024-02-06a "Kaos"
Hi, any news or ETA on this? do you need help? Regards, Daniel
Bug#1069072: new upstream (0.36)
Package: nwipe Hi, it would be nice if you could upload the current nwipe release to Debian. Regards, Daniel
Bug#1068957: ITP: gnome-shell-extension-vertical-workspaces -- A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically st
Hi Tobias, On 4/14/24 13:55, Tobias Frost wrote: As I have the package ready, I'd like to propose to maintain it as new package In January 2023 I've uploaded gnome-shell-extension-vertical-workspaces (and 5 other extensions) as individual source packages as every other gnome-shell extension is packaged in Debian. ftp-master rejected all of them and insisted, that I create an artifical package (one src producing one binary) containing all 6 extensions together. This is how gnome-shell-extension-vertical-workspaces is included in bookworm and anything newer. You can read more about this in #1030683. I don't think ftp-master has changed their opinion. If they did, I'm happy to break it up and re-upload the extensions as individual packages again like I did in the first place in January 2023. ftp-master/Thorsten: What is your current opinion, can I upload the extensions as individual extensions again, or do we have to keep the aggregation package? Regards, Daniel
Bug#1068957: ITP: gnome-shell-extension-vertical-workspaces -- A GNOME Shell extension that lets you customize your GNOME Shell UX to suit your workflow, whether you like horizontally or vertically st
Hi Tobias, On 4/14/24 10:14, Tobias Frost wrote: * Package name: gnome-shell-extension-vertical-workspaces this is already included in src:gnome-shell-extensions-extra. Regards, Daniel
Bug#1062068: nvme-cli package fails to download firmware file for nvme
close 1062068 thanks Hi Anubhav, thank you for your report. Unfortunately you're using a very old version of nvme-cli that can not be expected to work with recent firmware files. Please upgrade nvme-cli to a more recent version (at last the one in stable). Regards, Daniel
Bug#1064390: mdadm: new upstream version 4.3 available
close 1064390 4.3-1 thanks Hi Graham, thanks - I've just uploaded 4.3. Regards, Daniel
Bug#1042906: ansible: please package new upstream version 8.x
retitle 1042906 please package new upstream version 9.x thanks Hi Lee, any updates since last year? Ansible is currently at 9.x and I'd really like to be able to use a recent enough version of ansible via debian packages. Is there anything I could help you with? Regards, Daniel
Bug#1068955: incompatible with inkscape 1.3
Package: inkscape-open-symbols Severity: wishlist Hi, thank you for maintaining inkscape-open-symbols. As inkscape-open-symbols 1.2 is incompatible with inkscape 1.3 in experimental, it would be nice if you could upload a newer version of inkscape-open-symbols to experimental too. Regards, Daniel
Bug#1068954: bookworm-pu: package libnvme/1.3-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Hi,
when scanning ("nvme list") some buggy NVMe ssds that don't like blocks
of less than 4096 bytes send to them, a buffer overflow happens.
Upstream fixed this in libnvme 1.7, I've cherry-picked this for
bookworm, attached is the full diff for review. Please let me know if I
can upload it to bookworm-pu.
Regards,
Danieldiff --git a/debian/changelog b/debian/changelog
index 2666b0a..d7cef38 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+libnvme (1.3-1+deb12u1) bookworm; urgency=medium
+
+ * Uploading to bookworm.
+ * Cherry-picking upstream commits to fix buffer overflow during scanning
+devices that do not support sub-4k reads (Closes: #1054631).
+
+ -- Daniel Baumann Sun, 14 Apr 2024 08:57:21 +0200
+
libnvme (1.3-1) sid; urgency=medium
* Uploading to sid.
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..f31922e
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1,2 @@
+upstream/0001-alloc-helper.patch
+upstream/0002-aligned-payloads.patch
diff --git a/debian/patches/upstream/0001-alloc-helper.patch b/debian/patches/upstream/0001-alloc-helper.patch
new file mode 100644
index 000..deafcae
--- /dev/null
+++ b/debian/patches/upstream/0001-alloc-helper.patch
@@ -0,0 +1,52 @@
+commit a2b8e52e46cfd888ac5a48d8ce632bd70a5caa93
+Author: Tomas Bzatek
+Date: Tue Oct 10 18:16:24 2023 +0200
+
+util: Introduce alloc helper with alignment support
+
+Similar to nvme-cli an alloc helper is needed for a couple
+of ioctls sent out during tree scan.
+
+Signed-off-by: Tomas Bzatek
+
+diff --git a/src/nvme/private.h b/src/nvme/private.h
+index 6fb9784a..ee9d738b 100644
+--- a/src/nvme/private.h
b/src/nvme/private.h
+@@ -182,6 +182,8 @@ nvme_ctrl_t __nvme_lookup_ctrl(nvme_subsystem_t s, const char *transport,
+ const char *host_iface, const char *trsvcid,
+ const char *subsysnqn, nvme_ctrl_t p);
+
++void *__nvme_alloc(size_t len);
++
+ #if (LOG_FUNCNAME == 1)
+ #define __nvme_log_func __func__
+ #else
+diff --git a/src/nvme/util.c b/src/nvme/util.c
+index 8fe094d5..20679685 100644
+--- a/src/nvme/util.c
b/src/nvme/util.c
+@@ -7,6 +7,7 @@
+ * Chaitanya Kulkarni
+ */
+
++#include
+ #include
+ #include
+ #include
+@@ -1058,3 +1059,15 @@ bool nvme_iface_primary_addr_matches(const struct ifaddrs *iface_list, const cha
+ }
+
+ #endif /* HAVE_NETDB */
++
++void *__nvme_alloc(size_t len)
++{
++ size_t _len = round_up(len, 0x1000);
++ void *p;
++
++ if (posix_memalign((void *), getpagesize(), _len))
++ return NULL;
++
++ memset(p, 0, _len);
++ return p;
++}
diff --git a/debian/patches/upstream/0002-aligned-payloads.patch b/debian/patches/upstream/0002-aligned-payloads.patch
new file mode 100644
index 000..8c514d0
--- /dev/null
+++ b/debian/patches/upstream/0002-aligned-payloads.patch
@@ -0,0 +1,60 @@
+commit 68c6ffb11d40a427fc1fd70ac2ac97fd01952913
+Author: Tomas Bzatek
+Date: Tue Oct 10 18:18:38 2023 +0200
+
+tree: Allocate aligned payloads for ns scan
+
+libnvme is actually doing some namespace identification
+during tree scan, leading to stack smash on some systems.
+
+Signed-off-by: Tomas Bzatek
+
+diff --git a/src/nvme/tree.c b/src/nvme/tree.c
+index 00cf96f7..5636aa18 100644
+--- a/src/nvme/tree.c
b/src/nvme/tree.c
+@@ -2404,26 +2404,33 @@ static void nvme_ns_parse_descriptors(struct nvme_ns *n,
+
+ static int nvme_ns_init(struct nvme_ns *n)
+ {
+- struct nvme_id_ns ns = { };
+- uint8_t buffer[NVME_IDENTIFY_DATA_SIZE] = { };
+- struct nvme_ns_id_desc *descs = (void *)buffer;
++ struct nvme_id_ns *ns;
++ struct nvme_ns_id_desc *descs;
+ uint8_t flbas;
+ int ret;
+
+- ret = nvme_ns_identify(n, );
+- if (ret)
++ ns = __nvme_alloc(sizeof(*ns));
++ if (!ns)
++ return 0;
++ ret = nvme_ns_identify(n, ns);
++ if (ret) {
++ free(ns);
+ return ret;
++ }
+
+- nvme_id_ns_flbas_to_lbaf_inuse(ns.flbas, );
+- n->lba_shift = ns.lbaf[flbas].ds;
++ nvme_id_ns_flbas_to_lbaf_inuse(ns->flbas, );
++ n->lba_shift = ns->lbaf[flbas].ds;
+ n->lba_size = 1 << n->lba_shift;
+- n->lba_count = le64_to_cpu(ns.nsze);
+- n->lba_util = le64_to_cpu(ns.nuse);
+- n->meta_size = le16_to_cpu(ns.lbaf[flbas].ms);
++ n->lba_count = le64_to_cpu(ns->nsze);
++ n->lba_util = le64_to_cpu(ns->nuse);
++ n->meta_size = le16_to_cpu(ns->lbaf[flbas].ms);
+
+- if (!nvme_ns_identify_descs(n, descs))
++ descs = __nvme_alloc(NVME_IDENTIFY_DATA_SIZE);
++ if (descs && !nvme_ns_identify_descs(n, descs))
+ nvme_ns_parse_descriptors(n, descs);
+
++ free(ns);
++ free(descs);
+ return 0;
+ }
+
Bug#1068953: new upstream (10.0)
Package: frr Severity: wishlist Hi David and Ondrej, it would be nice if you could upload the newly released frr version. If you need/want help, I'm happy to do so, just let me know. Regards, Daniel
Bug#1067450: ttyd: does not start
close 1067450 thanks Hi, On 3/21/24 18:03, Daniel wrote: Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E: lws_create_context: failed to load evlib_uv Mar 21 17:59:09 zone-s ttyd[1039170]: [2024/03/21 17:59:09:4449] E: libwebsockets context creation failed Mar 21 17:59:09 zone-s systemd[1]: ttyd.service: Main process exited, code=exited, status=1/FAILURE Mar 21 17:59:09 zone-s systemd[1]: ttyd.service: Failed with result 'exit-code'. this is a stray issue because of the t64 migration when you haven't fully updated your system. on a minimal, up2date sid ttyd works reproducibly fine. Regards, Daniel
Bug#1068952: new upstream required for frr
Package: libyang2 Severity: wishlist Hi Ondrej, it would be nice if you could upload libyang2 >= 2.1.128 as the new frr release requires that. If you need/want help, I'm happy to do so, just let me know. Regards, Daniel
Bug#1068951: new upstream (6.x)
Package: knot-resolver Severity: wishlist Hi, it would be nice if you could upload knot-resolver 6.x to experimental. Regards, Daniel
Bug#1065692: NMU: 9.1-0.1
Package: frr Version: 9.1-0.1 Severity: normal Hi, please find the diff of the NMU from 8.4.4-1.1 to 9.1-0.1 as patch attached. I noticed that frr could do with some more packaging love, I'd be happy to help out if you need/want any. Regards, Daniel frr_9.1-0.1.patch.gz Description: application/gzip
Bug#1059534: DEP17: handle /usr-move for gzip and its diversions by zutils
On 3/8/24 15:28, Helmut Grohne wrote: > $FILE needs to be used here. thanks. > I was about to NMU zutils. Can you move ahead soonish? Once zutils is > uploaded, I can go ahead with gzip. sure, will upload in ~3h from now. Regards, Daniel
Bug#1059534: DEP17: handle /usr-move for gzip and its diversions by zutils
Hi Helmut, thanks for the patch and work on this, much appreciated. Just to be sure - I think I've found a typo in the latest iteration of the patch, could you please confirm? https://git.progress-linux.org/users/daniel.baumann/debian/packages/zutils/commit/?id=a4f81b9df9543f588c052861426469405603fb1d Regards, Daniel
Bug#1055509: diversions of /sbin/halt and friends
On 12/22/23 12:30, Helmut Grohne wrote: I am happy with all of these changes moving to unstable and trixie. applied and uploaded both p-l-metapackages and bfh-metapackages to unstable. Thanks for your patience. thank you for all your work and help! Regards, Daniel
Bug#1055511: progress-linux-container: diversions need to be updated to deal with DEP17 P3
Hi Helmut On 12/19/23 15:13, Helmut Grohne wrote: Based on the work on molly-guard, I'm ataching an updated patch and it really is a copy of the one on bfh-container #1055509, so see there for the why its done the way its done. great, thanks! I'll test it tomorrow and upload. Regards, Daniel
Bug#1054354: Would you care to share a few reasons behind not including Machine Learning?
Hi, On 12/11/23 15:52, grin wrote: > Could you write at least a short note into README.Debian (or TODO) behind the > reasons > why ML is not compiled in? I'm currently re-working the netdata packaging after the latest upstream changes, which is quite some work.. this issue is definitely on the todo, but not the top one. Thanks for your patience. Regards, Daniel
Bug#1057908: new upstream (1.2.1)
Package: sentinelsat Severity: wishlist Hi Simon, thank you for maintaining sentinelsat in Debian. It would be nice if you could update it to the current upstream version (1.2.1). Regards, Daniel
Bug#1057909: new upstream (1.0.1)
Package: icingaweb2-module-reporting Severity: wishlist Hi David, thank you for maintaining icingaweb2-module-reporting in Debian. It would be nice if you could update it to the current upstream version (1.0.1). Regards, Daniel
Bug#1057907: new upstream (0.7.2)
Package: port-for Severity: wishlist Hi David, thank you for maintaining port-for in Debian. It would be nice if you could update it to the current upstream version (0.7.2). Regards, Daniel
Bug#1057906: new upstream (1.3.2)
Package: icingaweb2-module-x509 Severity: wishlist Hi David, thank you for maintaining icingaweb2-module-x509 in Debian. It would be nice if you could update it to the current upstream version (1.3.2). Regards, Daniel
Bug#1057902: new upstream (1.11.0)
Package: icingaweb2-module-director Severity: wishlist Hi David, thank you for maintaining icingaweb2-module-director in Debian. It would be nice if you could update it to the current upstream version (1.11.0). Regards, Daniel
Bug#1057905: new upstream (1.3.2)
Package: icingaweb2-module-cube Severity: wishlist Hi David, thank you for maintaining icingaweb2-module-cube in Debian. It would be nice if you could update it to the current upstream version (1.3.2). Regards, Daniel
Bug#1057904: new upstream (2.5.0)
Package: icingaweb2-module-businessprocess Severity: wishlist Hi David, thank you for maintaining icingaweb2-module-businessprocess in Debian. It would be nice if you could update it to the current upstream version (2.5.0). Regards, Daniel
Bug#1057903: new upstream (1.2.4)
Package: icingaweb2-module-graphite Severity: wishlist Hi David, thank you for maintaining icingaweb2-module-graphite in Debian. It would be nice if you could update it to the current upstream version (1.2.4). Regards, Daniel
Bug#1057901: new upstream (1.1.0)
Package: geomet Severity: wishlist Hi Simon, thank you for maintaining geomet in Debian. It would be nice if you could update it to the current upstream version (1.1.0). Regards, Daniel
Bug#1057031: nvme-stas: autopkgtest hanging on s390x
Hi Olivier, thanks you, that is much apperciated. I've been mostly away/VAC the last two weeks, but I'll take care about this and the other patch later today. Regards, Daniel
Bug#1041689: stack smashing detected in libnvme
close 1041689 1.5-2 thanks Hi Marc, On 8/8/23 11:07, Marc Bres Gil wrote: > I've downloaded it from sid repositories, installed manually and seems > to work. thank you for confirming and reporting it in the first place, I'm closing the bug now. Regards, Daniel
Bug#1041689: stack smashing detected in libnvme
Hi Marc, I think the bug you reported is fixed when using libnvme 1.5-2. Can you confirm? Regards, Daniel
Bug#1040523: new upstream (2.4)
Package: isc-kea Severity: wishlist Hi, upstream has releases 2.4.0 this week, it would be nice if you could upgrade to it in Debian. Regards, Daniel
Bug#1040051: prompt-toolkit breaks pymodbus autopkgtest: output on stderr: Task was destroyed but it is pending!
notfound 1040051 prompt-toolkit/3.0.38-2 retitle 1040051 autopkgtest err "Task was destroyed but it is pending!" thanks Hi, thanks for reporting this. however, I can't reproduce it - I don't think the bug is caused by prompt-toolkit but by anthing other that is different between testing and unstable. Also the error message doesn't sound like prompt-toolkit is involved here at all. Regards, Daniel
Bug#1035999: Debian 12 rc2 error: 'mdadm: No arrays found in config file or automatically'
close 1035999 thanks Hi Bill, thank you for your patience - it took some time to systematically reproduce your bug report. I've tried the following permutations: 1. virtualbox with one disk: 1.1 encrypted-partition-on-luks (guided partitioning) 1.1.1 installing "standard" (no tasks selected) 1.1.2 installing "gnome-desktop" (default task selection) 1.2 encrypted-partition-on-luks (manual partitioning) 1.2.1 installing "standard" (no tasks selected) 1.2.2 installing "gnome-desktop" (default task selection) 2. virtualbox with two disks attached, only using one: 2.1 encrypted-partition-on-luks (guided partitioning) 2.1.1 installing "standard" (no tasks selected) 2.1.2 installing "gnome-desktop" (default task selection) 2.2 encrypted-partition-on-luks (manual partitioning) 2.2.1 installing "standard" (no tasks selected) 2.2.2 installing "gnome-desktop" (default task selection) So in total I did 8 installation with debian-12.0.0-amd64-netinst.iso and could not reproduce it. I tried everything twice, with a virtualbox that has two disks attached just to be sure that there's no bug "sneaking" in mdadm due to some autodetection. At this point I'm out of ideas on how you ended up with mdadm in the scenario you described. If you can still reproduce it, please let me know how (and reopen the bug). In the meanwhile, I'm closing it. Regards, Daniel
Bug#1039168: deluge: ships sysv-init script without systemd unit
close 1039168 2.1.1-3 thanks Hi, On 6/26/23 00:21, bl...@debian.org wrote: > deluge has been flagged by Lintian as shipping a sysv-init script > without a corresponding systemd unit file. thanks; this is not the case since deluge 2.1.1-3 from 2023-02-24 already, so closing. Regards, Daniel
Bug#1039181: doodle: ships sysv-init script without systemd unit
close 1039181 0.7.2-6 thanks Hi, On 6/26/23 00:21, bl...@debian.org wrote: > doodle has been flagged by Lintian as shipping a sysv-init script > without a corresponding systemd unit file. thanks; the daemon just has been removed due to #1038809, so, this doesn't apply anymore to the current package. Regards, Daniel
Bug#1039027: new upstream (2.1.0)
Package: python-pgspecial Hi, thank you for maintaining pgsepcial in Debian. Now that bookworm has been released, it would be nice if you could update the package to the current upstream version (2.1.0). Regards, Daniel
Bug#893069: new upstream (4.4.3)
retitle 893069 new upstream (4.4.10) thanks Hi Javier, another two years have passed, bookworm has been released.. I must assume that you're MIA and would like to take over the package. Are you fine with this? Regards, Daniel
Bug#1038809: doodle: Depends on unmaintained gamin
On 6/24/23 19:03, Christian Grothoff wrote: > Do we know if there is anything else that replaces > libgamin in terms of functionality? it's seems gamin has been abandoned quite some time ago already in favour of using inotify. maybe using libinotify from https://github.com/inotify-tools/inotify-tools/ instead? Regards, Daniel
Bug#1038809: doodle: Depends on unmaintained gamin
On 6/24/23 18:37, Daniel Baumann wrote: > removed now, so nevermind, thanks, and sorry for the noise. sorry, I wrote that while the package was still building. without libgamin-dev (containing libfam.so), there's no doodled then. so now we now :) Regards, Daniel
Bug#1038809: doodle: Depends on unmaintained gamin
On 6/24/23 16:10, Christian Grothoff wrote: > I'm a bit confused where the build-depends comes from confusing indeed - it seems it has creeped in in 2007 (probably from the 'fam' removal at that time) and has never been questioned ever since. removed now, so nevermind, thanks, and sorry for the noise. Regards, Daniel
Bug#1030683: bundling extensions into one src/bin: unmaintainable?
close 1030683 20230618-2 thanks Hi, I'd like to once again point out that I'm just interested in having these extensions apt-get'able - I don't have any strong opinions either way (one src-package per extensions, or one src-package for all extensions), so I'm happy to do/migrate to whatever is the consensus between ftp-master and pkg-gnome. Meanwhile, I've tried to address all the raised point based (e.g. versioned provides, etc.) on the assumption, that ftp-master continues to request 'one src-package for all extensions'. This seems to be still the case as we didn't hear anything else from ftp-master after message #10 in this bug. The bug has been quiet for some time, leading me to the conclusion that the "discussion is over". Therefore there's nothing left for me to do in this bug, so I'm closing it. If anyone think different, please feel free to reopen it anytime. Regards, Daniel
Bug#1038809: doodle: Depends on unmaintained gamin
Hi Christian, On 6/21/23 18:05, Simon McVittie wrote: > This package has a Depends or Build-Depends on gamin, which is unmaintained > upstream (see #1008205). > > The Linux kernel's inotify interface is a good replacement. > > We shouldn't really be shipping gamin in Debian 13, so this is likely to > become release-critical in future. What are your plans for doodle - do you think you will/could replace gamin within the next ~18 months, or, would you like me to remove it instead? Regards, Daniel
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Hi Mark, On 6/18/23 10:33, Mark Hindley wrote: > I would still disagree with that. just to avoid misunderstandings, my current understanding is: 1) technical issue: non-bootable systems on some non-systemd systems - can be handled by moving mdadm initscripts into orphan-sysvinit-scripts, and - adding a note in mdadm to point to orphan-sysvinit-scripts. 2) technical issue: no maintenance tasks on non-systemd systems - could be handled by a future orphan-cron-jobs package - is an issue that needs to be adressed for sure, but isn't critical like booting. 3) non-technical issue: systemd vs. sysvinit - we have decided that in Debian. Is my understanding correct, that: * we have an agreement on the 1) being technically possible to be solved that way * we still need to find a solution in place for 2) * we agree to disagree on 3) If so, do you mind taking care about mdadm initscript making its way into orphan-sysvinit-scripts? Regards, Daniel
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
Hi Mark, On 6/17/23 19:13, Mark Hindley wrote: > I am asking gently for the reinstatement of the recently removed non-systemd > initscripts. I hear you, but I prefer not doing this for the stated reasons. How about getting the mdadm initscript into orphan-sysvinit-scripts? I read the section about bugs/limitations on orphan-sysvinit-scripts but can't see anything that would be of concern for mdadm. Assuming there are no problems of having mdadm initscripts in orphan-sysvinit-scripts, I think this is the best way forward. Also, I've added a check to show a note via debconf (only briefly tested): https://git.progress-linux.org/users/daniel.baumann/debian/packages/mdadm/log/ Regards, Daniel
Bug#1037502: missing ipv4/ipv6 commands
Package: force-ip-protocol Version: 0.2.0-2 Severity: wishlist Hi Thorsten, thank you very much for force-ip-protocol, it's very handy. Unfortunately the debian package does not install /usr/bin/ipv4 or /usr/bin/ipv6. Assuming you did that deliberately (because they would be quite generic; I woudn't mind though :), maybe naming them force-ipv4/force-ipv6 would be less generic? Anyhow - having the helpers in the path and in the binary package would be super useful. Regards, Daniel
Bug#1037496: mdadm: Please restore support for use without systemd as PID 1
retitle 1037496 show note about missing boot integration for non-systemd thanks Hi Mark, On 6/13/23 14:28, Mark Hindley wrote: > It would be a great help to users of non-systemd inits if you could restore > them. thanks you for your report. Personally I'm using systemd, but in general I fully agree that as long as it's no "burden" to keep the sysvinit scripts around, I'd keep them. For mdadm specifically, using sysvinit scripts has been the source of a bunch of bugs as some things are not properly supportable when it comes to events/race-condition handling when detecting raid devices in early boot. Most other distributions as well as upstream don't support sysvinit anymore in mdadm. I can see at least three disadvantages for keeping sysvinit scripts in mdadm around: * I would need to support them in Debian for a type of system I don't use anywhere anymore since several Debian releases. Personally, I'd rather spend time on, to me, more appealing things. * Keeping sysvinit support for mdadm in Debian de-facto makes me upstream for these scripts, which doesn't seem right given that I don't use it myself. * Keeping sysvinit support would "falsly advertise" that it's actually maintained and cared for, which isn't the case and I'd expect that a lot of bugs don't get spottet in time for a next Debian release. As of policy 4.5.0, including sysvinit scripts in a package if systemd units are present, is not longer recommended but optional, so that (at least after the bookworm release last weekend) I'd expect that a lot of other packages are going to drop the sysvinit scripts too. A solution could be for those that like to keep using sysvinit, to submit the scripts for inclusion in the orphan-sysvinit-scripts package and maintain it there. > Installing recent mdadm on a non-systemd system can render the system > unbootable. Good point, I'll think about emitting an appropriate message so that it's not easily overseen in such situtations. Regards, Daniel
Bug#1037486: new upstream (3.5)
Package: rspamd Severity: wishlist Hi, thank you so much for maintaining rspamd in debian. Some time ago, there was a new upstream release with some nice new features. It would be nice if you could update the package to the current version (3.5). Regards, Daniel
Bug#1036528: zutils: leftover conffiles
found 1036528 1.12-1 notfound 1036528 1.12-2 close 1036528 1.12-2 thanks Hi Christoph, thank you for your report, this has been fixed in 1.12-2: https://git.progress-linux.org/users/daniel.baumann/debian/packages/zutils/commit/?id=4596dac645e794ca9153e92a99d176dfc357c2ce I've confirmed that when upgrading from previous versions, with the installation of zutils 1.12-2, /etc/zutils gets removed: ---snip--- daniel@daniel:~$ sudo apt install zutils [...] Reading changelogs... Done (Reading database ... 277758 files and directories currently installed.) Preparing to unpack .../zutils_1.12-2_amd64.deb ... Unpacking zutils (1.12-2) over (1.8-3+b10) ... Setting up zutils (1.12-2) ... Removing obsolete conffile /etc/zutilsrc ... Processing triggers for install-info (6.7.0.dfsg.2-6) ... Processing triggers for man-db (2.11.2-2) ... [...] daniel@daniel:~$ ---snap--- Regards, Daniel
Bug#1037014: AttributeError: module 'gettext' has no attribute 'bind_textdomain_codeset'
close 1037014 2.1.1-1 thanks Hi Matt, thank you for your report. Yes, you're right that deluge-console is broken in current unstable/testing, this has been fixed in the newer upstream version that can be found in experimental, I'm versioned-closing the bug as such. The situation for deluge in bookworm is rather unfortunate, I took over while bookworm was in freeze already so a lot of fixes, like this one, can't make it into bookworm anymore due to freeze policy. Let's make sure that the upper-next Debian release will have a decent deluge package from the start and use a backport of the (currently 2.1.1-3 in experimental) newer version in the meanwhile. Regards, Daniel
Bug#1032969: mdadm initrd scripts reference command not present in initrd
close 1032969 4.2+20230508-1 thanks Hi, this has been fixed by newer mdadm, at least above version, thus closing the bug. Regards, Daniel
Bug#1035999: Debian 12 rc2 error: 'mdadm: No arrays found in config file or automatically'
tag 1035999 + moreinfo thanks Hi Bill, thank you for your report. In order to reproduce it, I've got some questions for you: * you were using a live image, did you install with 'debian-installer' (the "Install" item in the boot menu) or 'calamares' (an installer application you can start in KDE)? * encrypted LVM: which "order" did you use, encrypted partition and LVM in it, or LVM and then encrypted partitions in it? Regards, Daniel
Bug#1033696: mdadm: dangling link to mdadm-shutdown.service
close 1033696 thanks Hi Christoph, thank you for your report. The problem you're describing sounds like #1031695 from dh_installsystemd. However, when looking at the mdadm 4.2-5 .deb file, it's not affected by that. Installing it on a clean system (with and without merged-usr) works both as expected (no dangling symlinks; all systemd files in /lib/systemd, not /usr/lib/systemd). Also I can't think of anything that would triggered that within the mdadm. Given all of the above, I think it must have been a transient problem that was caused by something outside of mdadm (and which I can't influence on the mdadm side). In any way, nothing I can do something about in mdadm, hence closing this bug. Regards, Daniel
Bug#1035937: new upstream (1.1.0)
Package: python-deepmerge
Severity: normal
Hi Birger,
thanks for maintaining python-deepmerge in Debian.
As this module is used by other tools which require >=1.1. Since
bookworm is frozen, it would be nice if you could upload it to
experimental, this would ease backporting for us.
I've build it in our local repository, the upgrade to 1.1 requires the
following two small changes (also attached as patches):
https://git.progress-linux.org/packages/graograman-backports-extras/python-deepmerge/commit/?id=97d7dfd07987f54409fd7773658423cb73c0045b
https://git.progress-linux.org/packages/graograman-backports-extras/python-deepmerge/commit/?id=31931e8c6f8353b5b1f2d8e67a33f819eadcb8f0
Regards,
DanielFrom 97d7dfd07987f54409fd7773658423cb73c0045b Mon Sep 17 00:00:00 2001
From: Daniel Baumann
Date: Thu, 11 May 2023 13:17:34 +0200
Subject: [PATCH 1/3] Removing
Remove-vcver-dependency-and-hardcode-version.patch, not needed anymore.
Signed-off-by: Daniel Baumann
---
...cver-dependency-and-hardcode-version.patch | 24 ---
debian/patches/series | 1 -
2 files changed, 25 deletions(-)
delete mode 100644 debian/patches/0001-Remove-vcver-dependency-and-hardcode-version.patch
delete mode 100644 debian/patches/series
diff --git a/debian/patches/0001-Remove-vcver-dependency-and-hardcode-version.patch b/debian/patches/0001-Remove-vcver-dependency-and-hardcode-version.patch
deleted file mode 100644
index 90a694f..000
--- a/debian/patches/0001-Remove-vcver-dependency-and-hardcode-version.patch
+++ /dev/null
@@ -1,24 +0,0 @@
-From: Birger Schacht
-Date: Fri, 6 Nov 2020 21:37:08 +0100
-Subject: Remove vcver dependency and hardcode version
-
-Forwarded: not-needed
-
- setup.py | 3 +--
- 1 file changed, 1 insertion(+), 2 deletions(-)
-
-diff --git a/setup.py b/setup.py
-index edf0a92..0ddf956 100644
a/setup.py
-+++ b/setup.py
-@@ -17,8 +17,7 @@ install_requires = [
- tests_require = []
-
- setup(name='deepmerge',
-- setup_requires=["vcver"],
-- vcver={"is_release": is_release, "path": base},
-+ version='0.0.5',
- description='a toolset to deeply merge python dictionaries.',
- long_description=open(README_PATH).read(),
- author='Yusuke Tsutsumi',
diff --git a/debian/patches/series b/debian/patches/series
deleted file mode 100644
index 7a3223c..000
--- a/debian/patches/series
+++ /dev/null
@@ -1 +0,0 @@
-0001-Remove-vcver-dependency-and-hardcode-version.patch
--
2.40.1
From 31931e8c6f8353b5b1f2d8e67a33f819eadcb8f0 Mon Sep 17 00:00:00 2001
From: Daniel Baumann
Date: Thu, 11 May 2023 13:20:51 +0200
Subject: [PATCH 2/3] Adding build-depends to pybuild-plugin-pyproject for
PEP517 support.
Signed-off-by: Daniel Baumann
---
debian/control | 1 +
1 file changed, 1 insertion(+)
diff --git a/debian/control b/debian/control
index f3d18ca..5031c58 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ XSBC-Original-Uploaders: Birger Schacht
Bugs: mailto:maintain...@lists.progress-linux.org
Build-Depends: debhelper-compat (= 13),
dh-python,
+ pybuild-plugin-pyproject,
python3-all,
python3-setuptools,
python3-sphinx,
--
2.40.1
Bug#1034747: systemd-journal-gatewayd flood log with entries from microhttpd
close 0.9.75-6 thanks On 4/24/23 09:01, Michael Biebl wrote: > Since those errors come for libmicrohttp, I'm going to reassing the issue > Checking the changelog of libmicrohttp, there are quite a few changes > regarding the handling of those options, see > https://git.progress-linux.org/users/daniel.baumann/debian/packages/libmicrohttpd/tree/ChangeLog yes, this is supposedly fixed in (at least) the current version in testing/unstable, thus closing the bug. Regards, Daniel
Bug#1031593: deluge-web: gettext error
On 3/28/23 08:56, nb wrote: > when will 2.1.1 version be available? it's in experimental as testing/unstable is frozen. I'll upload to unstable once bookworm is released. Regards, Daniel
Bug#1003352:
On 3/22/23 06:18, Cyrus Lien wrote: > This bug still needs a boot script mounting efivarfs in initrd for > systems whose rootfs are on RAID volume. as the bug sais: this has been fixed in mdadm 4.2+20230223-1. Regards, Daniel
Bug#1032969: mdadm initrd scripts reference command not present in initrd
Hi Jon, thank you for your report. On 3/14/23 23:16, Jon wrote: > I think its from this script: > > https://salsa.debian.org/debian/mdadm/-/blob/debian/4.2-4/debian/initramfs/scripts/local-bottom/mdadm yes, it's a cosmetical error. I'll fix it in one of the next uploads, but it doesn't meet the treshold for a bookworm update (given the freeze). Regards, Daniel
Bug#1032650: ITP: nvme-stas -- NVMe STorage Appliance Services
On 3/10/23 16:33, Benjamin Drung wrote: > My preference is that I will do the initial packaging > and you become the maintainer and I only an uploader for it. sounds like win-win, thanks :) > Where should I put the packaging git repository? To > https://salsa.debian.org/debian/nvme-stas? sounds good, can always be changed anytime later if needed. Regards, Daniel
Bug#1032650: ITP: nvme-stas -- NVMe STorage Appliance Services
Hi Benjamin On 3/10/23 14:40, Benjamin Drung wrote: > I would love to team maintain that package. I've had this on my todo list (but didn't fill a ITP for it), so I'm happy to (co)maintain it or take over if you just want do to the inital but not longterm work. Regards, Daniel
Bug#1032572: new upstream (3.2.2)
Hi Bernhard, On 3/10/23 08:59, Bernhard Schmidt wrote: > I can do so later, but I would prefer to fix these bugs in bookworm, > where uploading a whole new upstream version is not accepted at this > point in the release preparation right, ideally we'd have both; if you need help I'm happy to help with any uploads :) > Interestingly someone else has reported the partial CA problem a few > hours after your report, and provided a link to the issue/commit fixing > this. See Bug#1032590 thanks; yes, I guess now that people are starting to update-tests of their infrastructure to bookworm, they start noticing things :) > I have just uploaded 3.2.1-3 to the archive, it should be built in the > next hours. Could you test the resulting package and report back? thanks, much appreciated; yes, will do. Regards, Daniel
Bug#1032572: new upstream (3.2.2)
Package: freeradius Hi, the latest upstream release (3.2.2) fixes some important bugs for us, e.g. the fact that using an intermediate CA for which EAP-TLS, upstream writes: "It's also worth mentioning that FreeRADIUS 3.2.1 has an issue with partial chains. E.g. if you have Root CA -> Intermediate CA -> Client Cert and you want to put just Intermediate CA in the ca_file as that is what you want to trust rather than the root CA, then that does not work correctly on 3.2.1." Given the freeze, it would be very helpful if you could upload 3.2.2 to experimental, this would ease the local backporting on our end tremendously since we need 3.2.2. Regards, Daniel
Bug#1032272: RFP: pysilfont -- Collection of utilities for font development
retitle 1032272 ITP: pysilfont -- utilities for font development owner 1032272 Daniel Baumann tag 1032272 + pending thanks Hi Daniel, I've uploaded pysilfont 1.6.0-1 to NEW. Regards, Daniel
Bug#1031839: network devices do not work after kernel upgrade
On 2/28/23 18:58, Thorsten Alteholz wrote: > which one would you recommend? we use those extensively (several thousands), ymmv: https://www.flexoptix.net/de/p-8596-02.html Regards, Daniel
Bug#909533: No ability to specify legacy arrays in mdadm.conf to build automatically at boot
close 909533 thanks Hi, thank you for your report. EFI system partitions (ESP) are partitions with a specific partition type, regardless of the filesystem within (usually fat32). Linux MD depends on having the partitions of type Linux raid, so mdadm cannot be used for this use case. The "correct" way to mirror your ESPs is to have a grub hook that takes care of this. Currently, debian doesn't have this out-of-the-box included in the grub2 packages, but Ubuntu has a 'grub-multi-install' that takes care of that. As an alternative to this, if you search the internet, you'll also find several "rsync hooks" for grub2 to do this in another way. Regards, Daniel
Bug#763207: mdadm: kernel segfault related to software RAID5 rebuild
close 763207 thanks Hi, thank you for reporting this. I second upstreams opinion that there's nothing at the MD layer involved here. Given that the bugreport is a single issue nobody else reported and is 9 years old without followups since, I'm closing this bug. If you can still reproduce the issue with current versions of everything, please open a new bug. Regards, Daniel
Bug#759063: mdadm RAID5 array intermittently stalls during a write operation
close 759063 thanks Hi, thank you for reporting this. I second upstreams opinion that there's nothing at the MD layer involved here. Given that the bugreport is a single issue nobody else reported and is 9 years old without followups since, I'm closing this bug. If you can still reproduce the issue with current versions of everything, please open a new bug. Regards, Daniel
Bug#1031839: network devices do not work after kernel upgrade
On 2/27/23 15:25, Daniel Baumann wrote: > ixgbe.allow_unsupported_sfp=1 I've rebootet the server again just to check and indeed, the above override doesn't work anymore (also tried with ...=1,1 because it's a two slots adapter, but doesn't make any difference). So, seems the reason for your trouble is that allow_unsupported_sfp broke somewhen in between 5.x and 6.x, at least for ixgbe. I didn't check with i40e, but could do so if needed/wanted. Any chance you could confirm it by testing with an Intel-branded SFP? Regards, Daniel
Bug#1031839: network devices do not work after kernel upgrade
Hi Thorsten, On 2/25/23 11:56, Thorsten Alteholz wrote: > The I225-V are working fine, the other four make trouble. right, but those are copper interfaces. > I am using transceiver modules AXS85-192-M3 from 10Gtek. It looks like they are not flashable (like flexoptix and others), so I presume these are "non-Intel"-branded. > The allow_unsupported_sfp=1 does not make a difference. Shouldn't there > be at least a syslog message if an unsupported sfp is detected? Just to be extra sure, you've added: ixgbe.allow_unsupported_sfp=1 to your kernel cmdline, right? I've checked with an up2date bookworm test-server and kernel 6.1.12-1.. when inserting a Intel-branded flexoptix SFP, I'll get this message: Feb 27 14:59:06 xxx kernel: ixgbe :5e:00.0 ens2f0: detected SFP+: 5 whereas with a Arista-branded one, I'll get the same: Feb 27 15:00:30 xxx kernel: ixgbe :5e:00.0 ens2f0: detected SFP+: 5 Just to document it.. this is dmesg from after rebooting the machine, there's no allow_unsupported_sfp set at all, and there's an Intel-branded SFP in one slot (ens2f0), an Arista-branded one in the other (ens2f1): [3.178235] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver [3.178385] ixgbe: Copyright (c) 1999-2016 Intel Corporation. [3.927189] ixgbe :5e:00.0: Multiqueue Enabled: Rx Queue count = 63, Tx Queue count = 63 XDP Queue count = 0 [3.927726] ixgbe :5e:00.0: 32.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x8 link) [3.928058] ixgbe :5e:00.0: MAC: 2, PHY: 19, SFP+: 5, PBA No: 0210FF-0FF [3.928320] ixgbe :5e:00.0: 0c:c4:7a:8f:48:f6 [3.940393] ixgbe :5e:00.0: Intel(R) 10 Gigabit Network Connection [4.121469] ixgbe :5e:00.1: Multiqueue Enabled: Rx Queue count = 63, Tx Queue count = 63 XDP Queue count = 0 [4.122320] ixgbe :5e:00.1: 32.000 Gb/s available PCIe bandwidth (5.0 GT/s PCIe x8 link) [4.122938] ixgbe :5e:00.1: MAC: 2, PHY: 20, SFP+: 6, PBA No: 0210FF-0FF [4.123483] ixgbe :5e:00.1: 0c:c4:7a:8f:48:f7 [4.134330] ixgbe :5e:00.1: Intel(R) 10 Gigabit Network Connection [4.315894] ixgbe :5e:00.0 ens2f0: renamed from eth2 [4.411504] ixgbe :5e:00.1 ens2f1: renamed from eth3 [8.043579] ixgbe :5e:00.0: registered PHC device on ens2f0 [8.227099] ixgbe :5e:00.0 ens2f0: detected SFP+: 5 it's not obvious from the messages that one SFP is working and the other one is not. the only difference I can see is that the one with the Intel-branded SFP has this line: [8.043579] ixgbe :5e:00.0: registered PHC device on ens2f0 there's also no difference wrt/ the debug level (I've testet with printk set to 7 and 8, no additional messages are shown). Hope that helps - my guess would be to try and verify with an Intel or Intel-flashed SFP to rule out. Hope that helps. Regards, Daniel
Bug#784874: mdadm --re-add Segmentation Fault
close 784874 3.3.4-1 thanks Hi, this bug has been fixed in upstreams 3.3.3 version, the next debian upload was 3.3.4-1, thus closing this bug accordingly. Regards, Daniel
Bug#569359: /sbin/mdadm --detail --scan fails in d-i
close 569359 thanks Hi, there's nothing left; map file location has been straightened, consistently using UUID in both mdadm and d-i helps got conceptionally rid of this issue, closing the bug now. Regards, Daniel
Bug#985536: mdadm crashing when trying to grow an array with big disks
close 985536 4.1-1 thanks Hi, looking at the commit logs, this seems to have been fixed somewhen up to the 4.1 version of mdadm, closing accordingly. Regards, Daniel
Bug#609795: please add a note about /usr/share/doc/mdadm/README.recipes.gz at the top of the man page
close 609795 thanks Hi, thank you for your suggestion, however: * carrying this as a debian-specific patch doesn't make sense, and getting that accepted upstream is not likely either. * in general people are supposed to know that /usr/share/doc/$package/ might contain further documentation that they should look at. Regards, Daniel
Bug#763917: mdadm: rounding errors in human_size()
close 763917 3.3.4-1 thanks Hi, this was included in upstream version 3.3.3, the next debian version to that was 3.3.4-1. Regards, Daniel
Bug#619265: mdadm: mdadm.8.in -- Order items alphabetically in manual page
close 619265 thanks Hi, thank you for your report, however: * the patches do not apply to the current upstream version anymore. * even if they would, they are way to much of a burden to maintain downstream/keep them debian specific and therefore rebase for every new version, so they need to go to upstream directly. Since there's no real value in keeping this open forever/in the meanwhile, I'm closing the bug. Regards, Daniel
Bug#821355: mdadm: RAID1 unknown partition table kernel messages for raid disks
close 821355 thanks Hi, thank you for reporting this issue, however, there's no actionable content wrt/ mdadm. If your individual partitions are not accessible, there's nothing mdadm can do. Regards, Daniel
Bug#873767: W: mdadm: failed to auto-generate the mdadm.conf file
close 873767 thanks Hi, given that there is no more information provided and the actual issue, if any, is a noop (no MD loaded), I'm closing this bug. Regards, Daniel
Bug#844640: mdadm: Newly-created array doesn't assemble at boot - related to hostname change?
close 844640 thanks Hi, thanks for reporting this issue. mdadm requires that the devices are actually detected and present, so, if you're missing a module in your initrd, it's not something mdadm can do something about it. Regards, Daniel
Bug#855235: mdadm --size -G: size is truncated below 4TiB (on a 32bit platform)
close 855235 thanks Hi, thank you for reporting this. Presumably this is a "old" system with superblock 0.9 where there are such size limits. This is fixed by using superblock 1.x with any current mdadm/kernel. Regards, Daniel
Bug#789150: initramfs-tools: boot fails using root=UUID= for root-device on software, raid /dev/md*
close 789150 thanks Hi, there are so many things that could have gone wrong here/we don't know about the initial bug report, specifically how the disks where "copied" to the new system. However, when changing hardware in a situation like this, the initrd should always be regenerated with would have solved this in the first place. Regards, Daniel
Bug#810687: mdadm: eats all cpu time on all cores
close 810687 thanks Hi Michael, thank you for reporting this and sorry for the inconvenience. Given that the bug is 7 years old, I guess you fixed that system (if it still exists) in the meantime. As nobody else submitted similar bugs like that, I must assume that it was a "one off"-thing specific to your setup, or, most likely a corner case probably fixed in any of the newer mdadm/kernel versions since and thus closing the bug. If you still have the problem, feel free to reopen the bug. Regards, Daniel
Bug#675394: mdadm: Each file copy to array grown by MDADM results in copies with different md5sum values
close 675394 4.2-1 thanks Hi, thank you for reporting this issue and sorry for the inconvenience of it. In later 3.x versions and specifically in the 4.x, there have been quite some fixes regarding the 'grow' functionallity. I could not reproduce this bug with the current mdadm in stable nor in testing/unstable. Give that and that the bug is really old, I'm closing it. Feel free to reopen it if you can reproduce it with a current system. Regards, Daniel
Bug#705454: mdadm: --examine --scan generates wrong #spares
tag 705454 + moreinfo thanks Hi Thorsten, your problem doesn't affect arrays with superblock 1.x and superblock 0.9 is really not much used anymore.. do you still have the issue? I don't think this has much traction to get ever fixed upstream and suggest to close the bug. What do you think? Regards, Daniel
Bug#661278: mdadm --assemble --scan needs better heuristics when partition boundary is near disk boundary
tag 661278 + moreinfo thanks Hi Daniel, your problem doesn't affect superblock 1.x and superblock 0.9 is really not much used anymore.. do you still have the issue? I don't think this has much traction to get ever fixed upstream and suggest to close the bug. What do you think? Regards, Daniel
Bug#749062: mdadm: add "containers" to emergency config file
close 749062 4.2-1 thanks Hi, current mdadm doesn't re-create mdadm.conf anymore, so this issue doesn't exist anymore. Regards, Daniel
Bug#806215: mdadm: upgraded mdadm now does not recognize RAID6 array causing boot to drop into emergency mode
close 806215 4.2-1 thanks Hi, thank you for reporting this issue and sorry for the inconvenience. This change you mentioned has been reverted in one of the previous versions, at least it's not present anymore in 4.2, thus closing this bug. Regards, Daniel
Bug#864145: mdadm will only start root device degraded
close 864145 thanks Hi, this setup works (both when installing new with d-i and when later migrating it manually to it). since there's a long time no answer here and the system most likely has been resetup, I'm closing this bug. Regards, Daniel
Bug#837964: mdadm --add fails, can not add spares (regression)
close 837964 4.2-1 thanks Hi, thank you for reporting this, a patch has been included in some of the newer mdadm releases, but at least with 4.2, hence closing the bug accordingly. Regards, Daniel
