Bug#1072438: 3.0.10 released
i've just released v3.0.10 of notcurses, which fixes this upstream. i'll package it up ASAP (almost certainly today), and it ought close this bug.
Bug#1001661: Info received (Bug#1001661: Info received ((no subject)))
wait...even the most recent of these logs shows that it is testing notcurses 3.0.4, which indeed had this timing problem on input, which was fixed in notcurses 3.0.5: Get:1 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (dsc) [3,148 B] Get:2 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (tar) [7,391 kB] Get:3 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (asc) [833 B] Get:4 http://deb.debian.org/debian testing/main notcurses 3.0.4+dfsg.1-1 (diff) [17.1 kB] but apt-show-versions confirms only 3.0.7 in the archive: [schwarzgerat](0) $ apt-show-versions -a notcurses-bin notcurses-bin:amd64 3.0.7+dfsg.1-1 install ok installed No stable version No testing version notcurses-bin:amd64 3.0.7+dfsg.1-1 unstable ftp.us.debian.org No experimental version notcurses-bin:amd64/unstable 3.0.7+dfsg.1-1 uptodate [schwarzgerat](0) $ oh, i guess "No testing version" indicates it's gone from testing. so why isn't 3.0.7 in unstable the candidate for testing? 3.0.4 is definitely known to be bad.
Bug#1001661: Info received ((no subject))
i'm tracking this upstream at https://github.com/dankamongmen/notcurses/issues/2645
Bug#1001661: notcurses: flaky autopkgtests on armhf
i'm pretty sure raspberry pi is armhf, so i ought be able to dig that one RPi4 i've got up and explore this. if we can reproduce the problem interactively, it ought fall pretty quickly.
Bug#1001661: (no subject)
note that armhf is a 32-bit arm7 machine, unlike arm64 which is arm8. might be time to revisit some assumptions unconsciously made involving processor width.
Bug#1005778: pypandoc: diff for NMU version 1.7.2+ds0-1.1
> However, I don't think that adding lmodern to the package Depends is the > right solution, as that would lead to parts of tex (admittely, a small > part, but still) having to be installed on the system, which is not > required by pandoc itself. > The right solution, I believe, is to add lmodern to the tests/control > Depends, and I've just realized that I prepared that in git, but I never > actually did the upload (ups), and was wondering why it wasn't > working. agreed, so long as it's not required by most outputs (i.e. you can run pypandoc without it and it works). > I will do the upload myself in the next few days, since I have an > up-to-date copy of the repo locally (and salsa is down). alrightie. this was my NM application bug; i guess i will find another one. have a good day! signature.asc Description: PGP signature
Bug#1005778: pypandoc: diff for NMU version 1.7.2+ds0-1.1
Control: tags 1005778 + patch
Control: tags 1005778 + pending
Dear maintainer,
I've prepared an NMU for pypandoc (versioned as 1.7.2+ds0-1.1) and
it will be uploaded by my Account Manager, Sebastian Ramacher.
Please feel free to tell me if he should delay it.
lmodern needed be listed as a regular Depends, not just a
Build-Depends, in order for the autopkgtests to successfully
run. I have added it, and verified that this fixes the
autopkgtests on the testing distribution.
hack on, nick
diff -Nru pypandoc-1.7.2+ds0/debian/changelog pypandoc-1.7.2+ds0/debian/changelog
--- pypandoc-1.7.2+ds0/debian/changelog 2021-12-29 05:19:10.0 -0500
+++ pypandoc-1.7.2+ds0/debian/changelog 2022-02-28 10:12:41.0 -0500
@@ -1,3 +1,11 @@
+pypandoc (1.7.2+ds0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add dependency on lmodern for runtime to fix autopkgtests.
+Closes: #1005778
+
+ -- Nick Black Mon, 28 Feb 2022 10:12:41 -0500
+
pypandoc (1.7.2+ds0-1) unstable; urgency=medium
* New upstream release.
diff -Nru pypandoc-1.7.2+ds0/debian/control pypandoc-1.7.2+ds0/debian/control
--- pypandoc-1.7.2+ds0/debian/control 2021-12-29 05:19:10.0 -0500
+++ pypandoc-1.7.2+ds0/debian/control 2022-02-28 10:10:24.0 -0500
@@ -27,6 +27,7 @@
Package: python3-pypandoc
Architecture: all
Depends:
+ lmodern,
pandoc,
${misc:Depends},
${python3:Depends}
Bug#997845: Info received (Bug#997845: growlight: autopkgtest regression: log repeats until it times out)
notcurses 3.0.4+dfsg.1-1 ought be migrating to testing soon, and if there is any love in this world, it will resolve the continued failures. the most recent i see is from today, still using notcurses 3.0.3. i added several similar unit tests to the notcurses suite, and managed to reproduce the lockup in at least one of its incarnations. we'll see.
Bug#997845: bug 997845
exciting results! i wrapped up a similar invocation and threw it into my notcurses drone CI, and there i fail exactly as i do within the debian CI (i.e. we never terminate, though we don't soak the CPU). https://drone.dsscaw.com:4443/dankamongmen/notcurses/10240/1/2 i ought now be able to resolve this quickly, as i finally seem able to reproduce it locally =]. signature.asc Description: PGP signature
Bug#997845: bug 997845
alright, i might have found the root cause. when we declare EOF, we're not necessarily setting the input poll fd high. as a result, if the EOF comes at the end of an input burst, and we rely on such notifications, we miss it. https://github.com/dankamongmen/notcurses/issues/2521 has more details. i need to rerun the autopkgtests with NOTCURSES_LOGLEVEL=7 to confirm this. Paul, is that possible to do without uploading a new growlight package? i think i've got this just about all figured out, and would appreciate another week or so to get it resolved, if that's doable.
Bug#997845: Info received (Bug#997845: growlight: autopkgtest regression: log repeats until it times out)
wait, i just might have reproduced a failure. it doesn't look like our failure in autopkgtests, but this is an assert() blowing up, and i'm not certain we build with those. if not, maybe we're hitting a case that locks up. let's hope so! this would once again presumably be a notcurses fix. the breakage doesn't happen all the time, but it can be provoked without too much trouble: No ZFS support in this build. Couldn't read link at /sys/class/block/securityfs (No such file or directory) Couldn't read link at /sys/class/block/cgroup2 (No such file or directory) Couldn't read link at /sys/class/block/pstore (No such file or directory) Couldn't read link at /sys/class/block/efivarfs (No such file or directory) Couldn't read link at /sys/class/block/none (No such file or directory) Couldn't read link at /sys/class/block/systemd-1 (No such file or directory) Couldn't read link at /sys/class/block/hugetlbfs (No such file or directory) Couldn't read link at /sys/class/block/mqueue (No such file or directory) Couldn't read link at /sys/class/block/tracefs (No such file or directory) Couldn't read link at /sys/class/block/configfs (No such file or directory) Couldn't read link at /sys/class/block/none (No such file or directory) Couldn't read link at /sys/class/block/zhomez (No such file or directory) Couldn't read link at /sys/class/block/chungus (No such file or directory) Couldn't read link at /sys/class/block/tracefs (No such file or directory) growlight-readline: ./src/lib/in.c:1852: process_escape: Assertion `ictx->amata.used < buflen' failed. ;147;rgb:afaf/afaf/^[\^[]4;148;rgb:afaf/d7d7/^[\^[]4;149;rgb:afaf/d7d7/5f5f^[\^[]4;150;rgb:afaf/d7d7/8787^[\^[]4;151;rgb:afaf/d7d7/afaf^[\^[]4;152;rgb:afaf/d7d7/d7d7^[\^[]4;153;rgb:afaf/d7d7/^[\^[]4;154;rgb:afaf//^[\^[]4;155;rgb:afaf//5f5f^[\^[]4;156;rgb:afaf//8787^[\^[]4;157;rgb:afaf//afaf^[\^[]4;158;rgb:afaf//d7d7^[\^[]4;159;rgb:afaf//^[\^[]4;160;rgb:d7d7//^[\^[]4;161;rgb:d7d7//5f5f^[\^[]4;162;rgb:d7d7//8787^[\^[]4;163;rgb:d7d7//afaf^[\^[]4;164;rgb:d7d7//d7d7^[\^[]4;165;rgb:d7d7//^[\^[]4;166;rgb:d7d7/5f5f/^[\^[]4;167;rgb:d7d7/5f5f/5f5f^[\^[]4;168;rgb:d7d7/5f5f/8787^[\^[]4;169;rgb:d7d7/5f5f/afaf^[\^[]4;170;rgb:d7d7/5f5f/d7d7^[\^[]4;171;rgb:d7d7/5f5f/^[\^[]4;172;rgb:d7d7/8787/^[\^[]4;173;rgb:d7d7/8787/5f5f^[\^[]4;174;rgb:d7d7/8787/8787^[\^[]4;175;rgb:d7d7/8787/afaf^[\^[]4;176;rgb:d7d7/8787/d7d7^[\^[]4;177;rgb:d7d7/8787/^[\^[]4;178;rgb:d7d7/afaf/^[\^[]4;179;rgb:d7d7/afaf/5f5f^[\^[]4;180;rgb:d7d7/afaf/8787^[\^[]4;181;rgb:d7d7/afaf/afaf^[\^[]4;182;rgb:d7d7/afaf/d7d7^[\^[]4;183;rgb:d7d7/afaf/^[\^[]4;184;rgb:d7d7/d7d7/^[\^[]4;185;rgb:d7d7/d7d7/5f5f^[\^[]4;186;rgb:d7d7/d7d7/8787^[\^[]4;187;rgb:d7d7/d7d7/afaf^[\^[]4;188;rgb:d7d7/d7d7/d7d7^[\^[]4;189;rgb:d7d7/d7d7/^[\^[]4;190;rgb:d7d7//^[\^[]4;191;rgb:d7d7//5f5f^[\^[]4;192;rgb:d7d7//8787^[\^[]4;193;rgb:d7d7//afaf^[\^[]4;194;rgb:d7d7//d7d7^[\^[]4;195;rgb:d7d7//^[\^[]4;196;rgb://^[\^[]4;197;rgb://5f5f^[\^[]4;198;rgb://8787^[\^[]4;199;rgb://afaf^[\^[]4;200;rgb://d7d7^[\^[]4;201;rgb://^[\^[]4;202;rgb:/5f5f/^[\^[]4;203;rgb:/5f5f/5f5f^[\^[]4;204;rgb:/5f5f/8787^[\^[]4;205;rgb:/5f5f/afaf^[\^[]4;206;rgb:/5f5f/d7d7^[\^[]4;207;rgb:/5f5f/^[\^[]4;208;rgb:/8787/^[\^[]4;209;rgb:/8787/5f5f^[\^[]4;210;rgb:/8787/8787^[\^[]4;211;rgb:/8787/afaf^[\^[]4;212;rgb:/8787/d7d7^[\^[]4;213;rgb:/8787/^[\^[]4;214;rgb:/afaf/^[\^[]4;215;rgb:/afaf/5f5f^[\^[]4;216;rgb:/afaf/8787^[\^[]4;217;rgb:/afaf/afaf^[\^[]4;218;rgb:/afaf/d7d7^[\^[]4;219;rgb:/afaf/^[\^[]4;220;rgb:/d7d7/^[\^[]4;221;rgb:/d7d7/5f5f^[\^[]4;222;rgb:/d7d7/8787^[\^[]4;223;rgb:/d7d7/afaf^[\^[]4;224;rgb:/d7d7/d7d7^[\^[]4;225;rgb:/d7d7/^[\^[]4;226;rgb://^[\^[]4;227;rgb://5f5f^[\^[]4;228;rgb://8787^[\^[]4;229;rgb://afaf^[\^[]4;230;rgb://d7d7^[\^[]4;231;rgb://^[\^[]4;232;rgb:0808/0808/0808^[\^[]4;233;rgb:1212/1212/1212^[\^[]4;234;rgb:1c1c/1c1c/1c1c^[\^[]4;235;rgb:2626/2626/2626^[\^[]4;236;rgb:3030/3030/3030^[\^[]4;237;rgb:3a3a/3a3a/3a3a^[\^[]4;238;rgb://^[\^[]4;239;rgb:4e4e/4e4e/4e4e^[\^[]4;240;rgb:5858/5858/5858^[\^[]4;241;rgb:6262/6262/6262^[\^[]4;242;rgb:6c6c/6c6c/6c6c^[\^[]4;243;rgb:7676/7676/7676^[\^[]4;244;rgb:8080/8080/8080^[\^[]4;245;rgb:8a8a/8a8a/8a8a^[\^[]4;246;rgb:9494/9494/9494^[\^[]4;247;rgb:9e9e/9e9e/9e9e^[\^[]4;248;rgb:a8a8/a8a8/a8a8^[\^[]4;249;rgb:b2b2/b2b2/b2b2^[\^[]4;250;rgb:bcbc/bcbc/bcbc^[\^[]4;251;rgb:c6c6/c6c6/c6c6^[\^[]4;252;rgb:d0d0/d0d0/d0d0^[\^[]4;253;rgb:dada/dada/dada^[\^[]4;254;rgb:e4e4/e4e4/e4e4^[\^[]4;255;rgb://^[\^[]10;rgb://^[\^[]11;rgb:0808/0808/0808^[\^[[?11u^[[?2026;2$y^[_Gi=1;EINVAL:Zero width/height not allowed^[\^[[4;1035;1584t^[[8;45;132t^[[?62;cAborted
Bug#997845: Info received (Bug#997845: growlight: autopkgtest regression: log repeats until it times out)
further investigation: i uploaded -4 with a change to simply redirect input from /dev/null, rather than echoing 'blockdev -v' into the process. the result was pretty much the exact same: we don't see the input show up, and we get a time out. of course, attempting to reproduce this locally leads to the test immediately exiting on EOF as expected =\. i notice the command to run the test is rather complicated: su -s /bin/bash root -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true; . ~/.profile >/dev/null 2>&1 || true; buildtree="/tmp/autopkgtest-lxc.glluyzfl/downtmp/build.A7s/src"; mkdir -p -m 1777 -- "/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-artifacts"; export AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-artifacts"; export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 "/tmp/autopkgtest-lxc.glluyzfl/downtmp/autopkgtest_tmp"; export AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.glluyzfl/downtmp/autopkgtest_tmp"; export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=160; unset LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; export AUTOPKGTEST_NORMAL_USER=debci; export ADT_NORMAL_USER=debci; touch /tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stdout /tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stderr; bash -ec 'TERM=xterm-256color growlight-readline -v < /dev/null' 2> >(tee -a /tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stderr >&2) > >(tee -a /tmp/autopkgtest-lxc.glluyzfl/downtmp/devnull-stdout);" maybe our answer lives in this setup? it seems we're redirecting both stdout and stderr (makes sense)...what else here is different from our setup? LANG is defined to C.UTF-8. we're defining TERM ourselves. Notcurses is getting sensibly initialized. we're just never receiving input, nor an indication that input is exhausted...
Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere
this is addressed in more detail at https://github.com/dankamongmen/notcurses/issues/2519. i expect to have this fixed within the hour. sorry for the annoyance.
Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere
reopen 1003009 i added -DBUILD_FFI_LIBRARY=off with the intention of no longer building these three shared objects. looking at it now, however, this CMake variable doesn't actually seem to guard their building and installation, and thus it will not have the desired effect. i'm fixing this upstream, and will build a -3 with the necessary patch. sigh.
Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere
thanks, this ought be fixed in an hour or two.
Bug#997845: growlight: autopkgtest regression: log repeats until it times out
i can happily report that notcurses 3.0.2+dfsg.1-3 is passing autopkgtests, after resolving the issue at https://github.com/dankamongmen/notcurses/issues/2505 signature.asc Description: PGP signature
Bug#1001122: Processed: Re: Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression
well, as i noted above, this use case certainly isn't the standard way growlight will be used (although it's a valid one, and one worth fixing -- this was a valuable exercise, and i appreciate autopkgtests spotting this regression!). so it's not very important to users...but at the same time, it was considered important enough to drop the package from testing =]. so i guess i'm getting a bit of a mixed message here. the way i read it, this was critical to fix for the autopkgtests/transition regime, and relatively unimportant for most users. so i agree, we can do without the versioned dep. thanks for walking me through your thinking. signature.asc Description: PGP signature
Bug#1001122: Processed: Re: Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression
if i don't need the versioned dep, there is -- so far as i can tell -- no reason to upload a new growlight at all, unless i need do so to retrigger the autopkgtests and allow a transition to testing. (sorry for my ignorance--i'm still applying for DD) signature.asc Description: PGP signature
Bug#1001122: Processed: Re: Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression
> I don't think you need the versioned depends really. Or did I miss > something? well, if you have an older version of notcurses, you're going to run into this growlight problem, so "solving" this problem for Debian would seem to me to require the versioned dep? i'm sure you're much more knowledgeable though, so please do explain. signature.asc Description: PGP signature
Bug#997845: Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression
Control: reopen -1 oh no! =[ well, at least this can be my primary focus now that notcurses iii is out. i believe i've already provided https://github.com/dankamongmen/growlight/issues/153, but that's the tracking issue upstream. attempts to reproduce this locally have thus far been less than successful -- piping "blockdev -v" into "[sudo] growlight -v" as the tests do runs to successful termination as expected. let me try running it disconnected from a terminal/daemonized. the logs i'm seeing don't show anything obvious; we seem to look up all devices as expected, but then we just don't exit. that has smelled to me like something wrong with the input system, but perhaps it's in the growlight logics. if i can reproduce it, i'm sure the fix will come easily. anyway, this is my #1 open source priority now; sorry for the unwarranted optimism! signature.asc Description: PGP signature
Bug#997845: Your mail
i can happily report that the FTPmasters accepted notcurses 3.0.0 into experimental today, and thus the transition bringing it into unstable ought begin. once that hits, i'll be landing on this with both feet. signature.asc Description: PGP signature
Bug#997845: Your mail
ought i upload a -4 with a changelog entry marking the bug closed? i didn't mark it closed in the changelog because i explicitly wanted the bug left open. sorry for any confusion -- i'm certainly not trying to work around this issue in the long term by reducing testing =]. i just know that it's not going to be fixed until growlight 1.2.38 moves to unstable from experimental, which requires notcurses3, which is in the NEW queue awaiting FTPteam approval. at that point, i'll be reenabling the test. so i don't consider 1.2.37-3 as having "closed" the bug whatsoever. but it ought be closed shortly after notcurses3 hits unstable =].
Bug#997845: Your mail
you are correct in all of your assumptions =]. signature.asc Description: PGP signature
Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression
i went ahead and uploaded growlight 1.2.38 to experimental last evening. it doesn't build now, of course, due to a dep on missing libnotcurses3. i've asked my Application Manager (i'm currently applying for DD status) to sponsor an upload of the latter to experimental+NEW, so that i can begin the transition. at the end of this process, i expect us to have a 1.2.38 uploaded to unstable which will remedy this annoyance. also, just for the record, let me point out that the autopkgtest regression is due in part to the way it's being run in the autopkgtest environment--this is usually an interactive program. i fully agree that it's important to get it resolved, but it's not something that ought affect the majority of users. in any case, things will be in much better shape when 1.2.38 hits unstable. signature.asc Description: PGP signature
Bug#1001122: src:growlight: fails to migrate to testing for too long: autopkgtest regression
Thanks. I actually just cut growlight 1.2.38 literally forty minutes ago, and have prepared it for upload. Unfortunately, it's dependent on the new libnotcurses3, which needs to get through NEW. I'm not yet a DD, so I'm hoping my Application Manager will be willing to sponsor an upload of notcurses 3.0.0 to NEW. Once it gets there, I'll upload the new growlight as part of the library transition. I think this all ought happen within 30 days, but feel free to ping. signature.asc Description: PGP signature
Bug#997845: (no subject)
i'm not sure whether the "forwarded" tag applies in this case, but i've created an upstream bug (i am the upstream author) at https://github.com/dankamongmen/growlight/issues/153. signature.asc Description: PGP signature
Bug#997845: (no subject)
Package: growlight Version: 1.2.37-2 Tags: upstream Yep, I'm looking into it. For whatever reason, it's not exiting despite input having ended. I've tried reproducing this failure locally, but have not yet been able. I hope to fix it for 1.2.38. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
Bug#982786: growlight: autopkgtest regression
hurrah, it would appear that 1.2.31 is running successfully on the autopkgtest servers (all show as passed save ppc64el, which shows as passed here: https://ci.debian.net/packages/g/growlight/testing/ppc64el/).
Bug#982786: growlight: autopkgtest regression
ok, the good news is that with 1.2.30, we're no longer seeing the segfault. the bad news is that we error out due to an inability to load up notcurses without a TERM variable. the proper fix for this is to avoid using notcurses in any case where we're not connected to a tty. i can get this done today, but it will be a slightly more invasive patch (~20 lines, i would guess). it'll still be tightly targeted at this problem. once again, this is a use case that doesn't really reflect how the tool would be used, and while it's a real regression, it is being highlit primarily due to how the autopkgtests are run. i don't want to disable the autopkgtests, but i also don't want to get bounced from the release due to this. my plan is to address this today, cut it as 1.2.31, and upload it to unstable. sorry for the churn during soft freeze. =[
Bug#982786: growlight: autopkgtest regression
alright, with 1.2.30 (1.2.29 was never released), we pass the autopkgtests, huzzah.
Bug#982786: growlight: autopkgtest regression
not so fast! while this does indeed fix the segfault when run without TERM, i still get an autopkgtest failure, this one tracked down to stdout being redirected =[. so i'm gonna address that as well. how embarrassing.
Bug#982786: growlight: autopkgtest regression
Here's the upstream bug: https://github.com/dankamongmen/growlight/issues/139 Here's the (obvious, trivial) fix: https://github.com/dankamongmen/growlight/commit/297f487a8be84441ff75a22b5fa63305931cae70 A real brown-bagger =[. I'm going to cut 1.2.29 and upload it to unstable. If I ought prepare this patch as a debian patch for testing, as said, I can do that as well. Otherwise, I'm perfectly content to let this flow through unstable->testing.
Bug#982786: growlight: autopkgtest regression
Alright, I've got it locked down to the absence of a TERM environment variable in the autopkgtest environment. If I run the same command outside of autopkgtest, after running `unset TERM`, i get the exact same failure. So, this failure is IMHO definitely worth fixing, and I intend to do so now, but this is also a very atypical configuration. Users will generally have a TERM environment variable. I.e., I do not think this would have been reported as a bug were it not for the test. So hopefully this won't be a problem despite soft freeze. I'm preparing the fix now. Thanks to Antonio Terceiro and Daniel Leidert for their assistance on debian-devel in working with autopkgtest/debci! I really appreciate it.
Bug#982786: growlight: autopkgtest regression
I can now reproduce this locally, and expect to have a fix this evening. I've looked over the rules for the Soft Freeze, and understand that it'll be acceptable to cut a new upstream release (I'm the upstream author) with this fix only (there have been no other changes since this release), upload that to unstable, and let it proceed (possibly slowly) to testing. If I instead need to make a debian-specific patch against 1.2.28-1, and release it as 1.2.28-2, that's also fine.
Bug#982786: growlight: autopkgtest regression
Thanks for the heads-up; glad I've got those autopkgtests. Looking into this now with the hope of fixing it ASAP.
Bug#975432: growlight: autopkgtest failures
it looks like 1.2.24-1 has fixed at least the amd64 autopkgtests. i'm waiting on the other architectures, but it looks like we'll be able to close this. signature.asc Description: PGP signature
Bug#975432: 975...@bugs.debian.org
I believe this to be fixed by the 1.2.24 package I uploaded earlier today. The problem came down to lack of swap support on the machine(s) on which the tests were running. /proc/swaps doesn't exist on such a machine, and growlight thus aborted in startup. Growlight is now resistant to this class of issues. I expect 1.2.24 to fix this, but won't be sure until it runs. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
Bug#975432: growlight: autopkgtest failures
With 1.2.22-1, we've got e.g.: Processing triggers for libc-bin (2.31-4) ... (Reading database ... 14094 files and directories currently installed.) Removing autopkgtest-satdep (0) ... autopkgtest [06:16:57]: test blockdev-nonroot: echo "blockdev -v" | growlight-readline --notroot autopkgtest [06:16:57]: test blockdev-nonroot: [--- bash: line 1: growlight-readline: command not found autopkgtest [06:16:57]: test blockdev-nonroot: ---] autopkgtest [06:16:58]: test blockdev-nonroot: - - - - - - - - - - results - - - - - - - - - - blockdev-nonroot FAIL non-zero exit status 127 autopkgtest [06:16:58]: summary blockdev-nonroot FAIL non-zero exit status 127 the prior test is blockdev (note the lack of -nonroot), which apparently succeeds. does the non-root user (i.e. the user the tests run as in the absence of the "needs-root" restriction) possibly lack /usr/sbin in its PATH? that would explain this failure. i'll look into it and hopefully have this resolved shortly.
Bug#975082: [PATCH] patch for snd-20.9 for notcurses 2.0.7
As requested, here's a patch that gets snd-20.9 as packaged in
Debian's snd_20.9-1 to compile with Notcurses 2.0.7. Since
there's no version less than 2.0.7 in Debian, there's no need to
do the fine-grained comparisons the upstream author is doing.
The next release from upstream will have a native solution to
this, at which point this patch can be dropped. I'm sorry for
the inconvenience!
[schwarzgerat](0) $ cat notcurses2.diff
diff -ur snd-20.9-a/notcurses_s7.c snd-20.9-b/notcurses_s7.c
--- snd-20.9-a/notcurses_s7.c 2020-11-22 05:02:25.0 -0500
+++ snd-20.9-b/notcurses_s7.c 2020-11-24 04:58:19.984208602 -0500
@@ -1014,7 +1014,7 @@
return(s7_car(args));
}
-#if NOTCURSES_2_0_5
+#if NOTCURSES_2
static s7_pointer g_ncplane_options_x(s7_scheme *sc, s7_pointer args)
{
return(s7_make_integer(sc, ((ncplane_options *)s7_c_pointer_with_type(sc,
s7_car(args), ncplane_options_symbol, __func__, 1))->x));
@@ -1635,7 +1635,7 @@
{
ncplane_options nopts = {
.y = yoff,
-#if NOTCURSES_2_0_5
+#if NOTCURSES_2
.x = xoff,
#else
.horiz = {
[schwarzgerat](0) $
--
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.
diff -ur snd-20.9-a/notcurses_s7.c snd-20.9-b/notcurses_s7.c
--- snd-20.9-a/notcurses_s7.c 2020-11-22 05:02:25.0 -0500
+++ snd-20.9-b/notcurses_s7.c 2020-11-24 04:58:19.984208602 -0500
@@ -1014,7 +1014,7 @@
return(s7_car(args));
}
-#if NOTCURSES_2_0_5
+#if NOTCURSES_2
static s7_pointer g_ncplane_options_x(s7_scheme *sc, s7_pointer args)
{
return(s7_make_integer(sc, ((ncplane_options *)s7_c_pointer_with_type(sc, s7_car(args), ncplane_options_symbol, __func__, 1))->x));
@@ -1635,7 +1635,7 @@
{
ncplane_options nopts = {
.y = yoff,
-#if NOTCURSES_2_0_5
+#if NOTCURSES_2
.x = xoff,
#else
.horiz = {
Bug#975432: growlight: autopkgtest failures
Thanks for the report. I was aware of the autopkgtest failures, but didn't realize that a failure there prevented migration. This failure seems a property of the autopkgtest environment, and has thus proved difficult to debug without a release. The upcoming 1.2.21 release has added diagnostics to help investigate this issue; I'll go ahead and cut that release. I don't see any means by which a test can be marked ignore/flakey in the autopkgtest syntax, which seems unfortunate (right now, I'm trying to debug this failure in the specific autopkgtest environment; the test works fine on my setup and any other installed setup I can find). Do you have any suggestions? I could put a || true on Test-Command, but I'd rather use an idiom that we can search for etc.
Bug#974918: libnotcurses2,libnotcurses++2: missing Breaks+Replaces: libnotcurses1/libnotcurses++1 (>= 2)
> That would have been sufficient for the file conflict, but I assumed > that the forgotten soname bump makes lib*1 (>= 2) not neccessarily > broken, but at least undesired versions. makes sense. thanks for the explanation, and thanks once again for the bug report and your well-known vigilance!
Bug#974918: libnotcurses2,libnotcurses++2: missing Breaks+Replaces: libnotcurses1/libnotcurses++1 (>= 2)
I've just uploaded 2.0.4+dfsg.1-3, which I believe fixes this issue. It ought be available within a few hours. I believe that the version constraints could have been tightened to (>= 2.0.4), but I didn't see this as adding particularly much value. Thanks as always for filing these bugs, Andreas! You're the real MVP.
Bug#974918: libnotcurses2,libnotcurses++2: missing Breaks+Replaces: libnotcurses1/libnotcurses++1 (>= 2)
Confirmed, fixing now. I'll upload 2.0.4+dfsg.1-3 with this fix present shortly (probably this evening). Thanks once again for the heads-up, and sorry for the mistake!
Bug#966500: python3-notcurses: missing Breaks+Replaces: notcurses-bin (<< 1.6)
pending thanks ok, I believe i have solved this. the problem arose when i moved notcurses-pydemo from notcurses-bin to python3-notcurses sometime since 1.5.1. so: * i've added the necessary Breaks+Replace to debian/control, and have built this as 1.6.9+dfsg.1-3. it ought remedy the reported problem. i have made them available at: https://www.dsscaw.com/repos/apt/debian/pool/main/n/notcurses/ i'll almost certainly be cutting 1.6.10 today or tomorrow, so i'm inclined to wait until then, and get this all into one release (especially since I can't yet upload my own packages, and must harass my Sponsor to do so). if a DD would like to upload the 1.6.9+dfsg.1-3 packages i've prepared before then, email me, and we can do that. Andreas, if a fix tomorrow or the next day isn't fast enough, let me know and I can push on the 1.6.9+dfsg.1-3. thanks!
Bug#966500: python3-notcurses: missing Breaks+Replaces: notcurses-bin (<< 1.6)
#thanks Thank you for filing my first Debian bug! How exciting, and at the same time embarrassing. I should have caught this before uploading. A fix is obvious, and I ought be able to accomplish it within the Debian packaging proper, rather than requiring a new release (I'm the upstream author). Expect a +dfsg.1-3 built very soon. I'm not yet even a DM, so I'll have to wait on a DD to upload the new build to the archive. I'll provide a link here, and poke one of my sponsors.
Bug#945047: Needs dependency for Crypt/Digest/SHA256.pm
Package: extrepo Version: 0.2 Followup-For: Bug #945047 Just confirming that libcryptx-perl does indeed fix the issue. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.3.11nlb (SMP w/20 CPU cores) 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=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages extrepo depends on: ii gpgv 2.2.17-3 ii libwww-perl 6.41-1 ii libyaml-perl 1.29-1 ii perl 5.30.0-9 extrepo recommends no packages. extrepo suggests no packages. -- Configuration Files: /etc/extrepo/config.yaml changed [not included] -- no debconf information
Bug#839767: ncmpcpp fails to start due to undefined symbol in binary
Package: ncmpcpp Version: 0.7.4-1 Followup-For: Bug #839767 I rebuilt the source package against current libtag, and it works once more. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/8 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 ncmpcpp depends on: ii libboost-filesystem1.61.0 1.61.0+dfsg-2.1+b1 ii libboost-locale1.61.0 1.61.0+dfsg-2.1+b1 ii libboost-program-options1.61.0 1.61.0+dfsg-2.1+b1 ii libboost-regex1.61.01.61.0+dfsg-2.1+b1 ii libboost-system1.61.0 1.61.0+dfsg-2.1+b1 ii libboost-thread1.61.0 1.61.0+dfsg-2.1+b1 ii libc6 2.24-3 ii libcurl3-gnutls 7.50.1-1 ii libfftw3-double33.3.5-1 ii libgcc1 1:6.2.0-5 ii libicu5757.1-4 ii libmpdclient2 2.9-1 ii libncursesw56.0+20160917-1 ii libreadline77.0-1 ii libstdc++6 6.2.0-5 ii libtag1v5 1.11+dfsg.1-0.2 ii libtinfo5 6.0+20160917-1 ncmpcpp recommends no packages. Versions of packages ncmpcpp suggests: ii desktop-file-utils 0.23-1 ii mpd 0.19.19-1 -- no debconf information
Bug#801430: aptitude: segfault maybe casued by package dependency loop aptitudeDepCache::internal_mark_delete loop here
I can confirm that 0.7.4 fixes the issue I reported. Good work. -- nick black -=- http://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
Bug#801430: aptitude: segfault maybe casued by package dependency loop aptitudeDepCache::internal_mark_delete loop here
if you want me to pull something and test it, i ought be able to within a day or so. -- nick black -=- http://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
Bug#801430: aptitude: segfault maybe casued by package dependency loop aptitudeDepCache::internal_mark_delete loop here
As a datum (I reported a duplicate of this bug as 801488), I removed both libxmlrpc-lite-perl and libsoap-lite-perl, and still see the crash. So I don't think they're to blame, as asserted earlier on this bug. They also would seem unlikely causes for the gdb/valgrind output I reported in that bug. -- nick black -=- http://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
Bug#801430: aptitude: segfault maybe casued by package dependency loop aptitudeDepCache::internal_mark_delete loop here
As a datum (I reported a duplicate of this bug as 801488), I removed both libxmlrpc-lite-perl and libsoap-lite-perl, and still see the crash. So I don't think they're to blame, as asserted earlier on this bug. They also would seem unlikely causes for the gdb/valgrind output I reported in that bug. -- nick black -=- http://www.nick-black.com to make an apple pie from scratch, you need first invent a universe.
Bug#787638: Acknowledgement (php5-curl: php segfaults immediately with php5-curl installed)
looks like this got resolved with the 7.42.1-2+b1 libcurl3-gnutls update that just rolled down. i can verify this update fixed things for me. -- nick black -=- http://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#787638: php5-curl: php segfaults immediately with php5-curl installed
Package: php5-curl
Version: 5.6.9+dfsg-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
This morning, I upgraded my unstable i386-on-x86_64 installation. This
pulled in new gnutls 3.3.15-5, and also gcc-5-base 5.1.1-9 and python3.4
(i doubt these last two are relevant). Full aptitude logs are below.
Following this upgrade, I started receiving notifications that php jobs
run from cron were failing. Indeed, running the "php" binary (linked
through alternatives to /usr/bin/php5) segfaulted. I ran an ltrace on
the binary, and determined it was segfaulting while dlopen()ing curl.so
from /usr/lib/php5/20131226/. I removed php5-curl, and the issue went away.
Reinstalling php5-curl reproduces the behavior immediately:
[vps](0) $ php
Segmentation fault
[vps](139) $ ltrace php 2>&1 | tail
strlen("/usr/lib/php5/20131226") = 22
memcpy(0xf505813c, "/usr/lib/php5/20131226", 22) = 0xf505813c
__ctype_b_loc() = 0xf50946ac
memcpy(0xf5058152, "/", 1) = 0xf5058152
__ctype_b_loc() = 0xf50946ac
strlen("curl.so")= 7
memcpy(0xf5058153, "curl.so", 7) = 0xf5058153
dlopen("/usr/lib/php5/20131226/curl.so", 266
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
[vps](0) $
Again, this started following an update that directly affected no php
packages. Here's the aptitude logs:
==
Aptitude 0.6.11: log report
Wed, Jun 3 2015 08:41:06 -0700
IMPORTANT: this log only lists intended actions; actions which fail due to
dpkg problems may not be completed.
Will install 36 packages, and remove 0 packages.
5,082 kB of disk space will be used
===
[INSTALL, DEPENDENCIES] libhogweed4:i386
[UPGRADE] gcc-5-base:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] gnupg-agent:i386 2.0.27-2 -> 2.0.28-1
[UPGRADE] gnupg2:i386 2.0.27-2 -> 2.0.28-1
[UPGRADE] gnutls-bin:i386 3.3.15-2 -> 3.3.15-5
[UPGRADE] lib64atomic1:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] lib64cilkrts5:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] lib64gcc1:i386 1:5.1.1-8 -> 1:5.1.1-9
[UPGRADE] lib64gomp1:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] lib64itm1:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] lib64quadmath0:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] lib64stdc++6:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] lib64ubsan0:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libatomic1:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libcilkrts5:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libgcc1:i386 1:5.1.1-8 -> 1:5.1.1-9
[UPGRADE] libgfortran3:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libgnutls-deb0-28:i386 3.3.15-2 -> 3.3.15-5
[UPGRADE] libgomp1:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libitm1:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libpython3.4-minimal:i386 3.4.3-6 -> 3.4.3-7
[UPGRADE] libpython3.4-stdlib:i386 3.4.3-6 -> 3.4.3-7
[UPGRADE] libquadmath0:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libstdc++6:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libubsan0:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libx32atomic1:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libx32cilkrts5:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libx32gcc1:i386 1:5.1.1-8 -> 1:5.1.1-9
[UPGRADE] libx32gomp1:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libx32itm1:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libx32quadmath0:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libx32stdc++6:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] libx32ubsan0:i386 5.1.1-8 -> 5.1.1-9
[UPGRADE] python3.4:i386 3.4.3-6 -> 3.4.3-7
[UPGRADE] python3.4-minimal:i386 3.4.3-6 -> 3.4.3-7
[UPGRADE] ufraw-batch:i386 0.20-2 -> 0.20-3
===
Log complete.
==
Note the upgrade of various core libraries, though not libc6. I am using
libcurl3-gnutls (as opposed to libcurl3-openssl), and figure the
libgnutls update might have broken things here.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (990, 'unstable')
Architecture: i386 (x86_64)
Kernel: Linux 3.18.5-x86_64-linode52 (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 php5-curl depends on:
ii dpkg 1.18.1
ii libc6 2.19-18
ii libcurl3 7.42.1-2
ii php5-common [phpapi-20131226] 5.6.9+dfsg-1
ii ucf3.0030
php5-curl recommends no packages.
php5-curl suggests no packages.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687378:
Here's another example of crosslinked entries: ╭[virtual]─[-]─╮ │╭╮│ ││Bind devices to the new aggregate. To be eligible, a device must either be ││ ││unpartitioned, or be a partition having the appropriate component type. The ││ ││device furthermore must not have a valid filesystem signature. ││ │╰──╭select aggregate components───╮ │ active└┤Linux mdadm │╭ ╮ │ │ md127┌───│ 1 sdo1 pci-:04:00.0-scsi-0:0:0:0-part1 │ │ raid6│ 1│ 2 sdn pci-:04:00.0-scsi-0:0:0:0 │ │ 1-degraded└┤Linux mdadm │ 3│ │ loop4 n/a │ 4│ │ loop6 n/a │╰ ╯ │ │ loop7 n/a ╰──'C' confirms setup, ⎋esc returns╯ so, i rebuilt using both udev 85 (the most recent pure udev release) and udev 189 (the most recent release since the merge with systemd). in both cases, straight SATA devices are not listed in /dev/disk/by-path at all. examining the diff i posted above, apparently the crosslinking had been noticed by udev maintainers, and thus they disabled by-path link generation for all ATA devices(!) as i noted earlier, it seems we can construct unambiguous, meaningful ATA links. do you agree? if so, what would your feelings be on such a patch? i've been running this down by myself, but in order to proceed further, i'd at this point appreciate a reply from the package maintainer. Marco, could you look at this and record your thoughts? thanks so much. --nick
Bug#687378:
This issue is also being tracked on Sprezzabugs, the SprezzOS bug tracker: https://www.sprezzatech.com/bugs/show_bug.cgi?id=358 -- nick black -- http://www.sprezzatech.com -- unix/hpc consulting "if you want to make an apple pie from scratch, you must first invent a universe." -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687378:
A diff (ignoring whitespace) of the builtin-path_id.c in Debian's 175 and the
upstream 182 is attached. The following looks possibly relevant:
@@ -322,19 +317,6 @@
goto out;
}
-/*
- * We do not support the ATA transport class, it creates
duplicated link
- * names as the fake SCSI host adapters are all separated, they are all
- * re-based as host == 0. ATA should just stop faking two duplicated
- * hierarchies for a single topology and leave the SCSI stuff alone;
- * until that happens, there are no by-path/ links for ATA
devices behind
- * an ATA transport class.
- */
-if (strstr(name, "/ata") != NULL) {
-parent = NULL;
-goto out;
-}
-
parent = handle_scsi_default(parent, path);
out:
return parent;
I noticed that udev-182 was released five months ago. Is there a particular
reason why Debian's shipping 175?
I will rebuild udeb-175 with the attached diff and see if that solves
the problem.
--
nick black -- http://www.sprezzatech.com -- unix/hpc consulting
"if you want to make an apple pie from scratch,
you must first invent a universe."
175-vs-182.diff
Description: Binary data
Bug#687378:
OK, yeah, the issue is that while the P-record for /sys/block/* entries has sufficient information to discriminate between devices, it's not all making its way into the ID_PATH variable off which the /dev/disks/by-path entry is constructed. I've got two devices in my virtual machine: P: /devices/pci.00/:00:01.1/ata2/host1/target1:0:1/1:0:1:0/block/sdc P: /devices/pci.00/:00:01.1/ata1/host0/target0:0:1/0:0:1:0/block/sdb they both get ID_PATH=pci-:00:01.1-scsi-0:0:1:0 ID_PATH_TAG=s/ID_PATH/:/_/g losing the difference. on my workstation, the devices on my 8-port SAS card are properly differentiated, as are those on my on-board intel and marvell sata. i've also got two marvell pcie sata cards, though, and there we again see the ID_PATH folding down. P: /devices/pci.00/:00:1f.2/ata2/host2/target2:0:0/2:0:0:0/block/sdj P: /devices/pci.00/:00:1f.2/ata1/host1/target1:0:0/1:0:0:0/block/sdi both going to ID_PATH=pci-:00:1f.2-scsi-0_0_0_0 looks like including the ata/host/target information would be necessary and sufficient to resolve this issue. -- nick black -- http://www.sprezzatech.com -- unix/hpc consulting "if you want to make an apple pie from scratch, you must first invent a universe." -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687378:
More info on this: I've tracked it back to at least ID_PATH/ID_PATH_TAG using udevadm. By the time those two variables are assigned, different devices are already colliding. I think I'll be able to work out the problem just tracking down source with this info. -- nick black -- http://www.sprezzatech.com -- unix/hpc consulting "if you want to make an apple pie from scratch, you must first invent a universe." -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687378: udev: /dev/disk/by-path is missing entries and has incorrect entries
Package: udev Version: 175-7 Severity: grave Tags: d-i Justification: causes non-serious data loss Dear Maintainer, I have experienced problems with udev's creation of links in /dev/disk/by-path on multiple machines (real and virtual) including missing links and incorrect links (ie, two partition-type links having the same path up through partition number, but pointing to different drives). This latter issue is of grave concern, since anyone using /dev/disk/by-path runs a chance of operating on the wrong block device (this almost happened to me). The gravity of this situation is increased due to at least ZoL (ZFS on Linux) recommending that /dev/disk/by-path naming be used for zpool creation; they're also plausibly used in /etc/fstab etc. I can trivially reproduce the problem by launching a KVM with three virtual disks ala (for some disk image passed as $1) KVMOPTS="$KVMOPTS -drive file=$1-1 -drive file=$1-2" kvm --hda "$1" -drive file="$2",if=none,id=b,boot=on -m $MEM -usb -device usb- storage,drive=b $KVMOPTS sda and sdb will have valid links in /dev/disk/by-path, while sdc will not have a link. a more complex example, illustrating the dangerous crosslinking, can be found here: https://groups.google.com/a/zfsonlinux.org/forum/?fromgroups=#!search/by-path /zfs-devel/gQ5jzweYqYU/RMXiBM3x-8oJ there's extensive logging and discussion in that thread. I'm using a custom 3.5.3 kernel. I can and will try with a default Debian kernel, but wanted to get the ball rolling on this. Thanks! -- System Information: Debian Release: turing-β/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.5.3 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages udev depends on: ii debconf [debconf-2.0] 1.5.46 ii libc6 2.13-35 ii libselinux12.1.9-5 ii libudev0 175-7 ii lsb-base 4.1+Debian7 ii procps 1:3.3.3-2 ii util-linux 2.21.793-2 Versions of packages udev recommends: ii pciutils 1:3.1.9-5 ii usbutils 1:005-3 udev suggests no packages. -- debconf information: udev/new_kernel_needed: false udev/title/upgrade: udev/reboot_needed: udev/sysfs_deprecated_incompatibility: -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#671695: fuseiso9660: copies from fuseiso9660 mount aren't reliable
Package: fuseiso9660 Version: 0.2b-1.1 Severity: grave Tags: upstream Justification: causes non-serious data loss Dear Maintainer, I am using fuseiso9660 for the creation of my modified debian-installer ISO. simple-cdd creates a standard debian unstable netboot installer ISO, which I then mount as a FUSE-capable user. I copy files from the FUSE mount into a new directory, from which I make a new CD (using grub-mkrescue). I was getting regular MD5 errors upon unpacking udebs from the CD (installer step, "Load installer components from CD"). I checked, and the MD5s were indeed incorrect on many of the new ISO's packages. I verified that this was occurring before running grub-mkrescue and after running simple-cdd -- that is, when copying from the fuseiso9660 mount. I then added the following options to fuseiso9660: -s -o noauto_cache,read_sync all problems went away immediately and reliably. I'm not yet sure which of these options are necessary, but all three together definitely work. This can introduce data loss if the user assumes the copies have been performed with fidelity, and removes the original media. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.3.4 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages fuseiso9660 depends on: ii fuse-utils2.8.7-2 ii libc6 2.13-32 ii libcdio10 0.81-5 ii libfuse2 2.8.7-2 ii libiso9660-7 0.81-5 ii libumlib0 0.6-1 ii zlib1g1:1.2.7.dfsg-1 fuseiso9660 recommends no packages. fuseiso9660 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#643304: stat output
Jakub Wilk left as an exercise for the reader:
> Did you create the symlink manually, perhaps following the "advice"
> from <http://bugs.debian.org/634684#10>?
this was precisely the issue. thanks!
--
nick black
"A main cause of the Roman Empire's fall was that–lacking zero–they had
no way to indicate successful termination of their C programs."
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#643304: python-awn-extras: can't install: unable to open '/usr/share/pyshared/awn/extras/__init__.py.dpkg-new'
Package: python-awn-extras
Version: 0.4.0-3.1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I attempted to upgrade to AWN 4.0.4 in sid. All my other packages are
up to date. python-awn-extras fails to install with the following
message:
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
(Reading database ... 336028 files and directories currently installed.)
Unpacking python-awn-extras (from .../python-awn-extras_0.4.0-4_amd64.deb) ...
dpkg: error processing
/var/cache/apt/archives/python-awn-extras_0.4.0-4_amd64.deb (--unpack):
unable to open '/usr/share/pyshared/awn/extras/__init__.py.dpkg-new': No such
file or directory
configured to not write apport reports
The package, and thus awn-python-applets-{core, extras}, cannot be installed.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.0.4 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages python-awn-extras depends on:
ii python 2.6.7-3
ii python-support 1.0.14
python-awn-extras recommends no packages.
python-awn-extras suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#533362: [Pkg-ia32-libs-maintainers] Bug#533362: ia32-libs uninstallable against libc6 2.9-15
Goswin von Brederlow left as an exercise for the reader:
> Nick Black writes:
>
> > Package: ia32-libs
> > Version: 2.7
> > Severity: grave
> > Justification: renders package unusable
> >
Thanks for the explanation, Goswin. Feel free to close this at your
discretion (you might want to leave it open so reportbug and friends see
it?).
--
Nick Black
Principal Engineer, McAfee
Grad student, GT College of Computing
Khalepa ta kala; per ardua, ad astra.
signature.asc
Description: Digital signature
Bug#533362: ia32-libs uninstallable against libc6 2.9-15
Package: ia32-libs Version: 2.7 Severity: grave Justification: renders package unusable Howdy! Yesterday, I upgraded to libc6 et al 2.9-14. Upon doing so, ia32-libs becomes uninstallable, until libc6 is backed down to 2.9-13. Today's 2.9-15 libc6 release does not solve the problem. As a result, 32-bit ELF binaries cannot be built on amd64 unstable without pinning libc6 to 2.9-13. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (990, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ia32-libs depends on: ii dpkg 1.15.2Debian package management system ii lib32asound2 1.0.20-2 shared library for ALSA applicatio ii lib32gcc1 1:4.4.0-6 GCC support library (32 bit Versio ii lib32ncurses5 5.7+20090523-1shared libraries for terminal hand ii lib32stdc++6 4.4.0-6 The GNU Standard C++ Library v3 (3 ii lib32z11:1.2.3.3.dfsg-13 compression library - 32 bit runti ii libc6-i386 2.9-13GNU C Library: 32bit shared librar ii lsb-release3.2-22Linux Standard Base version report ia32-libs recommends no packages. Versions of packages ia32-libs suggests: pn ia32-libs-gtk (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
