Bug#1016732: node-sockjs throws: TypeError: Cannot read properties of undefined (reading 'addEventListener') at WebSocketReceiver.setUp
On 06/08/2022 14:59, Nilesh Patra wrote: Yadd, Since you added in coffeescript patch for this package, I'd highly appreciate if you could consider taking a look. Hi, is there a test somewhere to see this error ?
Bug#968670: src:liboqs/0.7.2~rc1-1 not affected by #968670
Control: affects - src:liboqs Hello, src:liboqs/0.7.2~rc1-1 is no longer affected by this bug anymore. Andrius
Bug#1016771: nmu: liboqs_0.7.2~rc1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hello, I want to request binNMU on amd64 for recently accepted new package. nmu liboqs_0.7.2~rc1-1 . amd64 . unstable . -m "Rebuild on buildd" Thanks, Andrius
Bug#983146: 983146 RFS: bung/3.2.6-3 [ITP] -- backup next generation
Dear Bastian I have uploaded a fixed version to https://mentors.debian.net/package/bung, The QA information now shows + Package uses debhelper-compat + Package is the latest upstream version + Package is not native – "Maintainer" email is the same as the uploader – Package has lintian errors bung [I class items snipped] E source-is-missing [usr/share/doc/bung/Backup scripts next generation 3.2.x User Guide.htm] P very-long-line-length-in-source-file [several, only for .odt and .pdf files] [X class items snipped] + Package closes ITP bug – No VCS field present – Package is not in Debian – Upstream-Contact missing from d/copyright I do not understand the E class item. "usr/share/doc/bung/Backup scripts next generation 3.2.x User Guide.htm" is present in bung_3.2.6.orig.tar.gz Is there anything else you need me to fix? Best Charles
Bug#1016770: module does not build
package: apfs-dkms
version: 0+git20220214+ds-2
Hi,
The module does not build with kernel 5.18.0.
Here is the failure message:
/var/lib/dkms/linux-apfs-rw/0+git20220214+ds-2/build/inode.c:524:10:
error: ‘const struct address_space_operations’ has no member named
‘invalidatepage’; did you mean ‘invalidate_folio’?
524 | .invalidatepage = apfs_noop_invalidatepage,
| ^~
| invalidate_folio
/var/lib/dkms/linux-apfs-rw/0+git20220214+ds-2/build/inode.c:524:27:
error: initialization of ‘sector_t (*)(struct address_space *,
sector_t)’ {aka ‘long long unsigned int (*)(struct address_space *, long
long unsigned int)’} from incompatible pointer type ‘void (*)(struct
page *, unsigned int, unsigned int)’
[-Werror=incompatible-pointer-types]
524 | .invalidatepage = apfs_noop_invalidatepage,
| ^~~~
/var/lib/dkms/linux-apfs-rw/0+git20220214+ds-2/build/inode.c:524:27:
note: (near initialization for ‘apfs_aops.bmap’)
CC [M] /var/lib/dkms/linux-apfs-rw/0+git20220214+ds-2/build/namei.o
cc1: some warnings being treated as errors
make[1]: ***
[/usr/src/linux-headers-5.18.0-3-common/scripts/Makefile.build:294 :
/var/lib/dkms/linux-apfs-rw/0+git20220214+ds-2/build/inode.o] Erreur 1
make[1]: *** Attente des tâches non terminées
make: *** [/usr/src/linux-headers-5.18.0-3-common/Makefile:1862 :
/var/lib/dkms/linux-apfs-rw/0+git20220214+ds-2/build] Erreur 2
make : on quitte le répertoire « /usr/src/linux-headers-5.18.0-3-amd64 »
Bug#1016769: ITP: elpa-snakemake -- support for editing and running snakemake files in emacs
Package: wnpp Owner: Diane Trout Severity: wishlist * Package name: elpa-snakemake Version : 2.0.0 Upstream Author : Kyle Meyer * URL or Web page : https://git.kyleam.com/snakemake-mode/about * License : GPL-3+ Description : support for editing and running snakemake files in emacs The source repository is broken up into providing two emacs packages. One snakemake.el provides support for running snakemake in an emacs transient mode, the other snakemake-model.el adds syntax highlighting for editing snakemake files within emacs.
Bug#805357: cups-pdf: Print job with multiple input files doesn't work
Control: found 805357 3.0.1-14 Got bit by this on bullseye cups + (backported) sid cups-pdf. In this case i can only reproduce this with a postscript file, I'm using the attached one: specifying it thrice hangs the PDF process below cupsd -l; I managed to unstick it by removing the respective /var/spool/cups/d$job-* files and restarting cups.service. In the case of attached, the output (when using just one) is horrifically mangled, as compared to using something like gv(1) (or a plain gs -dSAFER -dBATCH -dNOPAUSE -r600 -sDEVICE=pdfwrite), but that's another issue, I'm assuming? Or is this some aspect of this postscript that explodes it both ways? Please advise. Best, наб p1-20.ps.Z Description: Binary data signature.asc Description: PGP signature
Bug#1016761: libhttp-daemon-perl: FTBFS with newer HTTP::Tiny versions
On Sat, 6 Aug 2022, gregor herrmann wrote: On Sat, 06 Aug 2022 21:24:08 +0300, Niko Tyni wrote: It looks like the recent security fix in libhttp-daemon-perl_6.14-1.1 (or at least the associated test case) has issues with newer versions of the HTTP::Tiny module. […] From my build log: Subroutine HTTP::Tiny::Handle::write_content_body redefined at t/content_length.t line 277. Oh, that is bad, shall these new tests better be disabled than? Thorsten
Bug#1016768: dino-im: please include patch to resolve known xmpp: links
Package: dino-im
Version: 0.3.0-2~bpo11+1
Severity: wishlist
Tags: patch
I authored a patch that resolves XMPP links (ie, xmpp:f...@bar.com) in
messages, if the body of the XMPP link match a user in the roster. The
upstream pull request is here - https://github.com/dino/dino/pull/1212
Upstream hasn't commented on the patch yet, and I'm trying to get it
upstream, but in the meantime I'd love to see it included in Debian.
I've been personally using this patch for 5 months now, and have had no
stability problems. If an XMPP link matches a user in the roster, a
roster contact display name is shown. If it doesn't match a roster
user, nothing is changed. It's not entirely complete (xmpp links in
notifications aren't resolved to roster names, for example), but it
makes using Dino with 3rd party services that use XMPP links a whole
lot nicer.
Please consider including it. I've attached the patch that I included
in my own builds at https://people.debian.org/~dilinger/dino-im/ , if
that's helpful.
>From ec2e6192d6cf01ab57326ac4cc9ffc99eae89f95 Mon Sep 17 00:00:00 2001
From: Andres Salomon
Date: Sat, 12 Mar 2022 17:23:14 -0500
Subject: [PATCH] Display friendlier xmpp: links when a jid is in the roster
In jabber chats, there may be cases where an xmpp link is a valid
jid that's in an account's roster. For example, Cheogram's jmp.chat
service uses xmpp: links to support SMS group chat over jabber. In
jmp.chat's case, that ends up looking like a message coming from a
jid that has combined multiple phone numbers with the format
"+11231231234,+13213214...@cheogram.com", and message body beginning
with " " or
" " (depending on which phone number
the message is coming from).
Those jids aren't particularly user-friendly, so we'd instead like to
display the roster name while still keeping the underlying link
clickable. In order to do that, we modify Util.parse_add_markup_theme()
(since that's where the html tag markup is created) to add a
callback function that takes a uri and returns what the tag
should display. If the callback returns null, we just stick with the
default behavior of just displaying the link. However, if the uri
includes a jid that's in the user's roster, we return the name that's
in the roster. Util.parse_add_markup_theme() then uses that returned
name in the tag.
A callback is used in order to keep the lookup generic, for future
uses. While the call to Util.parse_add_markup_theme() inside of
MessageItemWidget::generate_markup_text()'s non-muc code has a
callback that specifically only checks for xmpp: links, there's no
reason that it needs to be limited to that. It could handle any link;
for example, translating an http:// link to that same link but with
" (insecure)" appended to the end.
---
.../message_widget.vala | 12 ++-
main/src/ui/util/helper.vala | 31 ---
2 files changed, 31 insertions(+), 12 deletions(-)
--- a/main/src/ui/conversation_content_view/message_widget.vala
+++ b/main/src/ui/conversation_content_view/message_widget.vala
@@ -200,7 +200,17 @@ public class MessageItemWidget : SizeReq
if (conversation.type_ == Conversation.Type.GROUPCHAT) {
markup_text = Util.parse_add_markup_theme(markup_text, conversation.nickname, true, true, true, Util.is_dark_theme(this), ref theme_dependent);
} else {
-markup_text = Util.parse_add_markup_theme(markup_text, null, true, true, true, Util.is_dark_theme(this), ref theme_dependent);
+Util.LinkDisplay roster_lookup = (uri) => {
+string? s = null;
+if (GLib.Uri.parse_scheme(uri) == "xmpp") {
+try {
+Jid? j = new Jid(uri["xmpp:".length:uri.length]);
+s = Dino.get_real_display_name(stream_interactor, conversation.account, j);
+} catch (InvalidJidError e) { /* it's fine */ }
+}
+return s;
+};
+markup_text = Util.parse_add_markup_theme(markup_text, null, true, true, true, Util.is_dark_theme(this), ref theme_dependent, false, roster_lookup);
}
if (message.body.has_prefix("/me ")) {
--- a/main/src/ui/util/helper.vala
+++ b/main/src/ui/util/helper.vala
@@ -242,7 +242,9 @@ public static string parse_add_markup(st
return parse_add_markup_theme(s_, highlight_word, parse_links, parse_text_markup, parse_text_markup, false, ref ignore_out_var);
}
-public static string parse_add_markup_theme(string s_, string? highlight_word, bool parse_links, bool parse_text_markup, bool parse_quotes, bool dark_theme, ref bool theme_dependent, bool already_escaped_ = false) {
+public delegate string? LinkDisplay(string uri);
+
+public static string parse_add_markup_theme(string s_, string? highlight_word, bool parse_links, bool parse_text_markup, bool parse_quotes, bool dark_theme, ref bool theme_dependent, bool already_escaped_ = false,
Bug#1016391: bullseye-pu: libhttp-daemon-perl/6.12-1+deb11u1
On Sat, 6 Aug 2022, Adam D. Barratt wrote: Please go ahead. ... and uploaded. Thanks! Thorsten
Bug#884829: Still present in Debian 11
A small update: I managed to rebuild the xserver-xorg-core package with the patch applied, but the leak persists. So while it manifests the same way and can be triggered by the same application, my problem seems to have a different cause. On a second thought, it makes sense: if I understand it correctly, XAA, EXA, UXA etc. were replaced by Glamor in recent years. And from the Xorg log it seems that that's what my laptop uses (Intel HD 5500), so I should not experience any issues coming from the EXA code, right? I'm not very experienced with Valgrind, but I'll send an update if I manage to set it up and find anything of interest. Martin P.S. I had no clue about this transition to Glamor; Debian now generally works well out of the box, so I'm not learning about new stuff by constantly fixing stuff. :))
Bug#1016767: aardvark-dns: incomplete package description
Package: aardvark-dns Severity: normal X-Debbugs-Cc: dfo...@gmail.com Dear maintainer, I think that the description of this package is missing the word "Podman", where it says "...designed to work with but is..." the README.md says "...designed to work with Podman but is..." thanks for your work in Debian, Daniele
Bug#1016761: libhttp-daemon-perl: FTBFS with newer HTTP::Tiny versions
On Sat, 06 Aug 2022 21:24:08 +0300, Niko Tyni wrote:
> It looks like the recent security fix in libhttp-daemon-perl_6.14-1.1
> (or at least the associated test case) has issues with newer versions
> of the HTTP::Tiny module.
[…]
> From my build log:
>Subroutine HTTP::Tiny::Handle::write_content_body redefined at
> t/content_length.t line 277.
Just a quick note:
That's from debian/patches/CVE-2022-31081-testcase.patch:
#v+
+sub patch_http_tiny {
+
+# we need to patch write_content_body
+# this is part of HTTP::Tiny internal module HTTP::Tiny::Handle
+#
+# the below code is from the original HTTP::Tiny module, where just two
lines
+# have been commented out
+
+no strict 'refs';
+
+*HTTP::Tiny::Handle::write_content_body = sub {
+@_ == 2 || die(q/Usage: $handle->write_content_body(request)/ . "\n");
+my ($self, $request) = @_;
+
+my ($len, $content_length) = (0,
$request->{headers}{'content-length'});
+while () {
+my $data = $request->{cb}->();
+
+defined $data && length $data
+or last;
+
+if ( $] ge '5.008' ) {
+utf8::downgrade($data, 1)
+or die(qq/Wide character in write_content()\n/);
+}
+
+$len += $self->write($data);
+}
+
+# this should not be checked during our tests, we want to forge bad
requests
+#
+# $len == $content_length
+# or die(qq/Content-Length mismatch (got: $len expected:
$content_length)\n/);
+
+return $len;
+};
+}
#v-
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`-
signature.asc
Description: Digital Signature
Bug#1014705: xtables-addons 3.13-1+deb11u1 flagged for acceptance
package release.debian.org tags 1014705 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: xtables-addons Version: 3.13-1+deb11u1 Explanation: support both old and new versions of security_skb_classify_flow()
Bug#1015244: commons-daemon 1.0.15-8+deb11u1 flagged for acceptance
package release.debian.org tags 1015244 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: commons-daemon Version: 1.0.15-8+deb11u1 Explanation: fix JVM detection
Bug#1014315: dnsproxy 1.16-0.1+deb11u1 flagged for acceptance
package release.debian.org tags 1014315 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: dnsproxy Version: 1.16-0.1+deb11u1 Explanation: listen on localhost by defualt, rather than the possibly unavailable 192.168.168.1
Bug#1016766: gnome-initial-setup: Please upgrade to 43
Source: gnome-initial-setup Version: 42.2-1 Severity: wishlist Control: block -1 by 1016765 Packaging gnome-initial-setup 43 won't be possible until we get a gtk4 version of webkit2gtk. We can cherry-pick useful fixes (except for the switch to GTK4) to our gnome-initial-setup 42 series package. Thank you, Jeremy Bicha
Bug#1016765: webkit2gtk: Please enable gtk4 build
Source: webkit2gtk Version: 2.37.1-2 Severity: wishlist Please consider enabling the gtk4 build. It is required for gnome-initial-setup 43: https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/blob/master/NEWS On the other hand, I do understand that maintaining a 3rd full build (in addition to GTK3 4.0 and GTK3 4.1) is a lot. I'm ok with keeping gnome-initial-setup at version 42 for Debian 12 "Bookworm" if the extra build option isn't enabled in Debian for webkit2gtk 2.38. Epiphany 43 still uses GTK3 so it is not affected yet. Perhaps for Epiphany 44 next year. I am unaware of anything else using webkitgtk with gtk4 yet. gnome-control-center will depend on it too after a new gnome-online-accounts release with GTK4 support (unclear how long that will take). Thank you, Jeremy Bicha
Bug#1013732:
Dear Maintainer, please enable the CONFIG_IEEE80211AX option. WiFi-6 compatible USB WiFi Adapters like CF-953AX based on chipset mt7921au are now available and it would be unfortunate to keep requiring Debian users to recompile hostapd to use them. Thank you
Bug#1014705: bullseye-pu: package xtables-addons/3.13-1
Control: tags -1 -moreinfo +confirmed On Sat, 2022-08-06 at 20:57 +0100, Jeremy Sowden wrote: > On 2022-08-06, at 19:24:52 +0100, Adam D. Barratt wrote: > > Control: tags -1 + moreinfo > > > > On Sun, 2022-07-10 at 17:19 +0100, Jeremy Sowden wrote: > > > The related xtables-addons bug is: > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014680 > > > > > > [ Reason ] > > > xtables-addons-dkms and xtables-addons-source contain sources for > > > building > > > kernel modules with DKMS and module-assistant, respectively. The > > > 5.10.0-16 > > > kernel introduced in the 11.4 point release included a patch > > > back- > > > ported from > > > 5.11 to 5.10.121: > > > > > > > The metadata of #1014680 implies that it affects the package in > > unstable and is not yet fixed there - is that correct? If so, then > > the > > fix needs to happen in unstable first; if not, please add an > > appropriate fixed version to make the situation clearer. > > The problem arose because an API-changing patch was back-ported from > 5.11 to 5.10 and this was picked up by the kernel released in 11.4. > This part was clear... > The version of xtables-addons in unstable at the time 11.4 was > released > (3.19-1) supported the new API for kernel versions >= 5.11, and so > was > unaffected wrt. the kernel in unstable. > ...but this was not, at least to me, hence the question. Thanks for clarifying. > I have since uploaded the latest upstream release to unstable (3.21- > 1), > and that includes support for the problematic 5.10 kernels. The > patch I > have added in 3.13-1+deb11u1 is the one from upstream. I have added > a > fixed version to #1014680. > Thanks. > If you are happy to accept this change, is it a suitable candidate > for > stable-updates given that the package has been broken since 11.4 came > out? Potentially. Regards, Adam
Bug#1016672: grub2 2.06-3~deb11u1 flagged for acceptance
package release.debian.org tags 1016672 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: grub2 Version: 2.06-3~deb11u1 Explanation: new upstream release
Bug#1016037: libreoffice 7.0.4-4+deb11u2 flagged for acceptance
package release.debian.org tags 1016037 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: libreoffice Version: 7.0.4-4+deb11u2 Explanation: support EUR in .hr locale; add HRK<->EUR conversion rate to Calc and the Euro Wizard; security fixes [CVE-2021-25636 CVE-2022-26305 CVE-2022-26306 CVE-2022-26307]
Bug#1016655: dbus-broker 26-1+deb11u2 flagged for acceptance
package release.debian.org tags 1016655 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: dbus-broker Version: 26-1+deb11u2 Explanation: fix assertion failure when disconnecting peer groups; fix memory leak; fix null pointer dereference [CVE-2022-31213]
Bug#1016764: libzookeeper-mt-dev: zookeeper.jute.h missing
Package: libzookeeper-mt-dev Version: 3.8.0-6 Severity: important X-Debbugs-Cc: sor...@gmail.com Dear Maintainer, Neither libzookeeper-mt-dev nor libzookeeper-st-dev contain zookeeper.jute.h. Therefore no C/C++ code can be built that uses the zookeeper client library. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libzookeeper-mt-dev depends on: ii libzookeeper-mt2 3.8.0-6 libzookeeper-mt-dev recommends no packages. libzookeeper-mt-dev suggests no packages. -- no debconf information
Bug#1014705: bullseye-pu: package xtables-addons/3.13-1
On 2022-08-06, at 19:24:52 +0100, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Sun, 2022-07-10 at 17:19 +0100, Jeremy Sowden wrote: > > The related xtables-addons bug is: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014680 > > > > [ Reason ] > > xtables-addons-dkms and xtables-addons-source contain sources for > > building > > kernel modules with DKMS and module-assistant, respectively. The > > 5.10.0-16 > > kernel introduced in the 11.4 point release included a patch back- > > ported from > > 5.11 to 5.10.121: > > > > The metadata of #1014680 implies that it affects the package in > unstable and is not yet fixed there - is that correct? If so, then the > fix needs to happen in unstable first; if not, please add an > appropriate fixed version to make the situation clearer. The problem arose because an API-changing patch was back-ported from 5.11 to 5.10 and this was picked up by the kernel released in 11.4. The version of xtables-addons in unstable at the time 11.4 was released (3.19-1) supported the new API for kernel versions >= 5.11, and so was unaffected wrt. the kernel in unstable. I have since uploaded the latest upstream release to unstable (3.21-1), and that includes support for the problematic 5.10 kernels. The patch I have added in 3.13-1+deb11u1 is the one from upstream. I have added a fixed version to #1014680. If you are happy to accept this change, is it a suitable candidate for stable-updates given that the package has been broken since 11.4 came out? J. signature.asc Description: PGP signature
Bug#997024: [greek]babel + cleveref + Roman pagenumbering + label = ☇
Dear Toby, I greatly apologize for bothering you again on this issue (I believe having received no answer), and I hope this doesn't disturb you. Might I kindly ask you to look into https://bugs.debian.org/997024 and/or https://tex.stackexchange.com/questions/619875 ? Thanks in advance, Peter
Bug#1016369: IO::Handle ->error does not work, always saying "fine"
Niko Tyni writes ("Re: Bug#1016369: IO::Handle ->error does not work, always
saying "fine""):
> Hi, thanks Ian for the report and Damyan for looking into the issues.
Indeed, thanks to you and to Damyan.
> > > Actual output
> > >
> > > 0 Bad file descriptor
> > > 0 No space left on device
>
>
> FWIW I get
>
> 0 Is a directory
> 1 No space left on device
>
> on sid (perl_5.34.0-5). I'm not sure why you'd expect -1. The documentation
> for IO::Handle::error() only mentions it reporting a true value.
Interesting. I forget the details (can't easily check now) but some
test that passed for me gave -1. I agree that 1 is better.
> The first issue (reading a directory as a plain file) seems to be about
> the error flag getting cleared when reading past EOF or something like
> that.
I used reading from a directory as an example for two reason:
Firstly, it was the situation that actually happened to me. I was
writing a program and it had a bug that caused it to erroneously read
a directory, rather than some file within it. The program became
convinced the "file" was empty, leading to strange malfunctions. I
would have expected the file reading error checks ought to have
detected this earlier.
Secondly, having discovered this bug, reading from a directory is one
of very few ways to get something you can open() for reading, which
then returns errors if you call read(2).
Another way to obtain this erroneous behaviour is to pass a perl
script a stdin which is not, in fact, open for reading (easily
achieved with shell redirection). However, I didn't use that for my
bug report (even though it does repro the bug) because STDIN seems
like it will have special magic.
I would love a more portable name for something which can be opened
for reading, but which can't then be read.
I think the reasons so few people have reported this bug before are as
follows:
1. This can only occur if you have something open for reading but
which turns out not to be readable. In the absence of strange bugs,
that usually means a hardware failure resulting in EIO, which is very
rare.
2. If and when someone does get data loss due to this bug in a
situation where they got EIO due to hardware failure, they are very
likely to (a) be preoccupied with the disaster that is no doubt
unfolding (b) unable to precisely reproduce the situation or indeed
have precise and accurate records.
3. Very few people are so careful about error handling anyway, sadly.
So IMO the fact that this bug has been rarely reported does not mean
that it isn't a data loss bug. Rather, it's a data loss bug which
mostly has the effect of burning up more things when your system is
already on fire.
> Anyway, the data loss argument seems misplaced given we've read all the
> data there is when we are at EOF?
No.
The handle in the test case can never be successfully read, so it has
*not* reached EOF. All the calls to read(2) return errors. If perl
claims that the handle has reached EOF, that is itself a bug. (A data
loss bug, because a fslse EOF causes the rest of the data to be
ignored.)
I am almost certain that this bug would trip if you got EIO while
trying to read a plain file. (But this is hard to test.)
> See also https://github.com/Perl/perl5/issues/12782 which has not
> received attention in almost ten years.
Yikes. That does seem like the very same bug.
> The second issue (writing to /dev/full) is indeed fixed in sid / Perl
> 5.34. It was https://github.com/Perl/perl5/issues/6799 and reportedly
> only affects things like character devices (including /dev/full) and
> sockets. I've verified that trying to write to a normal file on a full
> filesystem does set the error() flag on stable / Perl 5.32.
I wonder what is different about plain files. I suspect the fact that
it "works" (correctly returning errors) for you in this case may be
due to luck (the precise series of calls).
> I think that makes the issue less severe, and I'm not very inclined to
> fix it in stable. But in case we end up doing that anyway, these would
> be the commits needed:
>
>
> https://github.com/Perl/perl5/commit/89341f87f9fc65c4d7133e497bb04586e86b8052
>
> https://github.com/Perl/perl5/commit/8a2562bec7cd9f8eff6812f340f99028bb33
>
> Downgrading the severity, but let me know what you think based on the above.
I still think this is a data loss bug. (Two bugs.)
I will think about trying to produce more convincing repros. Would
you convinced by something involving an LD_PRELOAD to cause "syscalls"
to fail ? Something involving ptrace ?
Damyan writes:
> Note that the recommended way to read files line by line is (perldoc
> -f readline):
>
> while ( ! eof($fh) ) {
> defined( $_ = readline $fh ) or die "readline failed: $!";
> ...
> }
I don't find this particularly convincing. This argument seems to be
saying "never use <> to read lines" which is pretty strange. Surely
it should be possible to use
Bug#942399: rxvt-unicode: server lockup making all clients unresponsive
On Tue, 15 Oct 2019 13:49:07 -0400 rharw...@club.cc.cmu.edu wrote: > Occasionally, I will see urxvtc process become unresponsive to keyboard > input. It seems like processes may still be able to update their panes - my > mosh session keeps updating the screen, for instance. Hi, after upgrading to bullseye I started experiencing a similar thing. This might be a problem of urxvt interacting with ibus. Apparently this has a long history. See: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753611 - http://lists.schmorp.de/pipermail/rxvt-unicode/2010q2/001177.html - https://askubuntu.com/questions/746119/upgrade-ibus-or-export-ibus-enable-sync-mode-1-to-fix-intellij-android-studio because of the IBUS_ENABLE_SYNC_MODE remark I do not use the daemon mode and it seems I did not have ibus daemon installed before bullseye. In my case input hangs from time to time after closing a tab using ^D. >From technical point of view XFilterEvent() in rxvttoolkit.C starts returning true for all key presses so urxvt stops processing them. Running `ibus restart` unfreezes my terminals. -- Marcin Szewczyk http://wodny.org
Bug#1015717: gajim: crashes at startup: KeyError: 'proxies' in optparser.py
Hello, the upstream project solved this in Release 1.4.7 (see upstream issue). gajim 1.4.7 is available in debian unstable, testing and stable-bpo. -- Stefan Diese E-Mail wurde von einem Debian GNU/Linux System gesendet
Bug#1016763: transition: foonathan-memory
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Release Team, I'd like to transition foonathan-memory after a SONAME bump. Its reverse dependency fastdds builds fine on amd64. The auto-generated transition https://release.debian.org/transitions/html/auto-foonathan-memory.html also looks good. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmLuvOwACgkQ+C8H+466 LVlFbwwAosyY9Z0G7/xVe79e6W551tnOsVnPgtFEKNartcJxdxKW5lBmqAhmIV9o xrRA4CJFiuSqO2vFUtpQQpQlcKL+agtJVFBTtxcxV/xphecyetTuaJSNkWSqo7Gs u189sdFXulmFfxob5nElIhwEQ/PTBl580Qqy//urpsiCAvZsIk9aF8yooXHouygN s1W8uDOm6kaeehGjaDJKN3PF8msUXps8HRFT24VG+CNu3g+NqEYvd5DmeCAL8rKm F+3rSaFuJQ9GVL62cO29h7EAgO36eJ25tBqjr76dp7yTgKExTXMrwmMZA2Lu+9/6 Z8lvOBKccCEjAURKpPg+bVWnokIYYZOcYwysnS3LQoeA+mrlCfWKWRIDoLTnBefi xianUvlaXJ9lUMAFWY4H0B4SfLTbnXkkq9U2qXpWduBFt88Xqk3tvQemvisJ1IQP 9x6cNalXALuZHhWVa3lPFWGUco7AjeSPu4tRX3mGdfbIHPrNhkcbQfrD4cq7qiJr TlSO1sd2 =oEaE -END PGP SIGNATURE-
Bug#1016719: dask: test_query_with_meta fails on 32 bit arches
On Sat, 2022-08-06 at 03:15 +0200, Drew Parsons wrote: > Source: dask > Version: 2022.02.0+dfsg-1 > Severity: normal > Control: forwarded -1 https://github.com/dask/dask/issues/8620 > > dask 2022.02.0 is failing two CI tests on 32 bit arches (armhf, > i386), > one in test_query_with_meta, the other in test_categorize_info > > The test_query_with_meta error is reported upstream at > https://github.com/dask/dask/issues/8620 > > The test_categorize_info error was dealt with upsteam with your patch > applied in https://github.com/dask/dask/pull/8851 which should be > applied in the 2022.04.0 release. Those seem reasonable things to backport, I'll try to get to it soon. > > Since we've got the pyarrow dependency getting in the way of > upgrading > to the more recent dask releases as noted in Bug#1013080, should we > pull > in the PR#8851 patch to debian/patches to fix test_categorize_info ? > > I did learn someone started packaging arrow and looks like they got somewhere, but I'm not sure how much more is needed to get it into NEW. https://salsa.debian.org/science-team/arrow/ Diane
Bug#1016726: ITP: libcommuni -- A cross-platform IRC framework written with Qt
Package: wnpp Followup-For: Bug #1016726 Control: tags -1 pending Uploaded and it is now in NEW.
Bug#1003911: ITA: xplanet -- planetary body renderer
retitle 1003911 ITA: xplanet -- planetary body renderer owner 1003911 ! thanks I intent to addopt xplanet.
Bug#1014705: bullseye-pu: package xtables-addons/3.13-1
Control: tags -1 + moreinfo On Sun, 2022-07-10 at 17:19 +0100, Jeremy Sowden wrote: > The related xtables-addons bug is: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014680 > > [ Reason ] > xtables-addons-dkms and xtables-addons-source contain sources for > building > kernel modules with DKMS and module-assistant, respectively. The > 5.10.0-16 > kernel introduced in the 11.4 point release included a patch back- > ported from > 5.11 to 5.10.121: > The metadata of #1014680 implies that it affects the package in unstable and is not yet fixed there - is that correct? If so, then the fix needs to happen in unstable first; if not, please add an appropriate fixed version to make the situation clearer. Regards, Adam
Bug#1016761: libhttp-daemon-perl: FTBFS with newer HTTP::Tiny versions
Source: libhttp-daemon-perl Version: 6.14-1.1 Severity: important Tags: ftbfs User: debian-p...@lists.debian.org Usertags: perl-5.36-transition X-Debbugs-Cc: Thorsten Alteholz It looks like the recent security fix in libhttp-daemon-perl_6.14-1.1 (or at least the associated test case) has issues with newer versions of the HTTP::Tiny module. This includes the separately packaged one in sid (libhttp-tiny-perl_0.082-1) and the one bundled with Perl 5.36 (currently in experimental). Reproducible in current sid by passing something like --add-depends='libhttp-tiny-perl (>= 0.080)' to sbuild, triggering the installation of the separate package. >From my build log: Subroutine HTTP::Tiny::Handle::write_content_body redefined at t/content_length.t line 277. # Failed test '... and has expected status' # at t/content_length.t line 36. # got: '200' # expected: '400' # Failed test '... and body does match' # at t/content_length.t line 40. # '' # doesn't match '(?^:value must be an unsigned integer)' # Failed test '... and has expected status' # at t/content_length.t line 36. # got: '200' # expected: '400' # Failed test '... and body does match' # at t/content_length.t line 40. # '' # doesn't match '(?^:value must be an unsigned integer)' # Failed test '... and has expected status' # at t/content_length.t line 36. # got: '200' # expected: '400' # Failed test '... and body does match' # at t/content_length.t line 40. # '' # doesn't match '(?^:value must be an unsigned integer)' # Looks like you failed 6 tests of 30. t/content_length.t . ok 1 - Hello World Request ... it works as expected ok 2 - ... and has expected status ok 3 - ... and body does match ok 4 - Positive Content Length not ok 5 - ... and has expected status not ok 6 - ... and body does match ok 7 - Negative Content Length not ok 8 - ... and has expected status not ok 9 - ... and body does match ok 10 - Non Integer Content Length not ok 11 - ... and has expected status not ok 12 - ... and body does match ok 13 - Explicit Content Length ... with exact length ok 14 - ... and has expected status ok 15 - ... and body does match ok 16 - Implicit Content Length ... will always pass ok 17 - ... and has expected status ok 18 - ... and body does match ok 19 - Shorter Content Length ... gets truncated ok 20 - ... and has expected status ok 21 - ... and body does match ok 22 - Different Content Length ... must fail ok 23 - ... and has expected status ok 24 - ... and body does match ok 25 - Underscore Content Length ... must match ok 26 - ... and has expected status ok 27 - ... and body does match ok 28 - Longer Content Length ... gets timeout ok 29 - ... and has expected status ok 30 - ... and body does match 1..30 Dubious, test returned 6 (wstat 1536, 0x600) Failed 6/30 subtests -- Niko Tyni nt...@debian.org
Bug#1016760: RM: golang-github-templexxx-xor -- ROM; superseded by templexxx-xorsimd
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian...@lists.debian.org Hi, golang-github-templexxx-xor has been superseeded by golang-github-templexxx-xorsimd. Its only reverse dep golang-github-audriusbutkevicius-kcp-go-dev has been asked to be removed in #1016705. Rest reverse-deps have migrated to xorsimd. The removal has been ACK'ed by its uploader here[1] Hence, please consider removing this package from the archive. [1]: https://lists.debian.org/debian-go/2022/08/msg00015.html Best, Nilesh
Bug#1002956: New debdiff
On Sat, 2022-01-29 at 22:53 +0100, Thomas Goirand wrote:
> On 1/29/22 20:31, Salvatore Bonaccorso wrote:
> > Control: tags -1 + moreinfo
> >
> > Hi Thomas,
> >
> > On Sat, Jan 29, 2022 at 07:55:15PM +0100, Thomas Goirand wrote:
> > > My appologies for opening a new bug. I didn't realize #1002956
> > > was still
> > > pending my input. I merged both bugs.
> > >
> > > Please see, attached to this message, the new debdiff, adding the
> > > fix for
> > > CVE-2021-22116 as well.
> >
> > See my comment from
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002956#10 .
> > Isn't
> > the the debian/patches/series missing the listing of
> > CVE-2021-32718_Escape_username_before_displaying_it.patch to
> > actually
> > apply the patch?
> >
> > Regards,
> > Salvatore
>
> Correct, fixed, thanks and sorry for the mistake.
>
+ * Stop moving mv /etc/rabbitmq/rabbitmq.conf /etc/rabbitmq/rabbitmq-env.conf.
This could do with an explanation as to _why_ this move should not be
happening.
+ if ! [ -e /var/lib/rabbitmq/.erlang.cookie ] ; then
+ OLD_UMASK=$(umask)
+ umask 077; openssl rand -base64 -out
/var/lib/rabbitmq/.erlang.cookie 42
+ umask ${OLD_UMASK}
+ else
+ # This matches an Erlang generated cookie file: 20 upper case
chars
+ if grep -q -E '^[A-Z]{20}$' /var/lib/rabbitmq/.erlang.cookie ;
then
+ OLD_UMASK=$(umask)
+ umask 077; openssl rand -base64 -out
/var/lib/rabbitmq/.erlang.cookie 42
+ umask ${OLD_UMASK}
+ if [ ""$(ps --no-headers -o comm 1) = "systemd" ] ; then
+ if systemctl is-active --quiet
rabbitmq-server.service ; then
+ systemctl restart
rabbitmq-server.service
[...]
+Since 3.9.8-3, the rabbitmq-server node will use openssl to generate a
+cryptographically-secure cookie during first installation, mitigating
+this vulnerability.
+
+Servers which installed a prior version, and are upgrading to 3.9.8-3
+or higher, ARE STILL VULNERABLE, as the package will not regenerate
+the secret if it exists already. This is because the secret is
+designed to be shared between nodes in a cluster, and thus
+regenerating it would break existing clusters.
This seems to be inaccurate. The latter block quoted above specifically
*does* regenerate an existing secret if it deems it to be not "good
enough", so far as I can tell?
Regards,
Adam
Bug#1016369: IO::Handle ->error does not work, always saying "fine"
Control: severity -1 normal Hi, thanks Ian for the report and Damyan for looking into the issues. On Sun, Jul 31, 2022 at 11:37:09AM +0300, Damyan Ivanov wrote: > -=| Ian Jackson, 30.07.2022 13:42:05 +0100 |=- > > Package: perl > > Version: 5.34.0-4 > > Severity: grave > > > > To reproduce > > > > perl -MIO::Handle -e 'open X, "<", "." or die $!; $_ = ; printf "%s > > %s %s\n", X->error(), $!;' > > perl -MIO::Handle -e 'open X, ">", "/dev/full" or die $!; print X 1; > > flush X; printf "%s %s %s\n", X->error(), $!; close X' > > > > Expected output > > > > -1 Bad file descriptor > > -1 No space left on device > > > > Actual output > > > > 0 Bad file descriptor > > 0 No space left on device FWIW I get 0 Is a directory 1 No space left on device on sid (perl_5.34.0-5). I'm not sure why you'd expect -1. The documentation for IO::Handle::error() only mentions it reporting a true value. The first issue (reading a directory as a plain file) seems to be about the error flag getting cleared when reading past EOF or something like that. According to my meager debugger skills, the clearing happens around https://sources.debian.org/src/perl/5.34.0-5/pp_hot.c/#L3278 As Damyan notes, you can detect this by checking for EOF before reading, although perl -MIO::Handle -e 'open X, "<", "." or die $!; $_ = if !X->eof(); printf "%s %s\n", X->error(), $!;' 1 Inappropriate ioctl for device is not quite what I'd expect either. Anyway, the data loss argument seems misplaced given we've read all the data there is when we are at EOF? I can see there is probably a bug around here, but it would be good to have an example test case that doesn't involve treating a directory as a plain file (which can have very varying results between different platforms) before taking this upstream. Particularly so if you want to argue it's as serious as claimed here. See also https://github.com/Perl/perl5/issues/12782 which has not received attention in almost ten years. The second issue (writing to /dev/full) is indeed fixed in sid / Perl 5.34. It was https://github.com/Perl/perl5/issues/6799 and reportedly only affects things like character devices (including /dev/full) and sockets. I've verified that trying to write to a normal file on a full filesystem does set the error() flag on stable / Perl 5.32. I think that makes the issue less severe, and I'm not very inclined to fix it in stable. But in case we end up doing that anyway, these would be the commits needed: https://github.com/Perl/perl5/commit/89341f87f9fc65c4d7133e497bb04586e86b8052 https://github.com/Perl/perl5/commit/8a2562bec7cd9f8eff6812f340f99028bb33 Downgrading the severity, but let me know what you think based on the above. -- Niko
Bug#1016759: easy-rsa: regression?: Conflicting 'vars' files found
Package: easy-rsa Version: 3.1.0-0.1 Severity: normal Dear Maintainer, Consider the following sequence of commands: % make-cadir foo % cd foo % ./easyrsa init-pki % ./easyrsa build-ca In a fresh bullseye chroot (3.0.8-1), that sequence succeeds: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: …/pki/ca.crt In a sid chroot from today (3.1.0-0.1), that sequence fails with: # ./easyrsa build-ca Found: …/pki/vars Found: …/vars Easy-RSA error: Conflicting 'vars' files found. Priority should be given to your PKI vars file: * /root/sid/pki/vars I don't use easy-rsa, but this seems like a regression. HTH, Daniel P.S. The changelog of this version includes the item "autopkgtests: Remove conflicting vars file", which may be related.
Bug#1015254: transition: opencascade
Hi, On Mon, Aug 01, 2022 at 08:29:45AM +0100, Graham Inggs wrote: > Control: tags -1 confirmed > > Hi Tobi > > On Sun, 31 Jul 2022 at 16:51, Tobias Frost wrote: > > I've uploading 7.6.3 right now to experimental; as I removed the confirmed > > tag, please reACK > > the "go ahead" -- I've tested that all r-depends that worked before are > > still compiling > > reACK opencascade has now built on all release archs. I'd suggest to start binNMU freecad and maybe then proceed to remove netgen together with gmsh and deal.ii temporarily from testing. (the later two need an updated netgen…) (I'll poked the maintainer of netgen already, but no respons… As netgen has a "+really" version without really documenting the reason, I fear if I NMU a newer version I could break stuff…) -- Cheers, tobi
Bug#848578: Also running into this problem
I can also reproduce this problem with `ts` while `date` works fine: $ date | ts ao� 06 10:33:36 sam 06 aoû 2022 10:33:36 PDT $ date sam 06 aoû 2022 10:35:39 PDT $ echo test | ts ao� 06 10:36:04 test This is what my locale is set to: $ locale LANG=fr_CA.utf8 LANGUAGE= LC_CTYPE="fr_CA.utf8" LC_NUMERIC="fr_CA.utf8" LC_TIME="fr_CA.utf8" LC_COLLATE="fr_CA.utf8" LC_MONETARY="fr_CA.utf8" LC_MESSAGES="fr_CA.utf8" LC_PAPER="fr_CA.utf8" LC_NAME="fr_CA.utf8" LC_ADDRESS="fr_CA.utf8" LC_TELEPHONE="fr_CA.utf8" LC_MEASUREMENT="fr_CA.utf8" LC_IDENTIFICATION="fr_CA.utf8" LC_ALL= $ cat /etc/locale.gen | grep -v '^#' en_CA.UTF-8 UTF-8 en_NZ.UTF-8 UTF-8 fr_CA.UTF-8 UTF-8 Let me know if there's anything else I can provide to help reproduce the problem. Francois -- https://fmarier.org/
Bug#1014447: bullseye-pu: package lwip/2.1.2+dfsg1-8
Control: tags -1 + confirmed On Wed, 2022-07-06 at 11:26 +0200, Joan Lledó wrote: > This patch fixes CVE-2020-22283 and CVE-2020-22284 in bullseye. > Please go ahead. Regards, Adam
Bug#1014315: bullseye-pu: package dnsproxy/1.16-0.1+deb11u1
Control: tags -1 + confirmed On Sun, 2022-07-03 at 18:01 -0300, Marcos Talau wrote: > The dnsproxy package fails to install when you do not have the IP > address "192.168.168.1" configured on the machine. This bug remains > since its initial release. > Please go ahead. Regards, Adam
Bug#1014571: bullseye-pu: package node-log4js/6.3.0+~cs8.3.10-1+deb11u1
Control: tags -1 + confirmed On Fri, 2022-07-08 at 07:49 +0200, Yadd wrote: > node-log4js creates log files with permissive rights (644). This > causes > a security issue (CVE-2022-21704) > Please go ahead. Regards, Adam
Bug#1015244: bullseye-pu: package commons-daemon/1.0.15-8
Control: tags -1 + confirmed On Mon, 2022-07-18 at 12:10 +0200, Chris Hofstaedtler wrote: > Running a java daemon using jsvc and the JVM from (old)stable does > not > work. It appears no java programs inside Debian still use jsvc, > otherwise people would have noticed earlier. This is bug #935336, > and I want to fix it in oldstable/buster (#1015243) and > stable/bullseye > (this bug). > > [ Impact ] > > jsvc just does not work except if on upgrades one keeps the JVM from > oldoldstable (openjdk 8). > Please go ahead. Regards, Adam
Bug#1014900: bullseye-pu: package node-moment/2.29.1+ds-2+deb11u2
Control: tags -1 + confirmed On Thu, 2022-07-14 at 07:44 +0200, Yadd wrote: > node-moment is vulnerable to ReDoS (#1014845, CVE-2022-31129) > Please go ahead. Regards, Adam
Bug#1016199: bullseye-pu: package gif2apng/1.9+srconly-3+deb11u1
Control: tags -1 + confirmed On Fri, 2022-07-29 at 08:59 +0200, Håvard F.Aasen wrote: > This upload fixes three CVE's; > * CVE-2021-45909, Closes: #1002668: > heap based buffer overflow in the DecodeLZW > * CVE-2021-45910, Closes: #1002667: > heap-based buffer overflow within the main function > * CVE-2021-45911, Closes: #1002687: > heap based buffer overflow in processing of delays in the main > function > Please go ahead. Regards, Adam
Bug#1016458: bullseye-pu: package dovecot/2.3.13+dfsg1-2+deb11u1
Control: tags -1 + confirmed On Sun, 2022-07-31 at 18:06 -0700, Noah Meyerhans wrote: > Dovecot 2.3.13+dfsg1-2+deb11u1 contains a backported fix for #1016351 > (CVE-2022-30550). The fix is cherry-picked from upstream and is > identical > to the fix recently uploaded to unstable in dovecot_2.3.19.1+dfsg1- > 2. The > stable security team and the package maintainers have determined that > this > issue does not warrant a DSA and should be fixed in the next bullseye > point release. > Please go ahead. Regards, Adam
Bug#1016391: bullseye-pu: libhttp-daemon-perl/6.12-1+deb11u1
Control: tags -1 + confirmed On Sat, 2022-07-30 at 22:11 +, Thorsten Alteholz wrote: > The attached debdiff for libhttp-daemon-perl fixes CVE-2022-31081 in > Bullseye. This CVE has been marked as no-dsa by the security team. > > The patch is accompanied by a new test and should not create any > issue. > Please go ahead. Regards, Adam
Bug#991120: buster-pu: package postsrsd/1.5-2+deb10u2
Control: tags -1 -moreinfo +confirmed On Sun, 2021-07-18 at 18:29 +0100, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Wed, 2021-07-14 at 22:00 +0200, Oxan van Leeuwen wrote: > > [ Checklist ] > > [x] *all* changes are documented in the d/changelog > > [x] I reviewed all changes and I approve them > > [x] attach debdiff against the package in (old)stable > > [ ] the issue is verified as fixed in unstable > > > > As of writing the fix isn't in unstable yet, since I don't have > > upload rights. > > I've asked my sponsor to upload the fix for both stable and > > unstable > > at the > > same time -- it seemed unnecessary to add another roundtrip delay, > > as > > it's > > exactly the same fix. > > Tagging as "moreinfo" for now on that basis. Please remove the tag > once > the upload has happened. > Apparently the unstable upload happened at some point, but the tag was never removed. If this is still something you're interested in fixing in buster, please go ahead. Regards, Adam
Bug#983841: buster-pu: package libvirt-php/0.5.4-3+deb10u1
Control: tags -1 -moreinfo + confirmed On Wed, 2021-03-17 at 18:32 +, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Tue, 2021-03-02 at 08:47 +0100, Ondřej Surý wrote: > > [ Reason ] > > The package update fixes segmentation fault caused by incomplete > > PHP > > 7.3 support > > in the upstream package. > > > > [ Impact ] > > The PHP crashes when calling libvirt_node_get_cpu_stats (See > > #982804) > > The metadata for that bug implies that it affects the package in > unstable, and is not yet fixed there. Is that correct? > That appears to have been resolved in the meantime. If this is something that you're still interested in fixing in buster, please go ahead. Regards, Adam
Bug#983531: buster-pu: package python2.7/2.7.16-2+deb10u2
Hi Moritz, On Thu, 2021-03-18 at 20:17 +0100, Moritz Mühlenhoff wrote: > Am Sat, Mar 13, 2021 at 06:46:38PM + schrieb Adam D. Barratt: > > On Fri, 2021-02-26 at 16:30 +0100, Moritz Muehlenhoff wrote: > > > On Fri, Feb 26, 2021 at 07:49:38AM +0100, Matthias Klose wrote: > > > > On 2/25/21 7:41 PM, Moritz Muehlenhoff wrote: > > > > > + * CVE-2021-3177 > > > > > > > > are all the ctypes tests passing with this patch? See #983516. > > > > > > I'll have a look at Marc' updated patch and revise if needed. > > > > Was there a conclusion on that? > > I won't have time for preparing/testing a revised update, this will > need to wait for 10.10 Are you still looking at getting this fixed in buster? Regards, Adam
Bug#1015243: commons-daemon 1.0.15-8+deb10u1 flagged for acceptance
package release.debian.org tags 1015243 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: commons-daemon Version: 1.0.15-8+deb10u1 Explanation: fix JVM detection
Bug#1016671: grub2 2.06-3~deb10u1 flagged for acceptance
package release.debian.org tags 1016671 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: grub2 Version: 2.06-3~deb10u1 Explanation: new upstream release
Bug#1012048: composer 1.8.4-1+deb10u2 flagged for acceptance
package release.debian.org tags 1012048 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: composer Version: 1.8.4-1+deb10u2 Explanation: fix code injection vulnerability [CVE-2022-24828]; update GitHub token pattern; use Authorization header instead of deprecated access_token query parameter
Bug#1011943: php-guzzlehttp-psr7 1.4.2-0.1+deb10u1 flagged for acceptance
package release.debian.org tags 1011943 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: php-guzzlehttp-psr7 Version: 1.4.2-0.1+deb10u1 Explanation: fix improper header parsing [CVE-2022-24775]
Bug#1011030: htmldoc 1.9.3-1+deb10u4 flagged for acceptance
package release.debian.org tags 1011030 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: htmldoc Version: 1.9.3-1+deb10u4 Explanation: fix infinite loop [CVE-2022-24191], integer overflow issues [CVE-2022-27114] and heap buffer overflow issue [CVE-2022-28085]
Bug#1010858: unrar-nonfree 5.6.6-1+deb10u1 flagged for acceptance
package release.debian.org tags 1010858 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: unrar-nonfree Version: 5.6.6-1+deb10u1 Explanation: fix directory traversal issue [CVE-2022-30333]
Bug#1010380: flac 1.3.2-3+deb10u2 flagged for acceptance
package release.debian.org tags 1010380 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: flac Version: 1.3.2-3+deb10u2 Explanation: fix out-of-bounds write issue [CVE-2021-0561]
Bug#1010060: mutt 1.10.1-2.1+deb10u6 flagged for acceptance
package release.debian.org tags 1010060 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: mutt Version: 1.10.1-2.1+deb10u6 Explanation: fix uudecode buffer overflow [CVE-2022-1328]
Bug#1009652: nvidia-graphics-drivers 418.226.00-3 flagged for acceptance
package release.debian.org tags 1009652 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: nvidia-graphics-drivers Version: 418.226.00-3 Explanation: new upstream release
Bug#1009076: minidlna 1.2.1+dfsg-2+deb10u3 flagged for acceptance
package release.debian.org tags 1009076 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: minidlna Version: 1.2.1+dfsg-2+deb10u3 Explanation: validate HTTP requests to protect against DNS rebinding attacks [CVE-2022-26505]
Bug#1009251: fribidi 1.0.5-3.1+deb10u2 flagged for acceptance
package release.debian.org tags 1009251 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: fribidi Version: 1.0.5-3.1+deb10u2 Explanation: fix buffer overflow issues [CVE-2022-25308 CVE-2022-25309]; fix crash [CVE-2022-25310]
Bug#1008578: golang-github-russellhaering-goxmldsig 0.0~git20170911.b7efc62-1+deb10u1 flagged for acceptance
package release.debian.org tags 1008578 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: golang-github-russellhaering-goxmldsig Version: 0.0~git20170911.b7efc62-1+deb10u1 Explanation: fix NULL pointer dereference issue [CVE-2020-7711]
Bug#1009065: dropbear 2018.76-5+deb10u1 flagged for acceptance
package release.debian.org tags 1009065 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: dropbear Version: 2018.76-5+deb10u1 Explanation: fix possible username enumeration issue [CVE-2019-12953]
Bug#1016756: transition: meshoptimizer
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Release Team, I'd like to transition meshoptimizer after a SONAME bump. The only reverse dependency, filament, builds fine on amd64. The auto-generated transition https://release.debian.org/transitions/html/auto-meshoptimizer.html also looks good. Cheers Timo -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmLumN8ACgkQ+C8H+466 LVkKeQv/Vb0+mfmqH9Ex5++1vxoY3m4TcsvEOX7n6RHMGBV464XesvSl1SnneH+D +/7sqNDZz1kCbA/CW09D4SV1/VN2E9nS7xDiZjxAUiSB6ggzdFsZOuFpFAtG2T5Z V+6LAiLJDLGsjkqmN3sDUgErh7eFpREYNz2E2En3zk0XsJ9WXDqkZCEB14lv5DtK hqWcAg5jC5PFjKw2BkrL3XvW9Gv2TvXufx+smgRpj9QId2NZ+sJDgBYq+6A878Ao KYp6tmxYEHvC5mRKwT4YdowJPQQ2bULUJeY666dKAhikSuee1IGWEc2TzqehflhD qRlxufy0raIsu+zob+wHe7kkJUu4bZ9M73pDGHDFn5BNwD5zlkiFme3rwz9Nq9Na oAh3ZMUKL7BodGc8FgDaOs7iCA35sDs8E6ZXpCOlEYyCzpP1XjdnYBfQjDdTmGGV QABHAJBI2rAzk7zK7cPTBhcnZOreosORNP+Cu16MZikCiYDfgYJLGW9CZgyW/Y++ dn8NRlU/ =HMqu -END PGP SIGNATURE-
Bug#1003911: RFA: xplanet -- planetary body renderer
Hi Steve! I noticed you are searching someone to adopt xplanet. I'm still using it from time to time and am also looking for something to slowly getting back. Would you mind if I adtopt it? I think one of the first stept would be, to check (and upload) the 1.3.1 release. Best regards, Alexander
Bug#1003911: RFA: xplanet -- planetary body renderer
Hey! Nice to see you back around! :-) On Sat, Aug 06, 2022 at 06:16:53PM +0200, Alexander Reichle-Schmehl wrote: > >I noticed you are searching someone to adopt xplanet. I'm still using it >from time to time and am also looking for something to slowly getting >back. Would you mind if I adtopt it? > >I think one of the first stept would be, to check (and upload) the 1.3.1 >release. Sure, all yours! Have fun. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "Every time you use Tcl, God kills a kitten." -- Malcolm Ray
Bug#1014324: rustc-mozilla 1.59.0+dfsg1-1~deb11u3 flagged for acceptance
package release.debian.org tags 1014324 = bullseye pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye. Thanks for your contribution! Upload details == Package: rustc-mozilla Version: 1.59.0+dfsg1-1~deb11u3 Explanation: fix use of mips stage0 binaries
Bug#1010338: autopkgtest: Option --test-name and debian/tests/control test-name raise exception
Control: tag -1 patch
The trivial patch attached fixes the exception. Seems it was a
regression caused by the fix for #960267.
cheers
--
Guilhem.
diff --git a/lib/testdesc.py b/lib/testdesc.py
index 3e696a2..39e1ecb 100644
--- a/lib/testdesc.py
+++ b/lib/testdesc.py
@@ -678,7 +678,7 @@ def parse_debian_source(srcdir, testbed_caps, testbed_arch, control_path=None,
raise InvalidControl('*', 'missing "Tests" or "Test-Command"'
' field')
except Unsupported as u:
-if testname is None or n == testname:
+if testname is None:
u.report()
some_skipped = True
signature.asc
Description: PGP signature
Bug#1016695: po4a: Strange behaviour with repeated strings (in halibut backend)
Hello Martin, On Sat, Aug 06, 2022 at 05:24:48PM +0200, Martin Quinson wrote: > Hello, thanks for the analysis and the hints for sgt-puzzles. > Le samedi 06 août 2022 à 06:20 +0200, Helge Kreutzmann a écrit : > > > > On Sat, Aug 06, 2022 at 12:23:48AM +0200, Martin Quinson wrote: > > > the short answer is that po4a-gettextize is not intended to be used on a > > > regular > > > basis. It's only intended for the first run when you want to convert an > > > existing > > > translation to the po-based workflow. Once it's done, you're supposed to > > > use > > > po4a-updatepo to create an empty PO file. Even better, you should use po4a > > > directly instead of the deprecated atomic commands. > > > > Ok, so this would be incorrect usage in sgt-puzzles? It did work for > > the past ~ 13 years. Then it might be helpful to add a note that > > certain use cases are not working anymore. > > > > Should this bug be cloned to sgt-puzzles for updating its > > infrastructure? > > The fact is that I never imagined that someone would use po4a-gettextize on a > regular basis, to create the empty POT file. I would have added a note in the > changelog if I knew. I see the intend now, but this is not a usecase that I > plan > to maintain. I just added a check to po4a-gettextize which makes it break if > you > call it without localized files, as you would do to generate the empty POT > files. > > My rational here is that the gettextization (ie, the resynchronization of a > master file and a localized file to generate a valid PO file that can be used > afterward in a po4a-based workflow) is a really tedious process. I prefer the > po4a-gettextize script to dedicate to this usage, trying to smooth it as much > as > possible. This is not really compatible with its use as in sgt-puzzles. > > So, yes, the infrastructure of sgt-puzzles should be updated as it will fail > with the next upcoming release of po4a. Sorry about that. The easiest should > be > to simply use po4a-updatepo with an unexistant POT file instead of po4a- > gettextize, but the best would be to write a simple po4a.conf file and switch > to > the integrated po4a program. Invoking `make -f Makefile.doc update-po` now > fails > with the following error message: > > | You must provide both master files and localized files to po4a-gettextize, > as > | it is intended to synchronize master files and previously existing > translations. > | If just want to extract POT files of your master files, please > po4a-updatepo. > | But the most convenient way of using po4a is to write a po4a.conf file and > use > | the integrated po4a(1) program. > > Changing po4a-gettextize to po4a-updatepo seems to fix everything. > > > > The extra spaces that you see are intended to help the gettextization > > > process, as explained in the po4a-gettextize manpage. > > > > At least I don't fully understand this text, even though I translated > > it. (See below) > > > > > I'm not sure of how I can help you here. What piece of documentation > > > should > > > be updated? > > > > > > What is missing here is how and when these strings are merged back, i.e. > > what > > the translator or package maintainer should do to get to the desired > > situation (i.e. each string only appearing once). > > I tried to rewrite the documentation and apply your comments. Please check the > new version and report any remaining issue. > https://github.com/mquinson/po4a/blob/master/po4a-gettextize#L24 Thanks, this explains it better. > Thanks for your precious feedback, And thanks for your speedy and efficient handling. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: PGP signature
Bug#1016695: po4a: Strange behaviour with repeated strings (in halibut backend)
Hello, Le samedi 06 août 2022 à 06:20 +0200, Helge Kreutzmann a écrit : > > On Sat, Aug 06, 2022 at 12:23:48AM +0200, Martin Quinson wrote: > > the short answer is that po4a-gettextize is not intended to be used on a > > regular > > basis. It's only intended for the first run when you want to convert an > > existing > > translation to the po-based workflow. Once it's done, you're supposed to use > > po4a-updatepo to create an empty PO file. Even better, you should use po4a > > directly instead of the deprecated atomic commands. > > Ok, so this would be incorrect usage in sgt-puzzles? It did work for > the past ~ 13 years. Then it might be helpful to add a note that > certain use cases are not working anymore. > > Should this bug be cloned to sgt-puzzles for updating its > infrastructure? The fact is that I never imagined that someone would use po4a-gettextize on a regular basis, to create the empty POT file. I would have added a note in the changelog if I knew. I see the intend now, but this is not a usecase that I plan to maintain. I just added a check to po4a-gettextize which makes it break if you call it without localized files, as you would do to generate the empty POT files. My rational here is that the gettextization (ie, the resynchronization of a master file and a localized file to generate a valid PO file that can be used afterward in a po4a-based workflow) is a really tedious process. I prefer the po4a-gettextize script to dedicate to this usage, trying to smooth it as much as possible. This is not really compatible with its use as in sgt-puzzles. So, yes, the infrastructure of sgt-puzzles should be updated as it will fail with the next upcoming release of po4a. Sorry about that. The easiest should be to simply use po4a-updatepo with an unexistant POT file instead of po4a- gettextize, but the best would be to write a simple po4a.conf file and switch to the integrated po4a program. Invoking `make -f Makefile.doc update-po` now fails with the following error message: | You must provide both master files and localized files to po4a-gettextize, as | it is intended to synchronize master files and previously existing translations. | If just want to extract POT files of your master files, please po4a-updatepo. | But the most convenient way of using po4a is to write a po4a.conf file and use | the integrated po4a(1) program. Changing po4a-gettextize to po4a-updatepo seems to fix everything. > > The extra spaces that you see are intended to help the gettextization > > process, as explained in the po4a-gettextize manpage. > > At least I don't fully understand this text, even though I translated > it. (See below) > > > I'm not sure of how I can help you here. What piece of documentation should > > be updated? > > > What is missing here is how and when these strings are merged back, i.e. what > the translator or package maintainer should do to get to the desired > situation (i.e. each string only appearing once). I tried to rewrite the documentation and apply your comments. Please check the new version and report any remaining issue. https://github.com/mquinson/po4a/blob/master/po4a-gettextize#L24 > Could you add an example here? I.e. like I did below with my example? > In your text above (in the e-mail) you state that you should use > po4a-updatepo or po4a, here you mention msgmerge. Probably clarifying > this would help as well. I didn't add any example, but the new text is much more detailed so maybe that's enough? Thanks for your precious feedback, Mt > signature.asc Description: This is a digitally signed message part
Bug#1016752: developers-reference: Chapter 3.2.6. "Returning after retirement" refers to alioth.debian.org
Package: developers-reference Version: 12.5 Severity: minor Dear Maintainers, In the bullet point list of chapter 3.2.6. "Returning after retirement" the old alioth system is referenced. Should probably now be a refernece to salsa.debian.org? See https://www.debian.org/doc/manuals/developers-reference/developer-duties.en.html#returning-after-retirement. Best regards, Alexander -- System Information: Debian Release: 10.12 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-18-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled developers-reference depends on no packages. Versions of packages developers-reference recommends: pn debian-policy Versions of packages developers-reference suggests: pn doc-base
Bug#1016653: gm(1): targa (.tga) files are read and written upside-down
On Thu, 4 Aug 2022, Bob Friesenhahn wrote: Testing with ImageMagick 6.9.12-38 on an Illumos system shows the image the other way around with the bright pink cone laying on what might be a gray floor. Due to the nature of the image, it is difficult to tell what the right way up is. It appears that ImageMagick 6.9.10-23 and 6.9.12-38 do not display the same output! Thankfully this issue brought my attention back to TGA format. I found that an unnecessary security check was blocking reading some files entirely. I also noticed that the code could be optimized a bit. However, I believe that this bug report is incorrect. What has actually happened is that ImageMagick changed what it returns and more recent ImageMagick also changed what it does when it displays an image. GraphicsMagick always returns an image in the common normal form (TopLeft). ImageMagick changed so that it returns an image in the same form as the file, but it sets an orientation option so that the user needs to use -auto-orient to see a correct image. In the older version of ImageMagick, the 'display' program does not appear to automatically adjust the orientation where as the newer version does. This morning I committed the TGA improvements and created a new development snapshot release. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Bug#1016751: gsasl: autopkgtest regression on armel: new test has dependency that isn't available
Source: gsasl Version: 2.0.1-2 User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of gsasl the autopkgtest of gsasl fails in testing when that autopkgtest is run with the binary packages of gsasl from unstable on armel. It passes when run with only packages from testing. In tabular form: passfail gsasl from testing2.0.1-2 all others from testingfrom testing After checking your changelog, I noticed you added a test and exactly this test fails because the test dependencies can't be installed. Please add a "Architecture: !armel" line to the third test definition. Paul PS: for now, I have accepted the regression on armel, but please fix nevertheless. OpenPGP_signature Description: OpenPGP digital signature
Bug#1011165: org.h2.jdbc.JdbcSQLSyntaxErrorException: schema "MEDIATHEKVIEW" not found
Hello Markus,
On Tue, May 17, 2022 at 10:09:08PM +0200, Markus Koschany wrote:
> Control: severity -1 serious
>
> Am Dienstag, dem 17.05.2022 um 21:59 +0200 schrieb mt...@nurfuerspam.de:
> > Package: mediathekview
> > Version: 13.2.1-4
> > Severity: important
> >
> > Dear Maintainer,
> >
> > after libh2-java was updated from version 2.1.210+really1.4.197-1 to
> > 2.1.212-
> > 1
> > there is an enormous occurrence of the following error exceptions when
> > starting mediathekview:
>
> Hello and thanks for the report. Currently this cannot be avoided because we
> had to move forward with the h2 database in Debian. The latest version of
> mediathekview should not require h2 anymore. I don't have the time to package
> a
> new upstream release right now but if someone wants to beat me to it, please
> go
> ahead and mark yourself as the owner of this bug report.
I hope that you'll have some time so that mediathekview is shipped in
Testing/Futures stables again.
I tried to have a look at it (though I've really no clue about java
and building java progs) and unfortunately the situation is worse than
I thought.
To save others time, that's what I tried:
1) Using the existing debian directory with or without applying
patches no longer works (this is what I expected).
2) A direct ("upstream") build also fails (and the documentation on
building is very terse) and on a quick search I could not find a
workaround.
Direct build:
./mvnw compile
…
Downloaded from central:
https://repo.maven.apache.org/maven2/org/openjfx/javafx-graphics/19-ea+7/javafx-graphics-19-ea+7-linux.jar
(4.8 MB at 1.3 MB/s)
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 10.034 s
[INFO] Finished at: 2022-07-20T14:49:04+02:00
[INFO]
[ERROR] Failed to execute goal on project MediathekView: Could not resolve
dependencies for project de.mediathekview:MediathekView:jar:13.9.1: Could not
find artifact airsquared:JMacNotification:jar:1.1 in local-maven-repository
(file:tmp/mtvb2/MediathekView-13.9.1/maven-repository) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
and indeed,
/tmp/mtvb2/MediathekView-13.9.1/maven-repository/airsquared/JMacNotification/1.1/JMacNotification-1.1.jar
does not exists, and even worse (explaining the failure):
https://repo.maven.apache.org/maven2/airsquared/JMacNotification/1.1/JMacNotification-1.1.jar
is 404 (does not exist)
I could find maybe a read only copy here:
https://github.com/mediathekview/MediathekViewArchiv/blob/master/maven-repository/airsquared/JMacNotification/1.1/JMacNotification-1.1.jar
So this would require verification and then somehow to be included
into the build.
Maybe this helps getting the ball rolling …
Greetings
Helge
P.S. Besides the errors the current version still seems to work
--
Dr. Helge Kreutzmann deb...@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
signature.asc
Description: PGP signature
Bug#1016750: sbcl breaks cl-ironclad autopkgtest on armhf: Heap exhausted, game over.
Source: sbcl, cl-ironclad
Control: found -1 sbcl/2:2.2.6-2
Control: found -1 cl-ironclad/0.57-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update
Dear maintainer(s),
With a recent upload of sbcl the autopkgtest of cl-ironclad fails in
testing when that autopkgtest is run with the binary packages of sbcl
from unstable. It passes when run with only packages from testing. In
tabular form:
passfail
sbcl from testing2:2.2.6-2
cl-ironcladfrom testing0.57-1
all others from testingfrom testing
I copied some of the output at the bottom of this report.
Currently this regression is blocking the migration of sbcl to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=sbcl
https://ci.debian.net/data/autopkgtest/testing/armhf/c/cl-ironclad/24381695/log.gz
; wrote
/tmp/autopkgtest-lxc.d2c27h4h/downtmp/autopkgtest_tmp/usr/share/common-lisp/source/ironclad/src/ciphers/tea-tmp93OFNPHA.fasl
; compilation finished in 0:00:00.160
; compiling file
"/usr/share/common-lisp/source/ironclad/src/ciphers/threefish.lisp"
(written 18 FEB 2022 01:39:10 PM):
Heap exhausted during garbage collection: 16 bytes available, 48 requested.
Immobile Object Counts
Gen GF type fdefn symbol code Boxed ConsRaw Code SmMix
Mixed LgRaw LgCode LgMix Waste% AllocTrig Dirty GCs
Mem-age
1 00 0 0 0 7121939 9668 5273
827 0 0 17 19.96186748032499253 18850 1
1.1503
2 00 0 0 0 19865 2766 12586 84836
1681 10 34127 11.7 137430448 5368709 23089 0
0.9496
3 00 0 0 0 45116 7190 7447604 3552
16732394673311.0 270091288 2007806 0
0.4559
4 00 0 0 0 0 0 0 0 0
0 0 0 00.0 0 200 0 0
0.
5 00 0 0 0 0 0 0 0 0
0 0 0 00.0 0 200 0 0
0.
6 00 0 0 0 1370471 1242 3507314
402551342811.930584464 200 251 0
0.
Tot 00 0 0 0 73472 11366 30943 4200 4975
42215046357566.9 499973680 [93.1% of 536870912 max]
GC control variables:
*GC-INHIBIT* = true
*GC-PENDING* = true
fatal error encountered in SBCL pid 1357:
Heap exhausted, game over.
0: 0xf746478c pc=0x98 {0x4f0380b8+b0fc7fe0} {code_serialno=3901}
1: 0xf7464730 pc=0x4f005760 {0x4f005000+0760} (FLET
"WITHOUT-GCING-BODY-5" :IN SB-KERNEL::SUB-GC)
2: 0xf74646d4 pc=0x4f0053f8 {0x4f005000+03f8} (FLET
"WITHOUT-INTERRUPTS-BODY-1" :IN SB-KERNEL::SUB-GC)
3: 0xf7464678 pc=0x4f005108 {0x4f005000+0108} SB-KERNEL::SUB-GC
4: 0xf746466c pc=(nil) LRA=0x3e2e75: [I]0xf7464654
pc=0x3e4d8 {0x4fb3f240+b04ff298} {code_serialno=f5f}
6: 0xf7464634 pc=0x5028c858 {0x5028c4b0+03a8} SB-C::MAKE-WIRED-TN
7: 0xf7464604 pc=0x4fd9a348 {0x4fd9a030+0318}
SB-C::IR2-CONVERT-FULL-CALL-ARGS
8: 0xf74645c4 pc=0x4f8506f8 {0x4f8505c8+0130}
SB-C::IR2-CONVERT-FIXED-FULL-CALL
9: 0xf74645b4 pc=0x4f3d8b18 {0x4f3d8990+0188}
SB-C::IR2-CONVERT-FULL-CALL
10: 0xf7464598 pc=0x4f6fe720 {0x4f6fda90+0c90}
SB-C::IR2-CONVERT-BLOCK
11: 0xf7464584 pc=0x4f2c8f58 {0x4f2c8dc8+0190} SB-C::IR2-CONVERT
12: 0xf7464550 pc=0x504637a8 {0x50463198+0610}
SB-C::%COMPILE-COMPONENT
13: 0xf7464538 pc=0x5041c820 {0x5041c258+05c8}
SB-C::COMPILE-COMPONENT
14: 0xf7464514 pc=0x5037ca10 {0x5037c7b8+0258} SB-C::COMPILE-TOPLEVEL
15: 0xf7464500 pc=0x503f0eb8 {0x503f0c28+0290}
SB-C::CONVERT-AND-MAYBE-COMPILE
16: 0xf74644b4 pc=0x50393270 {0x50392a10+0860}
SB-C::PROCESS-TOPLEVEL-FORM
17: 0xf746449c pc=0x50457490 {0x504573a0+00f0}
SB-C::PROCESS-TOPLEVEL-PROGN
18: 0xf7464450 pc=0x50393188 {0x50392a10+0778}
SB-C::PROCESS-TOPLEVEL-FORM
19: 0xf7464404 pc=0x50393408 {0x50392a10+09f8}
SB-C::PROCESS-TOPLEVEL-FORM
20: 0xf74643b8 pc=0x50393408 {0x50392a10+09f8}
SB-C::PROCESS-TOPLEVEL-FORM
21: 0xf7464334 pc=0x502f60e0 {0x502f3b20+25c0} (LAMBDA
(SB-KERNEL::FORM :CURRENT-INDEX ) :IN
SB-C::SUB-COMPILE-FILE)
22: 0xf74642c0 pc=0x4f0c5038 {0x4f0c49a8+0690}
SB-C::%DO-FORMS-FROM-INFO
23: 0xf7464244 pc=0x502f3ea0 {0x502f3b20+0380} (FLET "LAMBDA0"
:IN "SYS:SRC;COMPILER;MAIN.LISP")
24:
Bug#1016749: pytango: autopkgtest failure on armel
Source: pytango
Version: 9.3.4-2
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always
Dear maintainer(s),
You recently added an autopkgtest to your package pytango, great.
However, it fails on armel. Currently this failure is blocking the
migration to testing [1]. Can you please investigate the situation and
fix it?
I copied some of the output at the bottom of this report.
More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
Paul
[1] https://qa.debian.org/excuses.php?package=pytango
https://ci.debian.net/data/autopkgtest/testing/armel/p/pytango/23495376/log.gz
=== FAILURES
===
___ test_subscribe_change_event[Synchronous]
___
event_device = EventDevice(test/nodb/eventdevice)
def test_subscribe_change_event(event_device):
results = []
def callback(evt):
results.append(evt.attr_value.value)
# Subscribe
eid = event_device.subscribe_event(
"attr", EventType.CHANGE_EVENT, callback, wait=True)
assert eid == 1
# Trigger an event
event_device.command_inout("send_event", wait=True)
# Wait for tango event
retries = 20
for _ in range(retries):
event_device.read_attribute("state", wait=True)
if len(results) > 1:
break
time.sleep(0.05)
# Test the event values
assert results == [0., 1.]
E assert [0.0] == [0.0, 1.0]
E Right contains one more item: 1.0
E Full diff:
E - [0.0, 1.0]
E + [0.0]
tests/test_event.py:115: AssertionError
Captured stdout setup
-
Ready to accept request
Captured stderr setup
-
Can't create notifd event supplier. Notifd event not available
_ test_push_event_with_timestamp[Synchronous]
__
event_device = EventDevice(test/nodb/eventdevice)
def test_push_event_with_timestamp(event_device):
string = StringIO()
ec = EventCallback(fd=string)
# Subscribe
eid = event_device.subscribe_event(
"attr", EventType.CHANGE_EVENT, ec, wait=True)
assert eid == 1
# Trigger an event
event_device.command_inout("send_event_with_timestamp", wait=True)
# Wait for tango event
retries = 20
for _ in range(retries):
event_device.read_attribute("state", wait=True)
if len(ec.get_events()) > 1:
break
time.sleep(0.05)
# Test the event values and timestamp
results = [evt.attr_value.value for evt in ec.get_events()]
assert results == [0., 2.]
E assert [0.0] == [0.0, 2.0]
E Right contains one more item: 2.0
E Full diff:
E - [0.0, 2.0]
E + [0.0]
tests/test_event.py:191: AssertionError
Captured stdout setup
-
Ready to accept request
Captured stderr setup
-
Can't create notifd event supplier. Notifd event not available
=== warnings summary
===
tests/test_client.py:19
/tmp/autopkgtest-lxc.q395dj8v/downtmp/autopkgtest_tmp/tests/test_client.py:19:
DeprecationWarning: The distutils package is deprecated and slated for
removal in Python 3.12. Use setuptools or check PEP 632 for potential
alternatives
from distutils.spawn import find_executable
-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== short test summary info
FAILED tests/test_event.py::test_subscribe_change_event[Synchronous]
FAILED tests/test_event.py::test_push_event_with_timestamp[Synchronous]
== 2 failed, 1033 passed, 26 xfailed, 1 warning in 263.04s (0:04:23)
===
autopkgtest [07:52:48]: test command1
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1003255: (no subject)
Control: retitle -1 PSTricks requests to use -dALLOWPSTRANSPARENCY even if not
needed.
On 07.01.22 Peter Mueller (petermuel...@ro.ru) wrote:
Hi,
giving that bug a sane title.
Hilmar
> From: Peter Mueller
> Reply-To: Peter Mueller , 1003...@bugs.debian.org
> To: submit
> Subject: Bug#1003255: (no subject)
> Date: Fri, 07 Jan 2022 01:40:48 +
> Message-Id: <3f04cf95e7eb5c42dc3e1d590f348...@mail.rambler.ru>
> X-Mailer: Rambler Compose (2.1.0), https://mail.rambler.ru
> X-Mailing-List: archive/latest/35254
>
> Package: texlive-pstricks
> Version: 2021.20211217-1
> Let's construct mwe.tex containing
> \documentclass{article} \usepackage{pstricks} \begin{document} test
> \end{document}
> and run
> latex mwe && dvipdf mwe
> or
> latex mwe && dvips mwe && ps2pdf mwe.ps
>
Bug#1016748: mathcomp-analysis: FTBFS: test failure: Error: apply-w-params
Source: mathcomp-analysis Version: 0.5.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Rebuilds of mathcomp-analysis failed: COQC theories/realfun.v COQC theories/exp.v COQC theories/lebesgue_measure.v File "./theories/lebesgue_measure.v", line 133, characters 0-76: Warning: Casts are ignored in patterns [cast-in-pattern,automation] File "./theories/lebesgue_measure.v", line 133, characters 0-76: Warning: Casts are ignored in patterns [cast-in-pattern,automation] COQC theories/lebesgue_integral.v COQC theories/trigo.v File "./theories/lebesgue_integral.v", line 201, characters 0-51: Error: apply-w-params make[3]: *** [Makefile.coq:764: theories/lebesgue_integral.vo] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [Makefile.coq:387: all] Error 2 Cheers -- Sebastian Ramacher
Bug#1016747: kea: Adjust log file in default config to match Debian config
Package: kea
Version: 2.0.2-3
Severity: normal
Dear Maintainer,
the package will install
/etc/kea/kea-{ctrl-agent,dhcp4,dhcp6,dhcp-ddns}.conf
files which all have set
> "loggers": [
> {
> "output_options": [
> {
> // Specifies the output file. There are several
special values
> // supported:
> // - stdout (prints on standard output)
> // - stderr (prints on standard error)
> // - syslog (logs to syslog)
> // - syslog:name (logs to syslog using specified name)
> // Any other value is considered a name of the file
> "output":
"/var/log/kea-{ctrl-agent,dhcp4,dhcp6,dhcp-ddns}.log"
> }
> ]
> }
> ]
However, default kea services cannot write to this location because they
are running as "_kea" user on Debian by default.
You are already creating /var/log/kea so I would suggest to update
default config to use that directory by default.
I run into this when I increased severity of log messages to debug an
issue but didn't find any logs. After adjusting paths I got the logs
I was looking for.
Thanks!
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages kea depends on:
ii kea-admin 2.0.2-3
ii kea-ctrl-agent2.0.2-3
ii kea-dhcp-ddns-server 2.0.2-3
ii kea-dhcp4-server 2.0.2-3
ii kea-dhcp6-server 2.0.2-3
kea recommends no packages.
kea suggests no packages.
-- no debconf information
Bug#997024: [greek]babel + cleveref + pagenumbering + label = ☇
Am 29.06.2022 um 02:53 teilte Peter Müller mit: Hi, I've just tested it, and the answer is no. The bug is still there with - pdfTeX, Version 3.141592653-2.6-1.40.22 (TeX Live 2022/dev/Debian) Yes, correct, else I'd have closed it already. I keep the bug open plase be so kind to contact the author of cleveref if not done yet. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1016746: sbcl breaks cffi autopkgtest: /usr/bin/ld: cannot find -lzstd: No such file or directory
Source: sbcl, cffi Control: found -1 sbcl/2:2.2.6-2 Control: found -1 cffi/1:0.24.1-2 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of sbcl the autopkgtest of cffi fails in testing when that autopkgtest is run with the binary packages of sbcl from unstable. It passes when run with only packages from testing. In tabular form: passfail sbcl from testing2:2.2.6-2 cffi from testing1:0.24.1-2 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration of sbcl to testing [1]. Due to the nature of this issue, I filed this bug report against both packages. Can you please investigate the situation and reassign the bug to the right package? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=sbcl https://ci.debian.net/data/autopkgtest/testing/amd64/c/cffi/24381426/log.gz ; wrote /tmp/autopkgtest-lxc.qpgu5j9b/downtmp/autopkgtest_tmp/usr/share/common-lisp/source/cl-cffi/tests/grovel-tmpFNKDE5XP.fasl ; compilation finished in 0:00:00.015 ;;; running tests (uncompiled) Doing 332 pending tests of 332 tests total. LOAD-CORE-FOUNDATION FUNCALL.CHAR FUNCALL.INT.1 FUNCALL.INT.2 FUNCALL.LONG FUNCALL.LONG-LONG FUNCALL.UNSIGNED-LONG-LONG FUNCALL.FLOAT FUNCALL.DOUBLE FUNCALL.STRING.1 FUNCALL.STRING.2 FUNCALL.STRING.3 FUNCALL.VARARGS.NOSTDLIB FUNCALL.VARARGS.CHAR FUNCALL.VARARGS.INT FUNCALL.VARARGS.LONG FUNCALL.VARARGS.DOUBLE FUNCALL.VARARGS.STRING FUNCALL.DOUBLE26 FUNCALL.FLOAT26 FUNCALL.F-S-P.1 FUNCALL.NIL-SKIP FUNCALL.POINTER-NOT-NIL DEFCFUN.PARSE-NAME-AND-OPTIONS.1 DEFCFUN.PARSE-NAME-AND-OPTIONS.2 DEFCFUN.PARSE-NAME-AND-OPTIONS.3 DEFCFUN.PARSE-NAME-AND-OPTIONS.4 DEFCFUN.PARSE-NAME-AND-OPTIONS.5 DEFCFUN.PARSE-NAME-AND-OPTIONS.6 DEFCFUN.PARSE-NAME-AND-OPTIONS.7 DEFCFUN.PARSE-NAME-AND-OPTIONS.8 TRANSLATE-UNDERSCORE-SEPARATED-NAME.TO-SYMBOL TRANSLATE-UNDERSCORE-SEPARATED-NAME.TO-STRING TRANSLATE-CAMELCASE-NAME.TO-SYMBOL TRANSLATE-CAMELCASE-NAME.TO-STRING TRANSLATE-CAMELCASE-NAME.TO-STRING-UPPER TRANSLATE-CAMELCASE-NAME.TO-SYMBOL-SPECIAL TRANSLATE-CAMELCASE-NAME.TO-STRING-SPECIAL TRANSLATE-NAME-FROM-FOREIGN.FUNCTION TRANSLATE-NAME-FROM-FOREIGN.VAR TRANSLATE-NAME-TO-FOREIGN.FUNCTION TRANSLATE-NAME-TO-FOREIGN.VAR DEFCFUN.CHAR DEFCFUN.DOCSTRING DEFCFUN.INT DEFCFUN.LONG DEFCFUN.LONG-LONG DEFCFUN.UNSIGNED-LONG-LONG DEFCFUN.FLOAT DEFCFUN.DOUBLE DEFCFUN.STRING.1 DEFCFUN.STRING.2 DEFCFUN.STRING.3 DEFCFUN.NOARGS DEFCFUN.NOOP DEFCFUN.VARARGS.NOSTDLIB DEFCFUN.VARARGS.DOCSTRINGS DEFCFUN.VARARGS.CHAR DEFCFUN.VARARGS.SHORT DEFCFUN.VARARGS.INT DEFCFUN.VARARGS.LONG DEFCFUN.VARARGS.FLOAT DEFCFUN.VARARGS.DOUBLE DEFCFUN.VARARGS.STRING DEFCFUN.BFF.1 DEFCFUN.BFF.2 DEFCFUN.UNDEFINED DEFCFUN.DOUBLE26 DEFCFUN.FLOAT26 CALLBACKS.CHAR CALLBACKS.UNSIGNED-CHAR CALLBACKS.SHORT CALLBACKS.UNSIGNED-SHORT CALLBACKS.INT CALLBACKS.UNSIGNED-INT CALLBACKS.LONG CALLBACKS.UNSIGNED-LONG CALLBACKS.LONG-LONG CALLBACKS.UNSIGNED-LONG-LONG CALLBACKS.FLOAT CALLBACKS.DOUBLE CALLBACKS.POINTER CALLBACKS.STRING CALLBACKS.STRING-NOT-DOCSTRING CALLBACKS.NIL-FOR-NULL CALLBACKS.QSORT CALLBACKS.VOID CALLBACKS.FUNCALL.1 CALLBACKS.FUNCALL.2 CALLBACKS.BFF.1 CALLBACKS.BFF.2 CALLBACKS.NON-EXISTANT CALLBACKS.DOUBLE26 CALLBACKS.DOUBLE26.FUNCALL CALLBACKS.FLOAT26 CALLBACKS.FLOAT26.FUNCALL CALLBACKS.UNINTERNED FOREIGN-GLOBALS.REF.CHAR FOREIGN-GLOBALS.REF.UNSIGNED-CHAR FOREIGN-GLOBALS.REF.SHORT FOREIGN-GLOBALS.REF.UNSIGNED-SHORT FOREIGN-GLOBALS.REF.INT FOREIGN-GLOBALS.REF.UNSIGNED-INT FOREIGN-GLOBALS.REF.LONG FOREIGN-GLOBALS.REF.UNSIGNED-LONG FOREIGN-GLOBALS.REF.FLOAT FOREIGN-GLOBALS.REF.DOUBLE FOREIGN-GLOBALS.REF.POINTER FOREIGN-GLOBALS.REF.STRING FOREIGN-GLOBALS.REF.LONG-LONG FOREIGN-GLOBALS.REF.UNSIGNED-LONG-LONG FOREIGN-GLOBALS.SET.INT FOREIGN-GLOBALS.SET.STRING FOREIGN-GLOBALS.SET.LONG-LONG FOREIGN-GLOBALS.GET-VAR-POINTER.1 FOREIGN-GLOBALS.GET-VAR-POINTER.2 FOREIGN-GLOBALS.REF.UPPERCASEINT1 FOREIGN-GLOBALS.REF.UPPER-CASE-INT1 FOREIGN-GLOBALS.REF.MIXEDCASEINT1 FOREIGN-GLOBALS.REF.MIXED-CASE-INT1 FOREIGN-GLOBALS.REF.UPPERCASEINT2 FOREIGN-GLOBALS.REF.UPPER-CASE-INT2 FOREIGN-GLOBALS.REF.MIXEDCASEINT2 FOREIGN-GLOBALS.REF.MIXED-CASE-INT2 FOREIGN-GLOBALS.REF.UPPERCASEINT3 FOREIGN-GLOBALS.REF.UPPER-CASE-INT3 FOREIGN-GLOBALS.REF.MIXEDCASEINT3 FOREIGN-GLOBALS.REF.MIXED-CASE-INT3 FOREIGN-GLOBALS.SYMBOL-NAME FOREIGN-GLOBALS.READ-ONLY.1 DEFCVAR.DOCSTRING FOREIGN-GLOBALS.UNDEFINED.1 FOREIGN-GLOBALS.ERROR.1 DEREF.CHAR DEREF.UNSIGNED-CHAR DEREF.SHORT DEREF.UNSIGNED-SHORT DEREF.INT DEREF.UNSIGNED-INT DEREF.LONG DEREF.UNSIGNED-LONG DEREF.LONG-LONG DEREF.UNSIGNED-LONG-LONG DEREF.FLOAT.1 DEREF.FLOAT.2
Bug#1016745: tracker-miner-fs: at 100% CPU activity for long minutes
Package: tracker-miner-fs Version: 3.3.1-2 Severity: important Dear Maintainer, I am facing something very similar to the following: https://gitlab.gnome.org/GNOME/tracker/-/issues/373 What can I do to see what is going on? Trying: $ tracker status but without success, the command was blocked maybe until the tracker-miner-fs finished. Its removal is also not possible as Nautilus depends on it. So I just tried to mask its .service Note that login into a text console (tty) starts also some services among which is the tracker-miner-fs one. Thanks, Patrice -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-trunk-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tracker-miner-fs depends on: ii init-system-helpers 1.64 ii libc62.33-8 ii libglib2.0-0 2.72.3-1 ii libtracker-sparql-3.0-0 3.3.2-1 ii libupower-glib3 0.99.20-1 ii procps 2:3.3.17-7+b1 ii tracker 3.3.2-1 ii tracker-extract 3.3.1-2 tracker-miner-fs recommends no packages. tracker-miner-fs suggests no packages.
Bug#637127: biblatex: Version 1.6-1 breaks "refsection=part" functionality
Am 08.08.2011 um 18:53 teilte Gunnar Wolf mit:
Hi Gunnar,
just a gentle reminder.
I do not understand so much about biblatex and biber. On [1] (see
comment from PLK) it is recommended to run biber on the aux file to
generate the bibliography. I could download your document from [2] and
processed the aux file using biber (bibtex fails to run anyway). I'm not
sure how the resulting pdf is expected to look like, but each the part
doesn't contain the full bibliography and the generated seco3.bbl
contains the information which part of the bib belongs to which document
part.
So my conclusion would be: when using biber the bibliography is in one
files instead of partial blx.aux files.
Can we close the issue?
Hilmar
[1] https://tex.stackexchange.com/questions/19326/section-bibliographies
[2] https://gitlab.com/gunnarwolf/seco3
Upon installing biblatex 1.6-1, my book (which includes a references
section per part) no longer generates the partial *.blx.aux files when
being built. My preamble includes:
\usepackage[style=authoryear, backref=true, backrefstyle=two,
refsection=part, block=ragged]{biblatex}
\ExecuteBibliographyOptions{ autocite=inline, sortcites=true,
labelyear=true, uniquename=true}
\bibliography{seco3}
So, from the seco3.bib file, four files (one per part --
seco31.blx.aux, seco32.blx.aux, seco33.blx.aux, seco34.blx.aux) should
be generated, and bibtex is run for each. Of course, if I run bibtex
on the core seco3.aux file, the complete reference section is repeated
at the end of each part.
Downgrading to 1.4c-1 fixes the problem.
Full sources for the book are available on request (of course, I'm not
inlining them here in order not to bloat the BTS and your mailbox)
--
sigfault
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1016744: vim-ultisnips: autopkgtest failure on arm64, i386 and ppc64el
Source: vim-ultisnips Version: 3.2-1 Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), You recently added an autopkgtest to your package vim-ultisnips, great. However, it fails on arm64, i386 and ppc64el. Currently this failure is blocking the migration to testing [1]. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=vim-ultisnips https://ci.debian.net/data/autopkgtest/testing/arm64/v/vim-ultisnips/23984911/log.gz == FAIL: runTest (test_ParseSnippets.ParseSnippets_ExtendsWithoutFiletype) -- Traceback (most recent call last): File "/tmp/autopkgtest-lxc.p149hn5f/downtmp/build.kSM/src/test/vim_test_case.py", line 53, in runTest self.assertRegexpMatches(self.output, self.expected_error) AssertionError: Regex didn't match: "'extends' without file types in \\S+:2" not found in 'An error occured. This is either a bug in UltiSnips or a bug in a\nsnippet definition. If you think this is a bug, please report it to\nhttps://github.com/SirVer/ultisnips/issues/new\nPlease read and follow:\nhttps://github.com/SirVer/ultisnips/blob/master/CONTRIBUTING.md#reproducing-bugs\n\nFollowing is the full stack trace:\nTraceback (most recent call last):\n File "/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/err_to_scratch_buffer.py", line 18, in wrapper\nreturn func(self, *args, **kwds)\n File "/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet_manager.py", line 905, in _track_change\n self._try_expand(autotrigger_only=True)\n File "/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet_manager.py", line 749, in _try_expand\nsnippets = self._snips(before, False, autotrigger_only)\n File "/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet_manager.py", line 629, in _snips\nsource.ensure(filetypes)\n File "/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet/source/file/base.py", line 31, in ensure\nself._load_snippets_for(ft)\n File "/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet/source/file/base.py", line 53, in _load_snippets_for\nself._parse_snippets(ft, fn)\n File "/usr/share/nvim/site/pack/dist-bundle/opt/ultisnips/pythonx/UltiSnips/snippet/source/file/base.py", line 69, in _parse_snippets\nraise SnippetSyntaxError(filename, line_index, msg)\nUltiSnips.snippet.source.file.base.SnippetSyntaxError: \'extends\' without file types in /tmp/p\tautopkgtest-lxc.p149hn5f/downtmp/autopkgtest_tmp/UltiSnipsTest_Casenir0duuw/us/all.snippets:2' -- Ran 560 tests in 1259.152s FAILED (failures=1, skipped=4) autopkgtest [05:49:55]: test with-neovim OpenPGP_signature Description: OpenPGP digital signature
Bug#1016743: zalign: autopkgtest failure on 32 bit architectures: Segmentation fault
Source: zalign Version: 0.9.1-6 Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), You recently added an autopkgtest to your package zalign, great. However, it fails. Currently this failure is blocking the migration to testing [1]. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=zalign https://ci.debian.net/data/autopkgtest/testing/armhf/z/zalign/23914703/log.gz [93m[1mRunning Tests[0m [93m[1mTest 1[0m Stage 1: Distribute data to all nodes - # File parameters S sequence: 104 characters Filename: dd T sequence: 104 characters Filename: rt # Performance parameters Number of 'split' submatrices: 1 Available nodes:1 Horizontal block divisions:10 Vertical block divisions: 10 # Scoring parameters Match: 1 Mismatch: -3 Gap Opening: -5 Gap Extension: -2 Stage 2: Find best scores - Showing progress information for root node (rank 0): split 1/1: || 0%* | 1%* | 2%** | 3%** | 4%** | 5%*** | 6%*** | 7% | 8% | 9% | 10%* | 11%* | 12%** | 13%** | 14%** | 15%*** | 16%*** | 17% | 18% | 19% | 20%* | 21%* | 22%** | 23%** | 24%** | 25%*** | 26%*** | 27% | 28% | 29% | 30%* | 31%* | 32%** | 33%** | 34%** | 35%*** | 36%*** | 37% |
Bug#1016742: libcereal: autopkgtest regression: add_subdirectory given source "sandbox" which is not an existing directory
Source: libcereal Version: 1.3.2+dfsg-1 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of libcereal the autopkgtest of libcereal fails in testing when that autopkgtest is run with the binary packages of libcereal from unstable. It passes when run with only packages from testing. In tabular form: passfail libcereal from testing1.3.2+dfsg-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=libcereal https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libcereal/24396353/log.gz -- The CXX compiler identification is GNU 11.3.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found version "1.74.0") found components: serialization -- boost_variant.cpp CMake Error at CMakeLists.txt:123 (add_subdirectory): add_subdirectory given source "sandbox" which is not an existing directory. -- Configuring incomplete, errors occurred! See also "/tmp/autopkgtest-lxc.q81fqk9c/downtmp/autopkgtest_tmp/CMakeFiles/CMakeOutput.log". make: *** No targets specified and no makefile found. Stop. autopkgtest [03:11:34]: test run-unit-test OpenPGP_signature Description: OpenPGP digital signature
Bug#1016741: Wrong paths to nm-initrd-generator
Package: dracut-network Version: 056-3 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 /usr/lib/dracut/modules.d/35network-manager/module-setup.sh and /usr/lib/dracut/modules.d/35network-manager/nm-lib.sh look for nm-initrd-generator in /usr/libexec and /usr/lib. However, network-manager actually ships it in /usr/lib/NetworkManager/. This prevents the network-manager module from working in the initrd. - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 'buildd-unstable'), (500, 'unstable'), (102, 'experimental-debug'), (102, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0+ (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dracut-network depends on: pn dracut-core ii iputils-arping 3:20211215-1 ii isc-dhcp-client 4.4.3-2 Versions of packages dracut-network recommends: ii curl7.84.0-2 pn nbd-client pn nfs-common pn open-iscsi dracut-network suggests no packages. -BEGIN PGP SIGNATURE- iHEEARECADEWIQSwn681vpFFIZgJURRaga+OatuyAAUCYu5tbhMcbWljaGVsQGRh ZW56ZXIubmV0AAoJEFqBr45q27IA8YQAnRTdZ0xH9LqUxjWrucgjVyoCCopQAJ9e RmC2sgy9r9egd531hAZwopf0FA== =lxbV -END PGP SIGNATURE-
Bug#1016740: golang-github-cli-go-gh: autopkgtest regression: TestGQLClientDoWithContext/http_fail_request_timed_out
Source: golang-github-cli-go-gh Version: 0.0.3+git20220623.91ca4ef-1 Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of golang-github-cli-go-gh the autopkgtest of golang-github-cli-go-gh fails in testing when that autopkgtest is run with the binary packages of golang-github-cli-go-gh from unstable. It passes when run with only packages from testing. In tabular form: passfail golang-github-cli-go-gh from testing0.0.3+git20220623.91ca4ef-1 all others from testingfrom testing I copied some of the output at the bottom of this report. Currently this regression is blocking the migration to testing [1]. Can you please investigate the situation and fix it? More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=golang-github-cli-go-gh https://ci.debian.net/data/autopkgtest/testing/amd64/g/golang-github-cli-go-gh/24389592/log.gz === RUN TestGQLClientDoWithContext/http_fail_request_canceled gql_client_test.go:170: Error Trace:gql_client_test.go:170 Error: An error is expected but got nil. Test: TestGQLClientDoWithContext/http_fail_request_canceled === RUN TestGQLClientDoWithContext/http_fail_request_timed_out gql_client_test.go:170: Error Trace:gql_client_test.go:170 Error: An error is expected but got nil. Test: TestGQLClientDoWithContext/http_fail_request_timed_out --- FAIL: TestGQLClientDoWithContext (0.00s) --- FAIL: TestGQLClientDoWithContext/http_fail_request_canceled (0.00s) --- FAIL: TestGQLClientDoWithContext/http_fail_request_timed_out (0.00s) === RUN TestRESTClientDoWithContext/http_fail_request_canceled rest_client_test.go:341:Error Trace:rest_client_test.go:341 Error: An error is expected but got nil. Test: TestRESTClientDoWithContext/http_fail_request_canceled === RUN TestRESTClientDoWithContext/http_fail_request_timed_out rest_client_test.go:341:Error Trace:rest_client_test.go:341 Error: An error is expected but got nil. Test: TestRESTClientDoWithContext/http_fail_request_timed_out --- FAIL: TestRESTClientDoWithContext (0.00s) --- FAIL: TestRESTClientDoWithContext/http_fail_request_canceled (0.00s) --- FAIL: TestRESTClientDoWithContext/http_fail_request_timed_out (0.00s) === RUN TestRESTClientRequestWithContext === RUN TestRESTClientRequestWithContext/http_fail_request_canceled rest_client_test.go:394:Error Trace:rest_client_test.go:394 Error: An error is expected but got nil. Test: TestRESTClientRequestWithContext/http_fail_request_canceled === RUN TestRESTClientRequestWithContext/http_fail_request_timed_out rest_client_test.go:394:Error Trace:rest_client_test.go:394 Error: An error is expected but got nil. Test: TestRESTClientRequestWithContext/http_fail_request_timed_out --- FAIL: TestRESTClientRequestWithContext (0.00s) --- FAIL: TestRESTClientRequestWithContext/http_fail_request_canceled (0.00s) --- FAIL: TestRESTClientRequestWithContext/http_fail_request_timed_out (0.00s) === RUN TestRestPrefix === RUN TestRestPrefix/github === RUN TestRestPrefix/localhost === RUN TestRestPrefix/enterprise --- PASS: TestRestPrefix (0.00s) --- PASS: TestRestPrefix/github (0.00s) --- PASS: TestRestPrefix/localhost (0.00s) --- PASS: TestRestPrefix/enterprise (0.00s) FAIL FAILgithub.com/cli/go-gh/internal/api 0.007s OpenPGP_signature Description: OpenPGP digital signature
Bug#1016739: rust-serde: please update to v1.0.142
Source: rust-serde Version: 1.0.130-2 Severity: normal Tags: upstream -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please update to upstream release 1.0.142, needed by projcts I am preparing for Debian. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmLubqcACgkQLHwxRsGg ASF4IQ/9FtnvoVIr6ZPigv6HmbdrsNcDgYWLCM7t+HSZhtnds9SZB+jamHIqukwo QFaX+atZfiHKLE3+0PVH5SxkpfYhmAEoCn6wr28TGMhaYVDxYoTwDTJmUKb+Fsht 67cQHXgegOydr161ECQ6RHg2C8NF7Le3FeWCpUIdre9zGMC3hoHvSA28gEg5QZNG 1CCOg3oUp4QejsPvJnsHj3FDlNP+86aUYtq5mtyRjjzhIT7HSE5XER82voOAz4Se 8xXg8Zf9iMRMvszweqyutXTaMchsJYxkfRAI4DgYyWighjXedlcLORO7JSqwhL0W I7kKcWOSByOvyGziZNc3x7E+aAFj9mSsBwwdIUVnZL5DtAUQdnKzOANVx4UCEDNW 797+7w1h01QDTc+60IGrdDMeA6D8GkKVQLJeqCcuA7G4H6wY3+yTqtZRBXWye5e5 EaR3TmUE9zToLBOp2f4QQ3JOQpV1GJLT5v5DFkf3SkBAQvYvCroXWLOI0cXYAm7n 9qfmNjRkLVm+HlMgW6WgAf4+stkWPktaXeiK/RUngmkTOgm5nX3GXmrgNGP4VMcj w2KMO3zY1C9Kiv7kITRVre+XzjtdEsh0c+8ZRSlIxvT047U2mzFBA6oKFw5+Om78 XE5uHWfd6BSarIdZB9/Dzt2MnauyI9e4YoKj+uRDryLpHgkjVXs= =c7mH -END PGP SIGNATURE-
Bug#1016736: nvidia-kernel-dkms: Fail to build with linux 5.19 (patch available in Ubuntu)
On 06 août 2022 15:31, Andreas Beckmann wrote: > On 06/08/2022 15.20, Christian Marillat wrote: >> Package: nvidia-kernel-dkms >> Version: 470.129.06-6 > > There is a new upstream release fixing this as well as some CVEs, I'm > currently working through the driver variants ... 390xx-legacy is > already done. Ha, OK, then sorry for the bug report. Christian
Bug#1016738: dt-schema: autopkgtest failure: No module named 'libfdt'
Source: dt-schema Version: 2022.07-1 Severity: serious User: debian...@lists.debian.org Usertags: fails-always Dear maintainer(s), You recently added an autopkgtest to your package dt-schema, great. However, it fails. Currently this failure is blocking the migration to testing [1]. Can you please investigate the situation and fix it? I copied some of the output at the bottom of this report. It seems you are missing a dependency. More information about this bug and the reason for filing it can be found on https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation Paul [1] https://qa.debian.org/excuses.php?package=dt-schema https://ci.debian.net/data/autopkgtest/testing/amd64/d/dt-schema/24372986/log.gz === python3.10 === Traceback (most recent call last): File "/tmp/autopkgtest-lxc.ard1nynt/downtmp/autopkgtest_tmp/test/test-dt-validate.py", line 20, in import dtschema File "/usr/lib/python3/dist-packages/dtschema/__init__.py", line 1, in from dtschema.lib import ( File "/usr/lib/python3/dist-packages/dtschema/lib.py", line 18, in import dtschema.dtb File "/usr/lib/python3/dist-packages/dtschema/dtb.py", line 9, in import libfdt ModuleNotFoundError: No module named 'libfdt' autopkgtest [08:11:46]: test unittests OpenPGP_signature Description: OpenPGP digital signature
Bug#1016736: nvidia-kernel-dkms: Fail to build with linux 5.19 (patch available in Ubuntu)
On 06/08/2022 15.20, Christian Marillat wrote: Package: nvidia-kernel-dkms Version: 470.129.06-6 There is a new upstream release fixing this as well as some CVEs, I'm currently working through the driver variants ... 390xx-legacy is already done. Andreas
Bug#1016737: Loop in POST when using --removable option in grub-install
Package: grub-efi-amd64
Version: 2.04-20
Severity: normal
X-Debbugs-Cc: none
Dear Maintainer,
*** Reporter, please consider answering these questions, where
appropriate ***
I run grub-install --target=x86_64-efi --efi-directory=/boot/efi
--removable and reboot, it repeats POST forever and loops.
This bug does not occur on Arch Linux, so it appears to be Debian-specific.
*** End of the template - remove these template lines ***
-- Package-specific info:
*** BEGIN /proc/mounts
/dev/sda2 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda1 /boot/efi vfat
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
*** END /proc/mounts
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
set have_grubenv=true
load_env
fi
if [ "${next_entry}" ] ; then
set default="${next_entry}"
set next_entry=
save_env next_entry
set boot_once=true
else
set default="0"
fi
if [ x"${feature_menuentry_id}" = xy ]; then
menuentry_id_option="--id"
else
menuentry_id_option=""
fi
export menuentry_id_option
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
if [ x$feature_all_video_module = xy ]; then
insmod all_video
else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
fi
}
if [ x$feature_default_font_path = xy ] ; then
font=unicode
else
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
4ac6e20f-f814-426a-9de9-b33d490010a6
else
search --no-floppy --fs-uuid --set=root
4ac6e20f-f814-426a-9de9-b33d490010a6
fi
font="/usr/share/grub/unicode.pf2"
fi
if loadfont $font ; then
set gfxmode=auto
load_video
insmod gfxterm
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
set timeout=30
else
if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
# Fallback normal timeout code in case the timeout_style feature is
# unavailable.
else
set timeout=5
fi
fi
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
4ac6e20f-f814-426a-9de9-b33d490010a6
else
search --no-floppy --fs-uuid --set=root
4ac6e20f-f814-426a-9de9-b33d490010a6
fi
insmod png
if background_image
/usr/share/desktop-base/homeworld-theme/grub/grub-4x3.png; then
set color_normal=white/black
set color_highlight=black/white
else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class
gnu --class os $menuentry_id_option
'gnulinux-simple-4ac6e20f-f814-426a-9de9-b33d490010a6' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2
4ac6e20f-f814-426a-9de9-b33d490010a6
else
search --no-floppy --fs-uuid --set=root
4ac6e20f-f814-426a-9de9-b33d490010a6
fi
echo 'Loading Linux 5.10.0-16-amd64 ...'
linux /boot/vmlinuz-5.10.0-16-amd64
root=UUID=4ac6e20f-f814-426a-9de9-b33d490010a6 ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-5.10.0-16-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option
'gnulinux-advanced-4ac6e20f-f814-426a-9de9-b33d490010a6' {
menuentry 'Debian GNU/Linux, with Linux 5.10.0-16-amd64' --class
debian --class gnu-linux --class gnu --class os $menuentry_id_option
'gnulinux-5.10.0-16-amd64-advanced-4ac6e20f-f814-426a-9de9-b33d490010a6' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search
Bug#1016732: node-sockjs throws: TypeError: Cannot read properties of undefined (reading 'addEventListener') at WebSocketReceiver.setUp
Yadd, Since you added in coffeescript patch for this package, I'd highly appreciate if you could consider taking a look. On Sat, 06 Aug 2022 17:54:13 +0530 Nilesh Patra wrote: > Package: node-sockjs > Version: 0.3.24+~0.3.33-1 > Severity: serious > X-Debbugs-Cc: e...@ericebrown.com > > Hi, > > On running shiny-server with 0.3.24+~0.3.33-1 it chokes with: > > | [2022-08-06T04:59:03.613] [ERROR] shiny-server - Uncaught exception: > TypeError: Cannot read properties of undefined (reading 'addEventListener') > | [2022-08-06T04:59:03.614] [ERROR] shiny-server - TypeError: Cannot read > properties of undefined (reading 'addEventListener') > |at WebSocketReceiver.setUp > (/usr/share/nodejs/sockjs/lib/trans-websocket.js:76:24) > |at new GenericReceiver (/usr/share/nodejs/sockjs/lib/transport.js:313:12) > |at new WebSocketReceiver > (/usr/share/nodejs/sockjs/lib/trans-websocket.js:63:9) > |at ws.onopen (/usr/share/nodejs/sockjs/lib/trans-websocket.js:31:55) > |at WebSocket.dispatchEvent > (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api/event_target.js:24:30) > |at WebSocket._open > (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api.js:144:10) > |at Hybi. > (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api.js:35:49) > |at Hybi.emit (node:events:513:28) > |at Hybi._open > (/usr/share/nodejs/websocket-driver/lib/websocket/driver/base.js:148:10) > |at Hybi.start > (/usr/share/nodejs/websocket-driver/lib/websocket/driver/base.js:105:34) > | [2022-08-06T04:59:03.615] [INFO] shiny-server - Stopping listener on > http://[::]:3838 > | [2022-08-06T04:59:03.615] [INFO] shiny-server - Shutting down worker > processes (with notification) > | /usr/lib/shiny-server/lib/main.js:391 > | throw err; > | ^ > | > | TypeError: Cannot read properties of undefined (reading 'addEventListener') > |at WebSocketReceiver.setUp > (/usr/share/nodejs/sockjs/lib/trans-websocket.js:76:24) > |at new GenericReceiver (/usr/share/nodejs/sockjs/lib/transport.js:313:12) > |at new WebSocketReceiver > (/usr/share/nodejs/sockjs/lib/trans-websocket.js:63:9) > |at ws.onopen (/usr/share/nodejs/sockjs/lib/trans-websocket.js:31:55) > |at WebSocket.dispatchEvent > (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api/event_target.js:24:30) > |at WebSocket._open > (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api.js:144:10) > |at Hybi. > (/usr/share/nodejs/faye-websocket/lib/faye/websocket/api.js:35:49) > |at Hybi.emit (node:events:513:28) > |at Hybi._open > (/usr/share/nodejs/websocket-driver/lib/websocket/driver/base.js:148:10) > |at Hybi.start > (/usr/share/nodejs/websocket-driver/lib/websocket/driver/base.js:105:34) > | > | Node.js v18.6.0 > > > While it is running perfectly ok _with 0.3.24-2_. Since this is > not a new release, there is a regression with the new changelog revision. > > In particular, it seems that something is off with the coffeescript > generated files. > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.14.0-2-amd64 (SMP w/8 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > -- Best, Nilesh signature.asc Description: PGP signature
Bug#1016735: O: safe-iop -- Safe integer operation library
Package: wnpp Severity: normal This is a dependency of Android SDK components. I am no longer active in Debian. Therefore, I orphan this package. OpenPGP_0xDD1FAB8937FE9825.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1016731: dictionaries-common: Badly generated /var/cache/dictionaries-common/emacsen-ispell-dicts.el for Hebrew
El sáb, 6 ago 2022 a las 14:09, Itaï BEN YAACOV () escribió:
>
> Package: dictionaries-common
> Version: 1.28.15
> Severity: normal
>
> Dear Maintainer,
>
> With hunspell-he installed, starting emacs I get the following error message :
>
> Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...
> Error while loading 50dictionaries-common: Invalid read syntax: "] in a list"
>
> Without that package, no problem.
> The origin seems to be in the file
> /var/cache/dictionaries-common/emacsen-ispell-dicts.el , that contains the
> following lines :
>
> (add-to-list 'debian-hunspell-only-dictionary-alist
> '("hebrew"
>
> "[a-zA-Z\327\231\327\225\327\224\327\220\327\242\327\227\327\233\327\247\327\251\327\241\327\226\327\223\327\222\327\221\327\250\327\240\327\236\327\230\327\246\327\252\327\244\327\235\327\243\327\232\327\245\327\237\327\234]"
>
> "[^a-zA-Z\327\231\327\225\327\224\327\220\327\242\327\227\327\233\327\247\327\251\327\241\327\226\327\223\327\222\327\221\327\250\327\240\327\236\327\230\327\246\327\252\327\244\327\235\327\243\327\232\327\245\327\237\327\234]"
> "[אבגדהוזחטיכלמנסעפצקרשתםןךףץ'"]"
> nil
> ("-d" "he_IL")
> nil
> utf-8))
>
> You will notice the unescaped " in the fifth line, followed indeed by the
> character ] ...
> Since the file is generated by perl (if I understand correctly, it is
> generated by /usr/share/perl5/Debian/DictionariesCommon.pm), this is where I
> stopped digging.
>
> Can that perl script be repaired so as to escape double quotes when
> appropriate ?
Hi, thanks for the info.
It should not be hard to fix once I find some time for that. Will let you know.
Regards,
..
Agustin
Bug#1001261: rclone: new upstream release 1.57.0
retitle 1001261 new upstream release (1.59) thanks ...and by now it it's 1.59. it would be really nice to have the bugfixes of the newer versions. Regards, Daniel
Bug#537284: Ligature fi becoming ø in avant garde
Control: severity -1 minor
Control: notforwarded -1
Am 16.07.2009 um 19:27 teilte Anthony DeRobertis mit:
Hi,
As explained the issue is now solved, except for "chancery". I lower to
minor for now. Please not that I had to change the command to "mk4ht
htlatex a.tex", else the compilation fails. As I don't understand
anything of tex4ht I can't tell if this is a new bug.
Hilmar
The following input:
\documentclass{article}
\usepackage{avant}
\usepackage[T1]{fontenc}
\begin{document}
first
\textsf{first}
\end{document}
with the following command:
mk4ht htlatex a.tex "html,uni-html4,css2,charset=utf-8,info" " -cunihtf
-utf8"
gets the following HTML output:
first
ørst
Notice how the fi (fi; U+FB01) ligature becomes ø (small o stroke; U+00F8).
--
sigfault
OpenPGP_signature
Description: OpenPGP digital signature
