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]
i'm tracking this upstream at
https://github.com/dankamongmen/notcurses/issues/2645
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.
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.
> 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
.
+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
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
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
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.
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
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
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.
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
thanks, this ought be fixed in an hour or two.
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
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
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
> 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
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
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
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
you are correct in all of your assumptions =].
signature.asc
Description: PGP signature
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
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
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
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
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/).
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
alright, with 1.2.30 (1.2.29 was never released), we pass the
autopkgtests, huzzah.
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.
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
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,
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
Thanks for the heads-up; glad I've got those autopkgtests. Looking into this
now with the hope of fixing it ASAP.
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
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.
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
), 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 n
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
> 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!
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!
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!
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
#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).
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
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)
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.
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.
.
--
nick black -=- http://www.nick-black.com
to make an apple pie from scratch, you need first invent a universe.
.
--
nick black -=- http://www.nick-black.com
to make an apple pie from scratch, you need first invent a universe.
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).
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
Here's another example of crosslinked entries:
╭[virtual]─[-]─╮
│╭╮│
││Bind devices to the new aggregate. To be eligible, a device must either be ││
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
/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
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
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
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
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
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 nbl...@nvidia.com
A main cause of the Roman
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
Goswin von Brederlow left as an exercise for the reader:
Nick Black d...@qemfd.net 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
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
63 matches
Mail list logo
