Bug#1002976: installation-reports: Installer Fault Accessibility No Screen Reader Heard
On Sun, Jan 2, 2022, 03:59 Holger Wansing wrote: > Hi, > > Am 2. Januar 2022 02:40:16 MEZ schrieb "David J. Ring, Jr." >: > > > >lspci -knn: 00:03.0 Audio device [0403]: Intel Corporation Broadwell-U > Audio Controller [8086:160c] (rev 09) > > > As I already wrote: > my best guess for this one would be > https://www.debian.org/releases/stable/debian-installer/#errata > > > Holger > > > -- > Sent from /e/ OS on Fairphone3 > Holger, So is this fixed? Does the daily our weekly installer with firmware allow speech to be heard during installation? Thank you, David >
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 12:15 schrieb Matthias Andree: >> I am the owner of the domain so nobody is hijacked! > > Are you the owner of "mydomain.de" or of the unnamed domain you intended > not to show to the public? Do you want to help with this new certificate issue or discuss the ownership of domains? >> A self signing certificate is absolutely sufficient and perfect for private >> use. > > Then install your own CA or (if marked as CA-suitable) issuer > certificate it into your fetchmail client's OpenSSL trust store, or a > separate location, and move on. I want to do this - what must be done? >> The same TLS1.2 as before shall be used, so it is not understandable why >> addtional things are mandantory now? >> Why old certificates cannot be used any more when the client that uses a >> server is upgraded? > > It is not about certificates, but - as László pointed out - about > repairing fetchmail's security requirements from substandard to "Stand > der Technik". fetchmail 6.4.0 made --sslcertck the default, as various > places of the documentation (man page, NEWS file) point out. When this method is "state of the art", why it is not explained somewhere? With the search "install OpenSSL trust store" i could find this article: https://support.code42.com/CP/Admin/On-premises/6/Configuring/Use_OpenSSL_to_install_a_keystore that explains much of the stuff, but not how to use an self-signed certificate. > The standard use case for fetchmail is to fetch mail from "big sites" > and those can be expected to handle proper certification chains. I agree - but is a private mail-server something that must be eliminated? > Your use case is "run my own TLS server"; in that case fetchmail can > safely assume people are aware what they are doing and how to handle trust. This worked for more then 5 years with TLS1.2 without any problem. Why this must be a problem now? In the Internet are a mass of similar problems with fetchmail, but no description what exactly must be done to solve it. >>> Because "similar problems" are usually a broken setup of either >>> server-side certificates that don't trace back to commonly used and >>> trusted stores (Mozilla's trusted CA package, mostly), or local broken >>> setups. Take the example Mozilla and please explain why it works without an "OpenSSL trust store" ? >> This "stores" are a big problem of public monitoring, because every >> certificate causes requests to this central "stores". > > Untrue. Mozilla's certificates are installed for offline use by Debian, > Fedora, FreeBSD and derived distros under names such as ca-certificates, > ca_root_nss or similar. AFAICS and up to and including OpenSSL 3.0.0, > OpenSSL does not perform Online Certificate Status Protocol (OCSP) > polls, so no calling home involved to date. O.K. Then you have no request to this CA-servers for every connect to a server with a certificate, but every private server is registered there and every client will request the "trust" once to access the server. So you can made a profil who is using a server. That's the simple goal of it. > https://manpages.debian.org/buster/ca-certificates/update-ca-certificates.8.en.html > might be a starting point. Thanks - but now i still have no idea where to search for the trust store of fetschmail? Why it is not possible to give the needed commands like before, like openssl req -x509 -newkey rsa:4096 -keyout /etc/exim4/exim.key.pem -out /etc/exim4/exim.cert.pem -days 365 -nodes ? The reason is the lack of understanding what has changed and what must be done and not to bother you. >> But it would be helpful for others what must be done to create and install >> this new "client side certificate" that >> appears about 2018? > > That's standard TLS library procedure and not specific to fetchmail. The > only specific part is that fetchmail uses OpenSSL, so your self-signing > server certificate belongs into OpenSSL's trust store, or you can use > one or both of the --sslcert* options to fetchmail. When this is a standard procedure, why it is not possible to find existing examples how to handle it? Why it is still possible to fetch Data with TLS1.2 from the FTP-Server without similar problems? Thank you for your help - we are coming to an solution in little steps. Cheers karsten
Bug#1002991: qtsvg-opensource-src: CVE-2021-45930
Source: qtsvg-opensource-src Version: 5.15.2-3 Severity: important Tags: security upstream Forwarded: https://bugreports.qt.io/browse/QTBUG-96044 X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 5.11.3-2 Hi, The following vulnerability was published for qtsvg-opensource-src. CVE-2021-45930[0]: | Qt SVG in Qt 5.0.0 through 5.15.2 and 6.0.0 through 6.2.1 has an out- | of-bounds write in | QtPrivate::QCommonArrayOpsQPainterPath::Element::growAppend | (called from QPainterPath::addPath and QPathClipper::intersect). Note that for 5.12.y it was fixed with [6] in 5.12.12, but remains unfixed in 5.15.2. The corresponding QT bug does not seem public, still marking it as forwarded there. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-45930 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45930 [1] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37025 [2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37306 [3] https://github.com/google/oss-fuzz-vulns/blob/main/vulns/qt/OSV-2021-1121.yaml [4] https://github.com/qt/qtsvg/commit/36cfd9efb9b22b891adee9c48d30202289cfa620 (dev) [5] https://github.com/qt/qtsvg/commit/79bb9f51fa374106a612d17c9d98d35d807be670 (v6.2.2) [6] https://github.com/qt/qtsvg/commit/a3b753c2d077313fc9eb93af547051b956e383fc (v5.12.12) [7] https://bugreports.qt.io/browse/QTBUG-96044 Regards, Salvatore
Bug#926037: systemd: localectl console keymap configuration delayed
On 02.01.22 13:32, Floris Bos wrote: On 1/2/22 12:01 PM, Michael Biebl wrote: On 19.12.21 00:56, Floris Bos wrote: Yes, your Debian specific stuff in debian/patches/debian/Use-Debian-specific-config-files.patch only seems to set /etc/default/keyboard However with other Linux distributions the setting is also instantly applied to console, so that is what me and other users are expecting. With other Linux distributions this seems to be done by restarting the systemd-vconsole-setup unit in src/local/localed.c vconsole_reload() : https://github.com/systemd/systemd/blob/main/src/locale/localed.c#L97 Think that function needs to be patched by whatever is necessary to have the change do take effect on Debian (run "dpkg-reconfigure keyboard-configuration" and "setupcon -k --force" ?) Currently we disable vconsole via debian/rules, so there is no systemd-vconsole-setup.service. Maybe a fix could be as simple as shipping a symlink systemd-vconsole-setup.service → keyboard-setup.service ? Or do we need to restart console-setup.service as well? I recall in some cases it is also necessary to regenerate initramfs after a keyboard settings change. E.g. when LUKS encryption is used and the user needs to be able to enter the password to unlock the disks in the console prior to the rest of the system being booted. So just restarting one of the services actually may not be enough. Well, I'm not yet convinced that doing this in localed is the correct place. After all, if you run dpkg-reconfigure console-setup, it doesn't update the initramfs either, or does it? OpenPGP_signature Description: OpenPGP digital signature
Bug#967275: Bug#967582: libgtkdatabox: depends on deprecated GTK 2
Control: tags -1 + pending fixed-in-experimental Control: block 967275 by -1 Control: severity 967275 important Control: block 967831 by -1 Control: severity 967831 important Hi Felipe On Sun, 6 Jun 2021 at 23:42, Felipe Castro wrote: > Hi, I'm the new upstream maintainer of GtkDatabox and we have released > version 1.0.0 this year, which depends now on GTK3, please update it on > Debian. > The packages which depend on it are klavaro, xoscope and brp-pacu. > From those, the only upstream which still depends on old gtkdatabox is > brp-pacu, but there is a fork which has done the upgrade to use the new GTK3 > version at GitHub, see: https://github.com/matthew-dews/brp-pacu > The problem is that they have not released this new version yet, but I could > provide another fork and release, if that is the case. Thanks for your work on these packages! I've uploaded libtgkdatabox 1.0.0 to experimental. Once it clears NEW [1], I will prepare uploads of xoscope and brp-pacu which I have already tested. klavaro seems to be using an embedded copy of libgtkdatabox. Regards Graham [1] https://ftp-master.debian.org/new.html
Bug#990524: rabbitmq-server: CVE-2021-32719 CVE-2021-32718
Source: rabbitmq-server Source-Version: 3.9.4-1 On Thu, Jul 01, 2021 at 01:22:12PM +0200, Moritz Mühlenhoff wrote: > Source: rabbitmq-server > X-Debbugs-CC: t...@security.debian.org > Severity: important > Tags: security > > Hi, > > The following vulnerabilities were published for rabbitmq-server. > > CVE-2021-32719[0]: > | RabbitMQ is a multi-protocol messaging broker. In rabbitmq-server > | prior to version 3.8.18, when a federation link was displayed in the > | RabbitMQ management UI via the `rabbitmq_federation_management` > | plugin, its consumer tag was rendered without proper script > | tag sanitization. This potentially allows for JavaScript code > | execution in the context of the page. The user must be signed in and > | have elevated permissions (manage federation upstreams and policies) > | for this to occur. The vulnerability is patched in RabbitMQ 3.8.18. As > | a workaround, disable the `rabbitmq_federation_management` plugin and > | use [CLI tools](https://www.rabbitmq.com/cli.html) instead. > > https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-5452-hxj4-773x > https://github.com/rabbitmq/rabbitmq-server/pull/3122 > > CVE-2021-32718[1]: > | RabbitMQ is a multi-protocol messaging broker. In rabbitmq-server > | prior to version 3.8.17, a new user being added via management UI > | could lead to the user's bane being rendered in a confirmation message > | without proper `script` tag sanitization, potentially allowing > | for JavaScript code execution in the context of the page. In order for > | this to occur, the user must be signed in and have elevated > | permissions (other user management). The vulnerability is patched in > | RabbitMQ 3.8.17. As a workaround, disable `rabbitmq_management` plugin > | and use CLI tools for management operations and Prometheus and Grafana > | for metrics and monitoring. > > https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-c3hj-rg5h-2772 > https://github.com/rabbitmq/rabbitmq-server/pull/3028 > > If you fix the vulnerabilities please also make sure to include the > CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2021-32719 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32719 > [1] https://security-tracker.debian.org/tracker/CVE-2021-32718 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32718 > > Please adjust the affected versions in the BTS as needed. Those were fixed for unstable with the 3.9.4-1 upload. Regards, Salvatore
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 12:28 schrieb Matthias Andree: > But it would be helpful for others what must be done to create and install > this new "client side certificate" that appears about 2018? >>> I think the certificate issue was there right from the beginning. >> Definitely no. Mails where fetched for about 5 years without any problem. > Untrue. Messages were fetched without proper protection from > MITM/eavesdropping attacks, unless you were using *other* options to > ensure authenticity of the server. Which I doubt, else you would have > asked specific questions about fetchmail options. That's true - but you change the privacy with an voluntary registration at an CA-authority. The people that can make MITM/eavesdropping attacks can fake an CA-authority too. Do you think it is possible to make thousands of MITM/eavesdropping attacks parallel for every private server? Can you please recommend *other* options to ensure more security with self signed certificates? >> >> I'm caring about safety and privacy, that's the reason encryption with >> private certificates are used. > Nonsense. That's the reason why fetchmail 6.4.0 finally broke > compatibility with broken sites and finally (far too late) enforces > proper X.509 certificate chains to so-called trust anchors. Can you explain this a little bit more please? Using encryption with an self-signed certificate cannot be more nonsense then to use no encryption at all. This makes no sense for me from a logic point. >>> In this case the original private certificate from the server is needed? >>> >>> Why a client must have additional files now to access an server > > No. That's the wrong question to ask. Do not ask "why they are needed > now", but "why have older fetchmail versions made proper trust > verification optional" for so many years. Why have older fetchmail versions made proper trust verification optional? :-) > And another question to ask is "why do users ignore manuals and NEWS > files of the applications they use" That's a really good question. When I think about it, the honest answer is probably laziness and to some extent disinterest. You set up a server at a certain point in time and as soon as it is running smoothly, you don't change anything about it - true to the motto "don't touch a running system". To the best of the knowledge and understanding, you have installed encrypted communication and hope that this is both sufficient and maintained through security updates. > And a third one, to third parties and outside of this bug's context "how > do we get proper yet concise certificate trust management documentation > in prominent places?". This is a very good question too! The most important problem is that this encryption stuff is very complicate to avoid to say "to complicate". You have to have the affinity to want to understand it, to really see through the details. > > One half is really OpenSSL basic usage and how to maintain its trust > store, and one half is, sorry to be so blunt, a half-baked approach at > trying to be your own CA without knowing what you are doing. That's correct. It is an unsuccessful attempt to bridge the gap between encryption in use and complete understanding of it. > Fetchmail's expectation is that the server-presented single self-signed > certificate, or normally certificate chain, traces back to a root > signing certificate that is "trusted" and is installed in your local > computer's OpenSSL trust store (the one running fetchmail), and trusted > in a way that it properly verifies the sub-CAs it authenticates with > respect to the policies and practices they implement. But this is all > OpenSSL trust handling and, again, not specific to fetchmail. Thank you for this explanation - that helps me to follow you. Cheers karsten
Bug#1002956: bullseye-pu: package rabbitmq-server/3.8.9-3 CVE-2021-32718, CVE-2021-32719
Hi Thomas,
On Sat, Jan 01, 2022 at 06:57:42PM +0100, Thomas Goirand wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
>
> [ Reason ]
> Hi,
>
> I'd like to update rabbitmq-server to address:
> https://bugs.debian.org/990524
>
> That's CVE-2021-32718, CVE-2021-32719.
Can you please include the fix as well for CVE-2021-22116?
>
> [ Impact ]
> XSS security bugs.
>
> [ Risks ]
> The patch only impacts some plugins which aren't activated
> by default, so most user aren't even impacted. However, the
> patches are also super-small, so why not approved them?
>
> [ 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
> [x] the issue is verified as fixed in unstable
>
> Cheers,
>
> Thomas Goirand (zigo)
> diff -Nru rabbitmq-server-3.8.9/debian/changelog
> rabbitmq-server-3.8.9/debian/changelog
> --- rabbitmq-server-3.8.9/debian/changelog2021-04-10 22:59:57.0
> +0200
> +++ rabbitmq-server-3.8.9/debian/changelog2022-01-01 18:46:04.0
> +0100
> @@ -1,3 +1,23 @@
> +rabbitmq-server (3.8.9-3+deb11u1) bullseye; urgency=medium
> +
> + * CVE-2021-32719: In rabbitmq-server prior to version 3.8.18, when a
> +federation link was displayed in the RabbitMQ management UI via the
> +`rabbitmq_federation_management` plugin, its consumer tag was rendered
> +without proper script tag sanitization. This potentially allows
> +for JavaScript code execution in the context of the page. The user must
> +be signed in and have elevated permissions (manage federation upstreams
> +and policies) for this to occur. Applied upstream patch: Escape the
> +consumer-tag value in federation mgmt.
> + * CVE-2021-32718: In rabbitmq-server prior to version 3.8.17, a new user
> +being added via management UI could lead to the user's bane being
> +rendered in a confirmation message without proper `script` tag
> +sanitization, potentially allowing for JavaScript code execution in the
> +context of the page. In order for this to occur, the user must be signed
> +in and have elevated permissions (other user management).
> + * Closes: #990524
> +
> + -- Thomas Goirand Sat, 01 Jan 2022 18:46:04 +0100
> +
> rabbitmq-server (3.8.9-3) unstable; urgency=medium
>
>[ Adam Cecile ]
> diff -Nru
> rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
>
> rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
> ---
> rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
> 1970-01-01 01:00:00.0 +0100
> +++
> rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
> 2022-01-01 18:46:04.0 +0100
> @@ -0,0 +1,21 @@
> +Description: CVE-2021-32718: Escape username before displaying it
> + All other values displayed in pop-ups are already escaped.
> +Author: Michael Klishin
> +Date: Thu, 6 May 2021 06:57:43 +0300
> +Origin: upstream,
> https://github.com/rabbitmq/rabbitmq-server/commit/5d15ffc5ebfd9818fae488fc05d1f120ab02703c.patch
> +Bug-Debian: https://bugs.debian.org/990524
> +Last-Update: 2022-01-01
> +
> +diff --git a/deps/rabbitmq_management/priv/www/js/dispatcher.js
> b/deps/rabbitmq_management/priv/www/js/dispatcher.js
> +index d2842c2da8a..5f1b54dbac8 100644
> +--- a/deps/rabbitmq_management/priv/www/js/dispatcher.js
> b/deps/rabbitmq_management/priv/www/js/dispatcher.js
> +@@ -189,7 +189,7 @@ dispatcher_add(function(sammy) {
> + res = sync_put(this, '/users/:username');
> + if (res) {
> + if (res.http_status === 204) {
> +-username = res.req_params.username;
> ++username = fmt_escape_html(res.req_params.username);
> + show_popup('warn', "Updated an existing user: '" +
> username + "'");
> + }
> + update();
> diff -Nru
> rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
>
> rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
> ---
> rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
> 1970-01-01 01:00:00.0 +0100
> +++
> rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
> 2022-01-01 18:46:04.0 +0100
> @@ -0,0 +1,21 @@
> +Description: CVE-2021-32719 Escape the consumer-tag value in federation mgmt
> + Patches persistent XSS.
> +Author: Patrik Ragnarsson
> +Date: Sat, 19 Jun 2021 09:23:12 +0200
> +Origin: upstream, https://github.com/rabbitmq/rabbitmq-server/pull/3122
> +Bug-Debian:
Bug#1002961: [Pkg-pascal-devel] Bug#1002961: src:castle-game-engine: fails to migrate to testing for too long: FTBFS on armel
The issue is that there seem to be a bug in the compiler. However, I'm not able to understand what kind of issue and cloud not produce a small code that triggers it. Moreover, it seems that the bug itself is triggered only when running the full battery of tests. Then the failing test starts to fail. If the test is ran alone (after a machine reboot, or after a while) then it will succeed, but it one runs it after running the full test suite then it will fail systematically. No clue how to go forward and no enough information to open an upstream compiler bug. Moreover CGE upstream think we should abandon armel (and other non widely used architectures) as a target for CGE, but I think myself it is a good test for the compiler and tend to think we should keep it. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#978040: [Pkg-pascal-devel] Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi Paul,
On Sun, 2022-01-02 at 08:19 +0100, Paul Gevers wrote:
> Hi,
>
> On 29-12-2021 23:47, Abou Al Montacir wrote:
> > So it should work correctly on all targets.
>
> Does this work correctly on all multiarch architectures too? I inspected
> only my own installation and there it only has cpui386 and cpux86_64.
If you check on a porter box for ARM or power PC, you will find only arm or ppc
related ifdefs.
So it works for all architectures, but not multiarch.
If we can safely suppose that all Debian architectures are using the very same
GCC version and path, then we can remove the ifdef and have a generic path that
works for mutiarch with a minimal effort.
>
> > However, it is true that if a new gcc version is installed after FPC
> > then the logic will fall down.
>
> Can't we use a wildcard for the version number? I mean, after 11 comes
> 12 and 13 and ...
The wildcards work but only for one directory level. This means /path/to/* and
/path/to/prefix* will work, but not /path/to/*/* or /path/to/prefix*/*
>
> > If this is judged OK, I propose to close this ticket
>
> As long as we have a new fpc in every Debian release, we're fine in
> Debian, but e.g. Ubuntu users may experience issues when they carry the
> same fpc over to a new version of Ubuntu that comes with a new gcc
> version. So I don't think it's nice.
If we can add a trigger then we can run dpkg-reconfigure fp-compiler-${VERSION}
and get it updated.
--
Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
Bug#1002992: sub...@bugs.debian.org
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wxsvg": * Package name: wxsvg Version : 2:1.5.23+dfsg-1 Upstream Author : Alex Thuering * URL : http://wxsvg.sourceforge.net/ * License : wxWindows * Vcs : https://salsa.debian.org/multimedia-team/wxsvg Section : libs It builds those binary packages: libwxsvg3 - SVG library for the wxWidgets toolkit libwxsvg-tools - SVG library for the wxWidgets toolkit (tools) libwxsvg-dev - Development files for wxSVG This is a minor update triggered by a new upstream version. More info: https://mentors.debian.net/package/wxsvg/ or using dget -x https://mentors.debian.net/debian/pool/main/w/wxsvg/wxsvg_1.5.23+dfsg-1.dsc Changes since the last upload: wxsvg (2:1.5.23+dfsg-1) unstable; urgency=medium . * New upstream version * d/watch: dfsg.1 -> dfsg (lintian warning) * d/control: Allow builds against wxWidgets 3.1 * d/control: Standards-version: 4.5.0 -> 4.6.0, no changes. * Add patch for separate -latomic library causing sh4 build errors.
Bug#1002732: needrestart stalled in background when performing update with KDE Discover
So, I actually just installed my regular updates today with Discover and noticed a few library changes. The update completed properly. If I run needrestart after (or do an apt install), it confirms it wants to restart some libraries. I can continue to install other packages with Discover as well. So it looks like that package was all I needed. Thanks, Ryan On Saturday, January 1, 2022 8:42:26 A.M. EST Thomas Liske wrote: > Hi, > > could you check running needrestart as root on cli if you have any > pending restarts? > > You might try to reinstall a lib to trigger needrestart (i.e. via apt- > get install --reinstall libnss3 - this *should* not break anything) to > force to get a pending restarts. > > Please check if needrestart and debconf-kde-helper are working when > using KDE Discover afterwards. > > > Regards, > Thomas > > On Fri, 2021-12-31 at 10:10 -0500, Ryan Armstrong wrote: > > I did not, but your message prompted me to go looking a bit. I found > > I had > > not installed debconf-kde-helper. I would have expected a package > > like this to > > get pulled in when I installed KDE, so I expect it is missing as a > > dependency > > (for plasma-discover perhaps?) > > > > In my setup, KDE was installed onto an existing setup by running `apt > > install > > kde-plasma-desktop` > > > > I did one update after installing the helper, but didn't notice > > anything (it > > didn't stall, though). As long as that fixes the problem, I guess > > this bug > > should be redirected as a dependency issue? > > > > Ryan > > > > On Friday, December 31, 2021 9:54:02 A.M. EST you wrote: > > > Hi Ryan, > > > > > > needrestart should not block if it is run non-interactive. On > > > Debian it > > > uses the debconf frontend which also has graphical frontends. Do > > > you > > > get debconf dialogs in KDE Discover when installing/updating > > > packages > > > at all? (Sorry I do not have an KDE environment for testing.) > > > > > > > > > Regards, > > > Thomas > > > > > > On Tue, 2021-12-28 at 08:33 -0500, Ryan Armstrong wrote: > > > > Package: needrestart > > > > Version: 3.5-5 > > > > Severity: normal > > > > > > > > Dear Maintainer, > > > > > > > > When I performed an update with KDE Discover, I noticed it > > > > stalled at > > > > 99% complete status and would not finish. When I checked the > > > > process > > > > tree with htop, I noticed the following lines from packagekitd > > > > and > > > > needrestart: > > > > > > > >2629 root 20 0 492M 124M 79624 S 0.0 0.8 0:29.20 > > > > ├─ > > > > /usr/libexec/packagekitd > > > >2632 root 20 0 492M 124M 79624 S 0.0 0.8 0:00.00 > > > > │ > > > > ├─ /usr/libexec/packagekitd > > > >2634 root 20 0 492M 124M 79624 S 0.0 0.8 0:00.05 > > > > │ > > > > ├─ /usr/libexec/packagekitd > > > > 14075 root 20 0 492M 124M 79624 S 0.0 0.8 0:05.78 > > > > │ > > > > ├─ /usr/libexec/packagekitd > > > > 14090 root 20 0 494M 99648 50800 S 0.0 0.6 0:00.24 > > > > │ > > > > └─ /usr/libexec/packagekitd > > > > 25864 root 20 0 494M 51924 2336 S 0.0 0.3 0:00.00 > > > > │ └─ /usr/libexec/packagekitd > > > > 25872 root 20 0 2472 704 616 S 0.0 0.0 0:00.00 > > > > │└─ sh -c test -x /usr/lib/needrestart/apt-pinvoke && > > > > /usr/lib/needrestart/apt-pinvoke || true > > > > 25873 root 20 0 35864 27816 6140 S 0.0 0.2 0:00.64 > > > > │ └─ /usr/bin/perl /usr/sbin/needrestart > > > > > > > > It appears that packagekit is still running needrestart to ask if > > > > I > > > > want to restart systemd services. However, this prompt is > > > > obviously > > > > not > > > > visible to me through KDE Discover, so it's stuck waiting > > > > forever. > > > > > > > > If I use kill on needrestart, the Discover session completes. > > > > > > > > Since, this is an interaction between Discover, packagekit, apt > > > > and > > > > needrestart (possibly others?), I'm not 100% sure this is the > > > > right > > > > place for it. Feel free to reassign if I got it wrong. > > > > > > > > Ryan > > > > > > > > -- Package-specific info: > > > > needrestart output: > > > > Your outdated processes: > > > > akonadi_archive[3076], akonadi_mailfil[3102], > > > > akonadi_sendlat[3116], > > > > akonadi_unified[3117], blueman-applet[2663], Discord[2921, 2924, > > > > 2967, 2922, 2958, 2917, 3276, 3044], DiscoverNotifie[2571], > > > > evolution-addre[2767], evolution-alarm[2660], evolution- > > > > calen[2742], > > > > evolution-sourc[2698], goa-daemon[2704], kmail[2936], > > > > kwin_x11[2488], > > > > nextcloud[2656], plasmashell[2554], QtWebEngineProc[6196, 6215, > > > > 6194, > > > > 6193], tracker-miner-f[2674], xdg-desktop-por[2375], xdg- > > > > document- > > > > po[2392], xdg-permission-[2397] > > > > > > > > > > > > > > > > -- System Information: > > > > Debian Release: bookworm/sid > > > > APT prefers testing > > > > APT policy: (900, 'testing'), (300,
Bug#926037: systemd: localectl console keymap configuration delayed
On 1/2/22 2:10 PM, Michael Biebl wrote: On 02.01.22 13:32, Floris Bos wrote: I recall in some cases it is also necessary to regenerate initramfs after a keyboard settings change. E.g. when LUKS encryption is used and the user needs to be able to enter the password to unlock the disks in the console prior to the rest of the system being booted. So just restarting one of the services actually may not be enough. Well, I'm not yet convinced that doing this in localed is the correct place. After all, if you run dpkg-reconfigure console-setup, it doesn't update the initramfs either, or does it? It does on my Ubuntu box. Not certain about upstream Debian. -- Yours sincerely, Floris Bos
Bug#1002993: systemd: Setting access ACL: invalid argument (Upgrade to 247.3-6 from buster to bullseye in container)
Package: systemd Version: 247.3-6 Severity: normal Dear Maintainer, In a systemd-nspawn container, upgrading from Debian 10 to Debian 11 fails with: Setting up systemd (247.3-6) ... Setting access ACL "u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" on /var/log/journal failed: Invalid argument Setting access ACL "u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" on /var/log/journal/0168a64537e84260bcb1172567dbc16e failed: Invalid argument Setting access ACL "u::rw-,g::r-x,g:adm:r--,g:4294967295:r-x,m::r--,o::---" on /var/log/journal/0168a64537e84260bcb1172567dbc16e/system.journal failed: Invalid argument dpkg: error processing package systemd (--configure): installed systemd package post-installation script subprocess returned error exit status 73 The Version before was: 241-7~deb10u8 Please let me know if there are additional details I could supply. -- tobi
Bug#712979: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"
On 01.01.22 22:05, Don Armstrong wrote: I'm currently working on it, but my available time is so minimal, that additional help would be welcome. Awesome news! Is there some repository to check out? I'd love to help if I can. My current plan is to reimplement the log and database reading pieces in python (SQLAlchemy + FastAPI) so that the number of people who can contribute to the web frontend parts is significantly larger. [I've started in on this, but it's slow going.] Cheers, Bastian -- Dr. Bastian Venthur https://venthur.de Debian Developer venthur at debian org
Bug#1000887: Info received ([Bug#1000887] xorg: X server segfaults when using xpdf)
Some more information: * A colleague who owns a more modern Radeon GPU than mine (using the radeonsi drivers) doesn't have the same problem. * If I start the X server with color depth 16 the problem goes away, but occurs with both 24 and 32 color depths. >From these observations, I conclude that the problem lies in the full-color handling of the standard radeon driver.
Bug#974217: RFS: python-radexreader/1.2.1-1 [ITP] -- Reader for the RADEX RD1212 Geiger counter
I found, this is easy: in radexreader.manpages: debian/radexreader.1 debian/radexreader.fr.1 so I didn't say anything
Bug#1002994: expat: CVE-2021-45960: A large number of prefixed XML attributes on a single tag can crash libexpat (troublesome left shifts by >=29 bits in function storeAtts)
Source: expat Version: 2.4.2-1 Severity: important Tags: security upstream Forwarded: https://github.com/libexpat/libexpat/issues/531 X-Debbugs-Cc: car...@debian.org, Debian Security Team Control: found -1 2.2.10-2 Control: found -1 2.2.6-2+deb10u1 Control: found -1 2.2.6-2 Hi, The following vulnerability was published for expat. CVE-2021-45960[0]: | In Expat (aka libexpat) before 2.4.3, a left shift by 29 (or more) | places in the storeAtts function in xmlparse.c can lead to realloc | misbehavior (e.g., allocating too few bytes, or only freeing memory). If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-45960 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45960 [1] https://github.com/libexpat/libexpat/issues/531 Regards, Salvatore
Bug#1002993: systemd: Setting access ACL: invalid argument (Upgrade to 247.3-6 from buster to bullseye in container)
Some more debugging into it: Adding a set -x to postinst: + [ configure = triggered ] + [ -z 241-7~deb10u8 ] + dpkg --compare-versions 241-7~deb10u8 lt 245.4-4~ + systemctl enable systemd-pstore.service + [ -z 241-7~deb10u8 ] + [ -z 241-7~deb10u8 ] + [ -z 241-7~deb10u8 ] + systemd-machine-id-setup + addgroup --quiet --system systemd-journal + adduser --quiet --system --group --no-create-home --home /run/systemd --gecos systemd Network Management systemd-network + adduser --quiet --system --group --no-create-home --home /run/systemd --gecos systemd Resolver systemd-resolve + dpkg --compare-versions 241-7~deb10u8 lt 244.1-2~ + mkdir -p /var/log/journal + mountpoint -q /proc + systemd-tmpfiles --create --prefix /var/log/journal Setting access ACL "u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" on /var/log/journal failed: Invalid argument Setting access ACL "u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" on /var/log/journal/0168a64537e84260bcb1172567dbc16e failed: Invalid argument Setting access ACL "u::rw-,g::r-x,g:adm:r--,g:4294967295:r-x,m::r--,o::---" on /var/log/journal/0168a64537e84260bcb1172567dbc16e/system.journal failed: Invalid argument /proc is mounted in my container. (I've made locally "systemd-tmpfiles --create --prefix /var/log/journal" a NOP to be able to proceed with the update. For the ones finding this bug report, the file to edit: /var/lib/dpkg/info/systemd.postinst) -- tobi
Bug#997748: libcomps: FTBFS: There is a syntax error in your configuration file: Missing parentheses in call to 'print'. Did you mean print(os.environ['LD_LIBRARY_PATH'])? (conf.py, line 23)
hi, On Sun, Oct 24, 2021 at 01:39:00PM +0200, Lucas Nussbaum wrote: > Source: libcomps > Version: 0.1.15-4 > Severity: serious [...] > During a rebuild of all packages in sid, your package failed to build > on amd64. [...] > > Running Sphinx v4.2.0 > > > > Configuration error: > > There is a syntax error in your configuration file: Missing parentheses in > > call to 'print'. Did you mean print(os.environ['LD_LIBRARY_PATH'])? > > (conf.py, line 23) > > > > make[5]: *** [src/python/docs/CMakeFiles/pydocs.dir/build.make:122: pydocs] > > Error 2 It seems to me we can fix this bug by simply taking the patch from https://github.com/rpm-software-management/libcomps/commit/5eebd94a7ce855979eb014595256eee17ee6b359 Can someone confirm? I'd be happy to sponsor an upload again :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Dance like no one's watching. Encrypt like everyone is. signature.asc Description: PGP signature
Bug#1002995: ruby3.0: CVE-2021-41816 CVE-2021-41817 CVE-2021-41819
Source: ruby3.0 Version: 3.0.2-5 Severity: grave Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerabilities were published for ruby3.0, they were fixed upstream in 3.0.3. CVE-2021-41816[0]: | Buffer Overrun in CGI.escape_html CVE-2021-41817[1]: | Date.parse in the date gem through 3.2.0 for Ruby allows ReDoS | (regular expression Denial of Service) via a long string. The fixed | versions are 3.2.1, 3.1.2, 3.0.2, and 2.0.1. CVE-2021-41819[2]: | CGI::Cookie.parse in Ruby through 2.6.8 mishandles security prefixes | in cookie names. This also affects the CGI gem through 0.3.0 for Ruby. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-41816 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41816 [1] https://security-tracker.debian.org/tracker/CVE-2021-41817 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41817 [2] https://security-tracker.debian.org/tracker/CVE-2021-41819 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41819 Regards, Salvatore
Bug#1002219: [PATCH] t/eml.t: ignore newer Email::MIME behavior
Hello Eric,
On 12/30/21 20:17, Eric Wong wrote:
Uwe Kleine-König wrote:
Hello,
adding the Debian Perl Group to Cc, maybe they can help here.
(for context look at https://bugs.debian.org/1002219)
On 12/30/21 10:12, Uwe Kleine-König wrote:
I got a bug report against the public-inbox 1.6.1 package about a
failing test, see below for the whole output. I didn't have time yet to
look into it, so this is just a heads up to make you aware. If someone
has a hint what to do, this would be greatly appreciated. Maybe just
updating to 1.7 will help?
Best regards
Uwe
On 12/21/21 17:34, Lucas Nussbaum wrote:
# Failed test 'filename decoded'
# at t/eml.t line 407.
# got: '=?utf-8?q?vtpm-makefile.patch?='
# expected: 'vtpm-makefile.patch'
# Looks like you failed 1 test of 146.
t/eml.t ..
I can reproduce this problem with 1.6.1 checked out. I played a bit around
(suffering from my weak perl foo) and found that when I downgrade
libemail-mime-perl from 1.952-1 (i.e. Debian unstable's version) to 1.949-1
(i.e. Debian stable's version), this works.
The reproducer is:
$ perl -e 'use Email::MIME; print Email::MIME->new("Content-Type:
text/x-patch; name=\"=?utf-8?q?vtpm-fakefile.patch?=\"\nContent-Disposition:
attachment; filename=\"=?utf-8?q?vtpm-makefile.patch?=\"\n\n")->filename;'
which emits "vtpm-makefile.patch" with 1.949-1 (as public-inbox expects),.
but =?utf-8?q?vtpm-makefile.patch?= with 1.952-1.
So the key question is: Is the test correct and his is a regression in
libemail-mime-perl, or is the test wrong and we need to fix the test (and
PublicInbox::Eml)?
I thought I sent a fix to this; but I nuked the root FS on one of
my workstations on accident :< Still recovering...
Oh, good luck in restoring your precious data.
Thanks for your patch. I just uploaded public-inbox with this change to
fix the bug.
I still wonder if this is a regression in Email::MIME, or just a wrong
expectation. In the first case I'd open a bug against libemail-mime-perl.
Bisecting in https://github.com/rjbs/Email-MIME.git yields
https://github.com/rjbs/Email-MIME/commit/8a7cffd2b1091ff1a750d541a85e1813a6747b72
as breaking commit. So this looks like an intended change.
Best regards
Uwe
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1002404: borgbackup: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13
control: close -1 control: severity -1 normal Hello Lucas, I tried on reproducible builds, and I saw some failures some time ago, but I retried today and everything was good. So I presume something in the build-deps got fixed in the meanwhile? e.g. https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/borgbackup_1.1.17-1.rbuild.log.gz G. On Wed, 22 Dec 2021 08:50:10 +0100 Lucas Nussbaum wrote: > Source: borgbackup > Version: 1.1.17-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20211220 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > python3 setup.py build_ext --inplace > > Detected and preferring liblz4 over bundled LZ4 > > Detected and preferring libb2 over bundled BLAKE2 > > Detected and preferring libzstd over bundled ZSTD > > Detected and preferring libxxhash over bundled XXHASH > > running build_ext > > skipping 'src/borg/algorithms/msgpack/_packer.cpp' Cython extension > > (up-to-date) > > skipping 'src/borg/algorithms/msgpack/_unpacker.cpp' Cython extension > > (up-to-date) > > skipping 'src/borg/compress.c' Cython extension (up-to-date) > > skipping 'src/borg/crypto/low_level.c' Cython extension (up-to-date) > > skipping 'src/borg/hashindex.c' Cython extension (up-to-date) > > skipping 'src/borg/item.c' Cython extension (up-to-date) > > skipping 'src/borg/chunker.c' Cython extension (up-to-date) > > skipping 'src/borg/algorithms/checksums.c' Cython extension (up-to-date) > > skipping 'src/borg/platform/posix.c' Cython extension (up-to-date) > > skipping 'src/borg/platform/linux.c' Cython extension (up-to-date) > > skipping 'src/borg/platform/syncfilerange.c' Cython extension (up-to-date) > > building 'borg.algorithms.msgpack._packer' extension > > x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g > > -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat > > -Werror=format-security -g -fwrapv -O2 -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC > > -D__LITTLE_ENDIAN__=1 -I/usr/include -I/usr/include -I/usr/include > > -I/usr/include -I/usr/include -I/usr/include -I/usr/include/python3.9 -c > > src/borg/algorithms/msgpack/_packer.cpp -o > > build/temp.linux-x86_64-3.9/src/borg/algorithms/msgpack/_packer.o > > x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g > > -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > > build/temp.linux-x86_64-3.9/src/borg/algorithms/msgpack/_packer.o -o > > /<>/src/borg/algorithms/msgpack/_packer.cpython-39-x86_64-linux-gnu.so > > building 'borg.algorithms.msgpack._unpacker' extension > > x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g > > -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat > > -Werror=format-security -g -fwrapv -O2 -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC > > -D__LITTLE_ENDIAN__=1 -I/usr/include -I/usr/include -I/usr/include > > -I/usr/include -I/usr/include -I/usr/include -I/usr/include/python3.9 -c > > src/borg/algorithms/msgpack/_unpacker.cpp -o > > build/temp.linux-x86_64-3.9/src/borg/algorithms/msgpack/_unpacker.o > > x86_64-linux-gnu-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g > > -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > > build/temp.linux-x86_64-3.9/src/borg/algorithms/msgpack/_unpacker.o -o > > /<>/src/borg/algorithms/msgpack/_unpacker.cpython-39-x86_64-linux-gnu.so > > building 'borg.compress' extension > > x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g > > -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat > > -Werror=format-security -g -fwrapv -O2 -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC > > -DBORG_USE_LIBLZ4=YES -DBORG_USE_LIBB2=YES -DBORG_USE_LIBZSTD=YES > > -DBORG_USE_LIBXXHASH=YES -DXXH_PRIVATE_API=YES -I/usr/include > > -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include > > -I/usr/include/python3.9 -c src/borg/compress.c -o > > build/temp.linux-x86_64-3.9/src/borg/compress.o > > x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -g > > -fwrapv -O2 -Wl,-z,relro -Wl,-z,now -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 > > build/temp.linux-x86_64-3.9/src/borg/compress.o -llz4 -lzstd -o > >
Bug#1003010: fonts-liberation2: please Provides fonts-liberation
Package: fonts-liberation2 Version: 2.1.5-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 It would be desirable for fonts-liberation2 to Provides fonts-liberation so as to avoid installing two versions of essentially the same font. - -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /bin/dash Init: unable to detect -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmHR8oMACgkQrh+Cd8S0 17Z7+RAAp5YKO9j36vycnMIvKSJP16hMis0Ua8kRKPbQD5yxHZ2esxA924Po5Owr DJPfBbHwiMBnZb4FQjDaHYBg+U7HN2ZWZuDJLFPszQr8p9eR+8GA3Wo2WxDTP9Es YsYia92X2Ay+T4Dq+OhEIQLdL7Dd72s8+BFpDqDWaZ+EAPNgsXFQneKpdCNS3y5w edw8ToH8xaDUnYILjBN7sD1f80RnA2oa6PbauVU+3CS41lsQ4vDZbFyR7Nedtl6n +C+HLmxwDHjd2SrvjCjBKkY7IZWMIzvt0fJb7LAoQ39w7+kqeCeTcbb28T+wjyFB hgPk30LStOgYCB9dQfhajrwt/rL+4/6ICy82BD7TRMOAhyiO8Z9zNViv151aPuMT 6BWSZAM1bjWBdAxDqWgaif9ByZnm7ba/n4NGTOyeQ2MX43HIn21DR1lNypLKsB6J t1q21TdeZNSmVJR02EtUZ6MhgXtCMJZoubb1uMkpQkeNuBv828mI0iqkCwMAnjfx Z2yYXDcaL7swtgBifGMtx4gtLJO54bFZ/7391f/AX7V1F07zFy0yiM1P7FY5jAkB xQ+wHVqGRIeSe0g9j40vQMH9u2T7GkgMCZDcraAiPTREZxUMpSc34o+DgnqOhAfZ 6U9cUH7iMvUfVyID/X3FQASnwjXrV2ALRRG+3tZmuIaTU4GnXKo= =k7Xm -END PGP SIGNATURE-
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, 2 Jan 2022 20:15:01 +0100 Moritz Muehlenhoff wrote: > On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: > > How should I handle this? NMU to sid, let people try it out, and > > then deal with buster/bullseye? > > Yeah, let's proceed with unstable first in any case. > > > Upload everything all at once? I'm also > > going to try building for buster, unless the security team doesn't > > think I should bother. > > I saw > https://salsa.debian.org/dilinger/chromium/-/commit/5c05f430e192961527ec9a64bbaa64401dc14d95 > , but buster now also includes LLVM/clang 11 (it was introduced to > support a more recent Rust toolchain needed for Firefox), so you > might be reduce complexity here further: > https://tracker.debian.org/pkg/llvm-toolchain-11 > > It's in buster-proposed-updates since there hasn't been a point > release since, but for the purposes of buster-security builds, it > doesn't matter (they chroots have been modified to includen > buster-proposed-updates temporarily): Ah, very helpful, thanks! I'll give buster a try (just created the 'v96-buster' branch). Between that and various backports, I think we might be in good shape.
Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere
this is addressed in more detail at https://github.com/dankamongmen/notcurses/issues/2519. i expect to have this fixed within the hour. sorry for the annoyance.
Bug#1003036: ITP: golang-github-fatih-camelcase -- Split a camelcase word into a slice of words in Go
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org Package: wnpp Severity: wishlist Owner: "Mason Giles" * Package name : golang-github-fatih-camelcase Version : 1.0.0-1 Upstream Author : Fatih Arslan * URL : https://github.com/fatih/camelcase * License : Expat Programming Lang: Go Description : Split a camelcase word into a slice of words in Go CamelCase is a Go package to split the words of a camelcase type string into a slice of words. It can be used to convert a camelcase word (lower or upper case) into any type of word. As with all Go packages, it should be team-maintained within the Debian Go Packaging Team. This package is part of the dependency tree of an attempt to package LiteIDE: - liteide - gocode - gotools - golang-github-visualfc-fastmod - golang-github-visualfc-goversion - gomodifytags - golang-github-fatih-camelcase (*) - golang-github-fatih-structtag
Bug#1003002: autopkgtest-virt-qemu: Console setup issue on armhf
Package: autopkgtest Version: 5.19 Severity: normal It looks as if one of the necessary consoles is not set up properly on armhf (it worked fine for me on arm64): $ sudo autopkgtest-build-qemu \ --architecture armhf \ --mirror http://deb.debian.org/debian \ unstable armhf.img ... $ autopkgtest libocas -- qemu \ --dpkg-architecture armhf \ -d --show-boot \ armhf.img produces | host login: autopkgtest-virt-qemu: DBG: expect: found "'login prompt on serial console'" | autopkgtest-virt-qemu: DBG: expect: b'ok' | autopkgtest-virt-qemu: DBG: setup_shell(): no default shell on hvc1 or ttyS1 | qemu-system-arm: terminating on signal 15 from pid 1316826 (/usr/bin/python3) | autopkgtest-virt-qemu: DBG: cleanup... | : failure: The VM does not start a root shell on ttyS1 or hvc1 already. The only other supported login mechanism is through --user and --password on the guest ttyS0 [By the way, libocas is just a tiny library with no dependencies that I tend to use as a smoke test.] Best, Christian
Bug#1002998: firejail-profiles: telegram-desktop not working with firejail
Hi, On Sun, Jan 02, 2022 at 02:58:26PM +, piorunz wrote: > Before upgrade to Testing, everything was working fine. > Something is wrong with firejail profile? > I request assistance. Thank you. This sounds similar to this upstream issue: https://github.com/netblue30/firejail/issues/4488 This was fixed by adding "whitelist /usr/share/TelegramDesktop" to the telegram.profile. Can you please check if that also works for you? Thanks. Kind regards, Reiner signature.asc Description: PGP signature
Bug#998244: lists.debian.org: request for debian-math mailing list
Hi Listmasters, Gentle ping on this? Since it has been a while now, and there are interested people, enabling a list will help us. Could you please consider processing the request whenever you have time? Regards, Nilesh On Tue, 14 Dec 2021 15:43:50 + Tobias Hansen wrote: > Hi Cord, > > I am also in favor of the creation of this list. I think we could then close > down debian-science-sagem...@alioth-lists.debian.net and move these > discussions to debian-math. > > Best, > Tobias > > On Sat, 13 Nov 2021 16:45:48 +0530 "Nilesh Patra" wrote: > > Dear list masters, > > > > Since a few people already responded on this bug, and other folks > > already showed interest in joining the team[1], would you please consider to > > process this mailing list request now? > > > > [1]: https://lists.debian.org/debian-science/2021/10/msg00034.html > > > > Thanks a lot for your work, > > Nilesh > > > > > > signature.asc Description: PGP signature
Bug#1003005: elkcode FTBFS with libxc 5.1.7
Source: elkcode Version: 6.3.2-2 Severity: serious Tags: ftbfs bookworm sid Control: close -1 7.2.42-1 https://buildd.debian.org/status/package.php?p=elkcode=sid ... mpif90 `dpkg-buildflags --get FFLAGS` `dpkg-buildflags --get CPPFLAGS` -Wall -ffast-math -funroll-loops -fopenmp -fallow-argument-mismatch `dpkg-buildflags --get LDFLAGS` -o elk modmain.o modmpi.o libxc_funcs.o libxc.o libxcifc.o modxcifc.o modfxcifc.o moddftu.o modrdm.o modphonon.o modscdft.o modtest.o modrandom.o modstore.o modpw.o modvars.o modtddft.o modgw.o modulr.o modjx.o modomp.o mkl_stub.o mkl_init.o oblas_stub.o oblas_init.o blis_stub.o blis_init.o w90_stub.o modw90.o zfftifc_fftw.o elk.o zbsht.o zfsht.o rbsht.o rfsht.o projsbf.o fsmooth.o nfftifc.o rfinp.o splint.o spline.o wsplint.o wsplintp.o splintwp.o sphcover.o r3frac.o genvsig.o gencfun.o zfpack.o addlorbcnd.o rfint.o sortidx.o gengkvec.o pade.o pades.o rfint0.o zfinp.o symrvf.o genapwfr.o rfcopy.o rhomagsh.o genylmg.o olpaa.o readfermi.o factr.o writechg.o zflmconj.o rminv.o zminv.o rlmrot.o rotrflm.o ztorflm.o rotzflm.o rfmtlm.o genzrm.o gensfacgp.o zmctmu.o zmctm.o hmlfv.o olpfv.o axangsu2.o checkmt.o symrf.o z2mm.o z2mctm.o z2mmct.o writefermi.o findnjcmax.o findscq.o plot1d.o plot2d.o plot3d.o hmllolo.o olprad.o occupy.o findkpt.o zfmtint.o rotrfmt.o forcek.o eveqnfvr.o findsym.o genvbmatk.o wigner3jf.o wigner6j.o mixbroyden.o zftrf.o gensocfr.o getcfgq.o wigner3j.o moke.o sfacinit.o sfacrho.o sfacmag.o gradwfcr2.o symrvfmt.o oepmain.o oepresk.o oepvcl.o oepvclk.o dbxcplot.o writehmlbse.o hmldbse.o hmldbsek.o dielectric_bse.o genidxbse.o writeevbse.o genwfpw.o writewfpw.o getwfpw.o genexpmat.o elnes.o potefield.o eulerrot.o fermisurfbxsf.o symmetry.o findsymcrys.o findsymsite.o plotpt1d.o writedos.o findprimcell.o proj2d.o nonlinopt.o vecplot.o wfcrplot.o energykncr.o eveqnss.o gendmatk.o gensdmat.o ggamt_1.o ggair_1.o ggamt_sp_1.o ggair_sp_1.o ggamt_2a.o ggair_2a.o ggamt_2b.o ggair_2b.o ggamt_sp_2a.o ggair_sp_2a.o ggamt_sp_2b.o ggair_sp_2b.o genspecies.o writeemd.o writeexpmat.o rotdmat.o hrmdmat.o reademd.o emdplot.o rfhkintp.o emdplot3d.o emdplot2d.o emdplot1d.o plotpt3d.o plotpt2d.o writeevsp.o torque.o ssfsmjx.o wxcplot.o effmass.o genlmirep.o ssfext.o sstask.o spiralsc.o genscss.o genfspecies.o writespecies.o exxengy.o exxengyk.o xc_c_tb09.o elfplot.o potplot.o mae.o writestate.o readstate.o rotaxang.o axangrot.o dmatls.o gendmat.o numlist.o sbesseldm.o genvchi0.o genspchi0.o vclcore.o hmlxbse.o hmlxbsek.o genvmatk.o writeepsinv.o putepsinv.o curden.o curdenk.o hflocal.o dielectric.o bdipole.o roteuler.o lopzflm.o eveqnfvz.o rhomag.o hmlaa.o hmlalo.o gencore.o gentau.o gentauk.o hmlistl.o olpistl.o gengclg.o hmlrad.o rhonorm.o rfmtsm.o olplolo.o genshtmat.o allatoms.o rtozflm.o rtozfmt.o gauntyry.o fderiv.o moment.o sctovec.o match.o writeinfo.o rfpack.o gaunt.o readinput.o ztorfmt.o putevecfv.o zfmtinp.o zfcmtinp.o writelinen.o writekpts.o rfmtinp.o brzint.o rhocore.o writelat.o mtdmin.o atpstep.o potcoul.o zfmtconj.o symrfmt.o putpmat.o eveqnz.o olpalo.o checkfsm.o rhoplot.o potnucl.o potxc.o erf.o gradzf.o writegeom.o linengy.o bandstr.o gengvc.o gengclq.o closefiles.o writefsm.o eveqn.o rhomagk.o factnm.o atom.o radnucl.o charge.o genrmesh.o genapwlofr.o wavefmt.o genzrho.o potks.o sbessel.o clebgor.o hermite.o findband.o genbs.o gencfrc.o genws.o chargemt.o gndstate.o addbfsm.o initoep.o orthevsv.o fermisurf.o findswidth.o gradrf.o dos.o gradzfmt.o nuclei.o writesym.o zftzf.o polynm.o rdirac.o zfmtftoc.o rfmtftoc.o gradrfmt.o genzvclmt.o getevalfv.o mixlinear.o gengvec.o putevalfv.o rfmtpack.o zfmtpack.o writestrain.o writeforces.o r3mv.o r3mtv.o r3cross.o r3minv.o r3mdet.o r3mm.o r3mtm.o r3mmt.o r3vo.o symvec.o curdenplot.o hartfock.o eveqnhf.o zpotclmt.o genlofr.o rfinpc.o eveqnit.o genzfrm.o gengqrf.o writepmat.o genwfsv.o writelsj.o writesf.o rzfinp.o genjlgprmt.o gridsize.o sphcrd.o writeiad.o readspecies.o i3mtv.o writeeval.o i3minv.o i3mdet.o genevfsv.o getpmat.o timesec.o mixpack.o mixerifc.o symmat.o rhoinit.o maginit.o rvfcross.o eveqnfv.o energynn.o rfinterp.o rfplot.o geomopt.o ylmroty.o ylmrot.o gcd.o sdelta.o stheta.o sdelta_mp.o stheta_mp.o sdelta_fd.o stheta_fd.o sdelta_sq.o stheta_sq.o sdelta_lr.o stheta_lr.o mossbauer.o gentpmae.o symveca.o massnucl.o wavefcr.o gradwf2.o geomplot.o findngkmax.o reciplat.o genrlmv.o genvmat.o putoccsv.o getoccsv.o curlrvf.o latvstep.o energy.o delevec.o rdiracint.o rzfmtinp.o genstrain.o genstress.o writestress.o rschrodint.o mixadapt.o genffacgp.o genidxlo.o writeengy.o genpmatk.o putevecsv.o getevecsv.o writegclq.o putevalsv.o genppts.o force.o vecfbz.o rfirsm.o gengclgq.o findsymlat.o grad2rfmt.o findqpt.o zftwfir.o symrfir.o symrvfir.o getevalsv.o genjlgpr.o init0.o init1.o init2.o init3.o init4.o genpmat.o putkmat.o getkmat.o genkmat.o genexpmt.o epsinv.o getevecfv.o zfmtctof.o wfplot.o straingkq.o symdmat.o genylmv.o nesting.o eveqnsv.o
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sun, Jan 02, 2022 at 06:53:51PM +0100, Mattia Rizzolo wrote: > Correlated, do you know how long do they plan on keeping using python2? > That's plainly unsuitable, it really is not going to last much longer in > debian. Current state of the Python 3 upstream migration can be found here: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/python3_migration.md So it sounds like it's almost ready except tests. But the migration doesn't seem like a top priority either, https://bugs.chromium.org/p/chromium/issues/detail?id=941669 dates back to March 2019... Cheers, Moritz
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 17:11 schrieb Karsten: Basically you can install the self-signed certificate (if you or a trusted party signed it, and you have transmitted it over a secure channel, for instance, via SFTP or SCP) into the trust store (assuming it suits both the TLS server and the signing CA roles - which was set when you created it). Just for understanding - the installation is the public certificate of the server, or must be a special file derived from the private certificate? "It depends" - on how you exactly you generated it - even if you only created it with "openssl req -x509 ...", the openssl configuration files matter. Normally, 1. the client's trust store (OpenSSL on the fetchmail computer) needs the CA certificate, i. e. one with the CA flag set to true in the basicConstraints, or basicContraints missing, see the x509(1ssl) manual page under CERTIFICATE EXTENSIONS. 2. Then, the server needs to present a certificate that is suitable as "SSL Server" (extendedKeyUsage = serverAuth) role. See the x509v3_config(5ssl) manual page for details. If your server's certificate does not fulfill both criteria, you better start over and set up a ca (and store its private key password-protected in a safe place, as you seldomly need it), and a separate server cert signed by your own ca. easy-rsa may help with that. Check /usr/share/doc/easy-rsa, easy-rsa has README files, but no manual page. To check: openssl x509 -noout -text -in whatever.crt # or whatever.pem shows you that, here for a CA certificate: X509v3 Basic Constraints: CA:TRUE ... X509v3 Key Usage: Certificate Sign, CRL Sign The TLS server has X509v3 Basic Constraints: CA:FALSE ... X509v3 Extended Key Usage: TLS Web Server Authentication Some of this may not be enforced in currently shipping fetchmail versions, but since a lot of public foot-shooting was involved in third-party documentation that advised trust-on-first-use schemes without warning people of the dangers involved, future versions might actually tighten things even more, so, f.i. validate CA flags of all but the server certificate. I don't currently use Debian or derivatives as so you need to check [update-]ca-certificates documentation and configuration to be sure that your certificate is (a) put in the right place where update-ca-certificate finds it, (b) "enabled" in configuration and processed into the output trust store, and (c) not in a place where it will be removed on system upgrades. dpkg-reconfigure ca-certificates - possibly with some modified priority option - might be required. That stackexchange link in the earlier message hints that there were changes somewhen in the past, and also be sure to re-check documentation since the answer there is older than Debian 11. No, where does that access happen? The trust store is local to your computer and fetchmail might use your system's DNS resolver (which can have privacy implications) and will connect to the servers you point it to. First you send your certificate to the public CA to sign it. Then an client must connect the CA to proove that the public certificate is correct signed. Correct or wrong? If I am my own CA, I am not sending something anywhere. I install the ca certificate on my clients' trust stores, put its (the CA) private keys on a CD or USB key so it's not left on my computer (let alone on my server), and that's it. I've been doing that for more than a dozen years; for public services however Let's Encrypt is a viable alternative.
Bug#1003016: node-chart.js breaks cacti autopkgtest: did Chart.js just got renamed to chart.js?
Source: node-chart.js Control: found -1 node-chart.js/3.7.0+~0.1.9-1 Severity: serious Tags: sid bookworm User: debian...@lists.debian.org Usertags: breaks needs-update Control: affects -1 cacti python3-ontospy [X-Debbugs-CC: debian...@lists.debian.org python3-onto...@packages.debian.org] Dear maintainer(s), [I'm also the maintainer of the cacti package in Debian] With a recent upload of node-chart.js the autopkgtest of cacti fails in testing when that autopkgtest is run with the binary packages of node-chart.js from unstable. It passes when run with only packages from testing. In tabular form: passfail node-chart.js from testing3.7.0+~0.1.9-1 cacti from testing1.2.19+ds1-2 all others from testingfrom testing I copied some of the output at the bottom of this report. The cacti autopkgtest is a simple recursive web crawl of the web app. The test fails because it can't find Chart.js while it expect it to be there. Chart.js used to be linked in from libjs-chart.js. There is a chart.js in the new version, is that just the renamed version of Chart.js? If that's the case, can a symlink be provided to enable reverse dependencies to just keep on working? (Same for other files that got renamed) Currently this regression is blocking the migration of node-chart.js to testing [1]. Can you please investigate the situation? If you think that reverse Depends should just move on, please clone and reassign the bug to all reverse dependencies that use Chart.js (or other files that got renamed/dropped). 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=node-chart.js https://ci.debian.net/data/autopkgtest/testing/amd64/c/cacti/17997504/log.gz 2022-01-01 21:11:48 - ERROR PHP WARNING: md5_file(/usr/share/cacti/site/lib/../include/js/Chart.js): failed to open stream: No such file or directory in file: /usr/share/cacti/site/lib/functions.php on line: 6072 2022-01-01 21:11:48 - CMDPHP PHP ERROR WARNING Backtrace: (/automation_tree_rules.php[68]:top_header(), /lib/functions.php[4155]:include_once(), /include/top_header.php[34]:html_common_header(), /lib/html.php[2566]:get_md5_include_js(), /lib/functions.php[6089]:get_md5_hash(), /lib/functions.php[6072]:md5_file(), CactiErrorHandler()) OpenPGP_signature Description: OpenPGP digital signature
Bug#1002986: libguestfs-tools: Depends on guestfs-tools that is not in the archive
* Laurent Bigonville: > It looks like libguestfs-tools version 1:1.46.2-1 in depending on > guestfs-tools that is not in the archive making the package uninstalable > > guestfs-tools is currently stuck in the new queue Right. Let's just wait. (Or do you know of a way to speed this up?) Cheers, -Hilko
Bug#904233: RFA: persp-projectile
control: title -1 O: persp-projectile -- integrate perspective.el with projectile Hello, On Sun 22 Jul 2018 at 01:31PM +08, Sean Whitton wrote: > Package: wnpp > Severity: normal > > I request an adoptor for the persp-projectile package. > > This package is no longer in my ~/.emacs.d/init.el and it would be > better if someone who actually uses the package maintains it. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. > > The package description is: > With this library, Emacs will create a separate perspective for each > Projectile project. > . > See the documentation for elpa-persp and elpa-projectile for more > details. I hereby orphan persp-projectile. -- Sean Whitton signature.asc Description: PGP signature
Bug#952807: RFA: cider
control: retitle -1 O: cider -- Clojure IDE for Emacs Hello, On Sat 29 Feb 2020 at 08:28AM -07, Sean Whitton wrote: > Package: wnpp > Severity: normal > > I request an adoptor for CIDER. > > Updating CIDER to new upstream releases is more work than typical Emacs > addons, because it is tightly coupled to Clojure. The current upstream > release, in particular, requires a lot of work to get the -doc packages > to include the new docs. > > This is a team-maintained package, so the adoptor should either replace > me in Uploaders:, or alternatively take the package out of the team's > hands. > > The package description is: > CIDER is the Clojure(Script) Interactive Development Environment that Rocks > . > While clojure-mode provides Emacs support for editing Clojure source files, > CIDER's cider-mode provides support for interacting with a running Clojure > process for compilation, debugging, looking up definitions and more. I hereby orphan cider. -- Sean Whitton signature.asc Description: PGP signature
Bug#1003031: RFA: projectile
Package: wnpp Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org Control: affects -1 src:projectile I request an adoptor for the projectile package. I haven't used it for some time, as I'm now using the built-in package.el for everything for which I used to use projectile. This is a team-maintained package, so the adoptor should either replace me in Uploaders:, or alternatively take the package out of the team's hands. The package is maintained using git-debrebase, using the workflow described in dgit-maint-debrebase(7). That's been working well, so I'd encourage any adopter to continue using the tool. The package description is: This library enhances Emacs with easy project management and navigation. The concept of a project is simple: just a folder containing a special file. Currently git, mercurial, darcs and bazaar repos are considered projects by default. So are lein, maven, sbt, scons, rebar and bundler projects. If you want to mark a folder manually as a project just create an empty .projectile file in it. . Some of Projectile's features: . * jump to a file in project * jump to files at point in project * jump to a directory in project * jump to a file in a directory * jump to a project buffer * jump to a test in project * toggle between files with same names but different extensions (e.g. `.h` <-> `.c/.cpp`, `Gemfile` <-> `Gemfile.lock`) * toggle between code and its test (e.g. `main.service.js` <-> `main.service.spec.js`) * jump to recently visited files in the project * switch between projects you have worked on * kill all project buffers * replace in project * multi-occur in project buffers * grep in project * regenerate project etags or gtags * visit project in dired * run make in a project with a single key chord -- Sean Whitton signature.asc Description: PGP signature
Bug#952808: Interest in helping maintain clojure-mode
Hello Michael Platt, On Mon 21 Sep 2020 at 08:30AM -04, Michael Platt wrote: > Hi Mr. Whitton, > > I'm looking to do some work to start getting into helping maintain Debian. > I use the OS and very much enjoy it as my everyday development system. I > am also a fan of Emacs and use it for personal development applications, > and Clojure and was looking through the Debian list of packages requesting > maintainers. Obviously I've never done something like this before but I > would be happy to come on board and help out in any way possible with the > packaging. Let me know if you still need someone and don't mind me coming > on to help. I'm sorry you never got a reply to this. Debian's bug tracking system does not copy bug submitters on follow-up messages by default. Are you still interested? -- Sean Whitton signature.asc Description: PGP signature
Bug#1003032: debootstrap: harden signature checking
Package: debootstrap Version: 1.0.126+nmu1 Severity: normal Tags: security Hey there. As far as I understood it, debootstrap defaults neither to --no-check-gpg nor to --force-check-gpg, but instead, if a keyring is speicified for some distribution and if that file is available, it uses (and verifies) these (and hopefully fails if anything fails later on). However, it also: - falls back to https (?) - correct me if I'm wrong, falls back to no verification if no key file was specified for the distribution or the file wasn't found That seems to make to too easy to accidentally install untrusted code. https is generally questionable, given the broken CA-model. There are some 150 CAs in the Mozilla CA bundle, and on top of these thousands of intermediate CAs. It seems far too easy for an attacker to fake a certificate if that's really desired. So my suggestion would be: - defaut to --force-check-gpg - add some --check-gpg-but-fallback-to-https option that is the current behaviour - if either the /usr/share/debootstrap/scripts/ for some distro doesn't name a keyring file or that file isn't readable, fail unless --no-check-gpg is given. Yes, that also includes failure if --check-gpg-but-fallback-to-https was given because likely the keyring file should be just there. Cheers, Philippe
Bug#1003033: cowdancer: harden package verification
Source: cowdancer
Version: 0.89
Severity: wishlist
Tags: security
Hey.
I was looking a bit through the code of cowbuilder and qemubuilder.
E.g. for qemubuilder, the manpage already says:
"The possible configuration options are as follows. Others are ignored."
Altough, it seemed in the code it would in fact respect ALLOWUNTRUSTED.
However, it doesn't seem to respect DEBOOTSTRAPOPTS? Taking just these
instead:
debootstrap_command_line[1] = "--arch";
debootstrap_command_line[2] = pc->arch;
debootstrap_command_line[3] = "--foreign";
DEBOOTSTRAP_ADD_PARAM(pc->distribution);
DEBOOTSTRAP_ADD_PARAM(pc->buildplace);
DEBOOTSTRAP_ADD_PARAM(pc->mirror);
DEBOOTSTRAP_ADD_PARAM(NULL);
Especially if one has set something like:
DEBOOTSTRAPOPTS=('--force-check-gpg'
'--keyring=/usr/share/keyrings/debian-archive-keyring.gpg'
'--variant=buildd')
to make sure that gpg signatures with the keyring are really always
used (as far as I understand, debootstrap allows fallback to just
https otherwise).
Does it consider APTKEYRINGS? Or at least just copy the host systems
APT keyrings safely into the VM and use only these?
I haven't checked so much, whether it's already done properly for cowbuilder.
Thanks,
Philippe
Bug#1003003: libqalculate FTBFS on architectures where char is unsigned
Source: libqalculate Version: 3.22.0-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/package.php?p=libqalculate ... FAIL: unittest == [32m ./tests/variables.batch - 11 tests passed [0m[32m ./tests/units.batch - 13 tests passed [0m[31m Mismatch detected at line 42 char(0xD8) expected ''Ø'' received '"Ø"' [0mRunning all unit tests Running unit tests from 'variables.batch' Running unit tests from 'units.batch' Running unit tests from 'strings.batch' FAIL unittest (exit status: 1) Testsuite summary for libqalculate 3.22.0 # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See src/test-suite.log make[4]: *** [Makefile:835: test-suite.log] Error 1
Bug#1002376: python-aiosqlite: FTBFS: AttributeError: module 'mistune' has no attribute 'BlockGrammar'
On Sunday, 02 January 2022, 13:15 +0100, Benjamin Hof wrote: > compatible to mistune v2 At the moment this is not the case.
Bug#1003006: graphviz: please migrate Recommends fonts-liberation to fonts-liberation2
Package: graphviz Version: 2.42.2-5 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please migrate the Recommends on fonts-liberation to fonts-liberation2. Thanks! - -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/8 CPU threads) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages graphviz depends on: ii libc6 2.33-1 pn libcdt5 pn libcgraph6 ii libexpat1 2.4.2-1 ii libgd3 2.3.0-2 ii libglib2.0-0 2.70.2-1 pn libgts-0.7-5 pn libgvc6 pn libgvpr2 pn liblab-gamut1 ii libx11-6 2:1.7.2-2+b1 pn libxaw7 pn libxmu6 pn libxt6 Versions of packages graphviz recommends: pn fonts-liberation Versions of packages graphviz suggests: pn graphviz-doc pn gsfonts -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmHR6LsACgkQrh+Cd8S0 17bY7BAAhD+QAUuA4J+RbMonwWzR7srTapAgZlLz0YMqTevLE8cXuW+aKJPXVsj7 nCz1CVzCwjt77tuvalN2ZZjSDfs081+fQ82bq4oS5aQC3rfviy38r+/J8ljYBzoS e5ZtlMv11UCrSBy1A/71w4jFA+LVi8sTuxQ7yYX0uhNtxIca9vnnsQ5RyQkjXeZj 5chXAuMe9VsqmGOPF/8K1+HKnRQN7hfNizRGWN2KcqAO7PD/M+dp5mHymV+3f5oK mSuJAXz85/OPEL6zB502TSCe2GpBapSMCAMbJj+aCtbWTKc0FZ3080NywMaFjQQq rp5bILv/2ePitPnS4YsVmS2eo4a+m+P2TXB/YpFppw4YXf62ojyM/FwTWDcZo6fC 1z/7GPJ3J31SNDFuqV5gBLbV7IBmw4vCrCQNysMe4jlKCrZcj5AU4MXDnrKngkwk 1qjRrNdsGrX8YJmjxemR6XyWnwf67UGGYevdf5AR4bC4lG6oUSG2e+ZIVEKPxqFG vrfUrk+nUa0iHRYEnxiVzWfc/QkAPPlHnbZuK4XK0T2QDGyDAVDiO/Lx6LlNuXFP RxgJ8W4W5ERjPoikYOwERclfChuvtKUU3TzKQ6vlv/iSCazHrbpSpreO0JezwrkM VEiTyuR3voUPTrMSlI5vOwGAubGc+8/yfuXAcVBqjmx7lTLEfW8= =exER -END PGP SIGNATURE-
Bug#992649: run-parts in /usr/bin breaks systemd-cron
Hi, I found this bug by luck. I miss the context (why ? UsrMerge ?) I can build systemd-cron like this during the transition: ./configure --runparts="/usr/bin/env run-parts" Greetings, Alexandre Detiste
Bug#1003008: Error 134633601: Error while parsing number"
Package: grub-legacy Version: 0.97-79 Severity: Normal After upgrade grub-legacy from 0.97-78 to 0.97-79 installation fails with message "Error 134633601: Error while parsing number": - grub> root (hd0,0) root (hd0,0) Filesystem type is ext2fs, partition type 0x8065e03 grub> setup (hd0) setup (hd0) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd-141250989)"... failed (this is not fatal) Running "embed /grub/e2fs_stage1_5 (hd-141250989,-"... failed (this is not fatal) Running "install /grub/stage1 (hd-141250989) /grub/stage2 p /grub/menu.lst "... failed Error 134633601: Error while parsing number - Observed on all updated hosts (about ten in my own). Rollback to 0.97-78 resolves the problem (with the same config files). Package versions: ii grub-legacy0.97-79 amd64GRand Unified Bootloader (Legacy version) ii grub-common2.04-20 amd64GRand Unified Bootloader (common files) ii libc6-i386 2.33-1 amd64GNU C Library: 32-bit shared libraries for AMD64 Debian version: Debian GNU/Linux bookworm/sid (64bit) -- Eugene Berdnikov
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On 1/2/22 12:53 PM, Mattia Rizzolo wrote: On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: I've got 96.0.4664.110 building on both bullseye and sid Trying it, I see it still build-depends on python-jinja2. That package is now gone, so it's not actually buildable in sid anymore. Correlated, do you know how long do they plan on keeping using python2? That's plainly unsuitable, it really is not going to last much longer in debian. Sorry, I hadn't pushed the commits yet. I just did, but like I said I still need to clean 'em up.
Bug#1003012: bash: Corrupted multibyte characters in command substitutions
Package: bash Version: 5.1-2+b3 Severity: critical Justification: breaks unrelated software Tags: patch upstream l10n I've reported this bug on bug-bash: https://lists.gnu.org/archive/html/bug-bash/2022-01/msg0.html only to learn that it's known and not fixed for months (it was known before bullseye was released, so a timely fix would have prevented the bug ever reaching stable): https://savannah.gnu.org/patch/?10035 I'm reporting it as critical because it causes silent data corruption and potentially affects each bash script in the system. Since the bash developers don't seem to take that seriously, I'm asking the Debian maintainers to put out a fixed version ASAP to prevent further damage -- hopefully as a security patch. (I'm no expert in writing exploits, but I think it's quite possible such a bug can be exploited. I hope you don't have to wait for an actual exploit in order to fix the bug.) Both reports listed above contain a patch. They're different, but either one will fix the immediate problem. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/24 CPU threads) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages bash depends on: ii base-files 11.1+deb11u2 ii debianutils 4.11.2 ii libc62.31-13+deb11u2 ii libtinfo66.2+20201114-2 Versions of packages bash recommends: ii bash-completion 1:2.11-2 Versions of packages bash suggests: pn bash-doc -- no debconf information
Bug#1003020: openblas breaks hypre autopkgtest on armhf: test times out after 2:47h
Source: openblas, hypre Control: found -1 openblas/0.3.19+ds-1 Control: found -1 hypre/2.22.1-3 Severity: serious Tags: sid bookworm X-Debbugs-CC: debian...@lists.debian.org User: debian...@lists.debian.org Usertags: breaks needs-update Dear maintainer(s), With a recent upload of openblas the autopkgtest of hypre fails in testing when that autopkgtest is run with the binary packages of openblas from unstable on armhf due to a timeout after 2:47 h. It passes when run with only packages from testing in about 9-12 minutes. In tabular form: passfail openblas from testing0.3.19+ds-1 hypre from testing2.22.1-3 all others from testingfrom testing I copied some of the output at the bottom of this report, but as the test times out, I suspect it just hangs and there's not much useful to see. Currently this regression is blocking the migration of openblas 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=openblas https://ci.debian.net/data/autopkgtest/testing/armhf/h/hypre/17988587/log.gz Building tests for HYPRE rm -f *.o *.obj rm -rf pchdir tca.map *inslog* mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o ij.o ij.c Building ij ... mpicc -o ij ij.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o ij_assembly.o ij_assembly.c Building ij_assembly ... mpicc -o ij_assembly ij_assembly.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o sstruct.o sstruct.c Building sstruct ... mpicc -o sstruct sstruct.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o struct.o struct.c Building struct ... mpicc -o struct struct.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o ams_driver.o ams_driver.c Building ams_driver ... mpicc -o ams_driver ams_driver.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o maxwell_unscaled.o maxwell_unscaled.c Building maxwell_unscaled ... mpicc -o maxwell_unscaled maxwell_unscaled.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o struct_migrate.o struct_migrate.c Building struct_migrate ... mpicc -o struct_migrate struct_migrate.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o sstruct_fac.o sstruct_fac.c Building sstruct_fac ... mpicc -o sstruct_fac sstruct_fac.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include -I/usr/lib/arm-linux-gnueabihf/openmpi/include/openmpi-c -o ij_mv.o ij_mv.c Building ij_mv ... mpicc -o ij_mv ij_mv.o -L/lib -lHYPRE -Wl,-rpath,/lib -L/usr/lib/arm-linux-gnueabihf/openmpi/lib -lmpi -lm mpicc -I/usr/include/hypre -I/usr/include/superlu -I/usr/include/superlu-dist -pthread -I/usr/lib/arm-linux-gnueabihf/openmpi/include
Bug#1002993: systemd: Setting access ACL: invalid argument (Upgrade to 247.3-6 from buster to bullseye in container)
On Sun, Jan 02, 2022 at 04:31:01PM +0100, Michael Biebl wrote: > On 02.01.22 16:12, Tobias Frost wrote: > > > Filesystem ia an ext4 on a lvm, backed by a raid1. > > Does the file system support xattr and acl? I guess so, but ACLs are nothing I use normally, so I cant tell if I use them correctly... root@thecus:/var/log/journal# touch test.txt root@thecus:/var/log/journal# setfattr -n user.test -v "xattr test string" test.txt root@thecus:/var/log/journal# getfattr test.txt # file: test.txt user.test root@thecus:/var/log/journal# getfacl test.txt # file: test.txt # owner: root # group: systemd-journal user::rw- group::r-x #effective:r-- group:adm:r-x #effective:r-- group:4294967295:r-x#effective:r-- mask::r-- other::r-- Albeith, I cannot set ACLs in /var/log/journal: setfacl --modify="u:unifi:rw" test.txt setfacl: test.txt: Malformed access ACL `user::rw-,user:unifi:rw-,group::r-x,group:adm:r-x,group:4294967295:r-x,mask::rwx,other::r--': Duplicate entries at entry 5 Same command in /var/log works: root@thecus:/var/log# touch test.txt ; setfacl --modify="u:unifi:rw" test.txt root@thecus:/var/log# getfacl test.txt # file: test.txt # owner: root # group: root user::rw- user:unifi:rw- group::r-- mask::rw- other::r-- root@thecus:/var/log# root@thecus:/var/log# ls -lad journal/ drwxr-sr-x+ 3 root systemd-journal 4096 Jan 2 21:33 journal/ root@thecus:/var/log# getfacl journal/ # file: journal/ # owner: root # group: systemd-journal # flags: -s- user::rwx group::r-x group:adm:r-x group:4294967295:r-x mask::r-x other::r-x default:user::rwx default:group::r-x default:group:adm:r-x default:group:4294967295:r-x default:mask::r-x default:other::r-x root@thecus:/var/log# mount | grep journal root@thecus:/var/log#
Bug#1002998: firejail-profiles: telegram-desktop not working with firejail
Yes, that worked! Thank you! On 02/01/2022 15:48, Reiner Herrmann wrote: Hi, On Sun, Jan 02, 2022 at 02:58:26PM +, piorunz wrote: Before upgrade to Testing, everything was working fine. Something is wrong with firejail profile? I request assistance. Thank you. This sounds similar to this upstream issue: https://github.com/netblue30/firejail/issues/4488 This was fixed by adding "whitelist /usr/share/TelegramDesktop" to the telegram.profile. Can you please check if that also works for you? Thanks. Kind regards, Reiner -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Bug#1003035: ITP: python-clevercsv -- Mutable set data type that remembers the order of its entries
Package: wnpp Severity: wishlist Owner: Louis-Philippe Véronneau Package name: python-clevercsv Version : 0.7.1 URL : https://github.com/alan-turing-institute/CleverCSV License : Expat Programming Lang: Python Description : Drop-in replacement for the Python csv package with improved dialect detection CleverCSV provides a drop-in replacement for the Python csv package with improved dialect detection for messy CSV files. It also provides a handy command line tool that can standardize a messy file or generate Python code to import it. This package is required to upload deepdiff version 5.6.0. I'm planning to maintain this package in the Python Team. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#1002978: Another GPU hang
I rebooted with the GRUB options intel_idle.max_cstate=1 i915.disable_power_well=1 i915.enable_dc=0 which my research shows sometimes helps with these kinds of GPU hangs. For quite some time performance was acceptable, but less than 20 hours later I triggered a GPU hang by switching desktops rapidly in fvwm. I was executing my keyboard equivalents for fvwm's 'Desk 0 9' followed by 'Scroll +0 +100' followed by 'Scroll +0 -100' followed by 'Desk 0 11' in repeated cycling when the system hung. Before the hang, the dmesg output reports three lines with 'perf: interrupt took too long'. These were minor hiccups/freezes that failed to trigger a crash/CPU hang error in the logs. But I consider them related to the problem. I was again changing desktops and moving around my desktops using my keyboard shortcuts mentioned above and the i915 driver could not cope. Back in Jessie this kind of work was routine for me with no fear of triggering kernel stack dumps. The i915 driver appears to have developed major bugs at least with my chipset. I have attached dmesg output capturing boot messages and the crash/hang. The other file contains the output of 'cat /sys/class/drm/card0/error'. I am planning to reboot soon to try another test, since daily GPU hangs will slow my productivity unacceptibly. I need to keep debugging in the hopes that I can find a solution. -- CJ Fearnley | LinuxForce Inc. c...@linuxforce.net | Hosting and Linux Consulting https://www.LinuxForce.net | https://blog.LinuxForce.net [0.00] Linux version 5.10.0-10-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.84-1 (2021-12-08) [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-10-amd64 root=/dev/mapper/precession-root ro quiet pcie_aspm=force intel_idle.max_cstate=1 i915.disable_power_well=1 i915.enable_dc=0 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x1fff] usable [0.00] BIOS-e820: [mem 0x2000-0x201f] reserved [0.00] BIOS-e820: [mem 0x2020-0x3fff] usable [0.00] BIOS-e820: [mem 0x4000-0x401f] reserved [0.00] BIOS-e820: [mem 0x4020-0xbad92fff] usable [0.00] BIOS-e820: [mem 0xbad93000-0xbadd9fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbadda000-0xbade0fff] ACPI data [0.00] BIOS-e820: [mem 0xbade1000-0xbade1fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbade2000-0xbae04fff] reserved [0.00] BIOS-e820: [mem 0xbae05000-0xbae05fff] usable [0.00] BIOS-e820: [mem 0xbae06000-0xbae17fff] reserved [0.00] BIOS-e820: [mem 0xbae18000-0xbae24fff] ACPI NVS [0.00] BIOS-e820: [mem 0xbae25000-0xbae48fff] reserved [0.00] BIOS-e820: [mem 0xbae49000-0xbae8bfff] ACPI NVS [0.00] BIOS-e820: [mem 0xbae8c000-0xbaff] usable [0.00] BIOS-e820: [mem 0xbb80-0xbf9f] reserved [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00023fdf] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] DMI: BIOSTAR Group H61MU3/H61MU3, BIOS 4.6.4 04/07/2011 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 2394.344 MHz processor [0.000831] e820: update [mem 0x-0x0fff] usable ==> reserved [0.000834] e820: remove [mem 0x000a-0x000f] usable [0.000843] last_pfn = 0x23fe00 max_arch_pfn = 0x4 [0.000847] MTRR default type: uncachable [0.000848] MTRR fixed ranges enabled: [0.000850] 0-9 write-back [0.000851] A-B uncachable [0.000852] C-C write-protect [0.000853] D-E7FFF uncachable [0.000854] E8000-F write-protect [0.000854] MTRR variable ranges enabled: [0.000856] 0 base 0 mask E write-back [0.000857] 1 base 2 mask FC000 write-back [0.000859] 2 base 0BB80 mask FFF80 uncachable [0.000860] 3 base
Bug#1003017: dulwich: autopkgtest regression: src/debian/tests/testsuite3: 10: -m: not found
Source: dulwich Version: 0.20.26-1 X-Debbugs-CC: debian...@lists.debian.org Severity: serious User: debian...@lists.debian.org Usertags: regression Dear maintainer(s), With a recent upload of dulwich the autopkgtest of dulwich fails in testing when that autopkgtest is run with the binary packages of dulwich from unstable. It passes when run with only packages from testing. In tabular form: passfail dulwichfrom testing0.20.26-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=dulwich https://ci.debian.net/data/autopkgtest/testing/amd64/d/dulwich/17999494/log.gz = Running tests with python3.9 == /tmp/autopkgtest-lxc.n4tqfogv/downtmp/build.r97/src/debian/tests/testsuite3: 10: -m: not found autopkgtest [23:08:36]: test testsuite3 OpenPGP_signature Description: OpenPGP digital signature
Bug#1002591: misdetects socket activated ssh
Hi Marc, On Sat, 2022-01-01 at 20:55 +0100, Marc Haber wrote: > Sure: > 1 [1/4996]mh@torres:~ $ pgrep ssh > 315675 > 315738 > [2/4997]mh@torres:~ $ sudo cat /proc/315675/cgroup > [sudo] password for mh on torres: > 0::/user.slice/user-1001.slice/session-296.scope > [3/4998]mh@torres:~ $ sudo cat /proc/315738/cgroup > 0::/user.slice/user-1001.slice/session-296.scope > [4/4999]mh@torres:~ $ > thanks! Needrestart should ignore those ssh instances since there is a user slice cgroup. It does not work due to this check[1] in needrestart. [1] https://github.com/liske/needrestart/blob/v3.5/needrestart#L637 Looks like a systemd/cgroup related change in bullseye, buster seems not to be affected. Regards, Thomas > > As a workaround you might blacklist sshd in needrestart but I think > > a > > generic approach handling socket activation services in needrestart > > would be better. Therefore needrestart need a way to detect if the > > process belongs to a socket activated service. > > It is also possible to mask ssh.service entirely in systemd. But of > couse having the heuristic fixed would be better. > > Greetings > Marc >
Bug#908941: unarchiving 908941, reopening 908941
rpyc | 5.0.1-1 | new| source
Bug#1003022: websocketpp: FTBFS with SCons 4.2.0+
Source: websocketpp
Version: 0.8.2-3
Severity: important
Tags: patch
Hi,
SCons 4.3.0 was released some time ago. I've packaged it and would
like to upload it in the next day or so. Your package FTBFS with that,
for which a patch is attached to fix it.
Regards,
Laszlo/GCS
Description: SCons 4.2.0 no longer has env_cpp11.has_key()
Check env_cpp11 as an array.
Author: Laszlo Boszormenyi (GCS)
Forwarded: no
Last-Update: 2022-01-02
---
--- websocketpp-0.8.2.orig/examples/broadcast_server/SConscript
+++ websocketpp-0.8.2/examples/broadcast_server/SConscript
@@ -13,7 +13,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs]
prgs += env_cpp11.Program('broadcast_server', ["broadcast_server.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/debug_client/SConscript
+++ websocketpp-0.8.2/examples/debug_client/SConscript
@@ -14,7 +14,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs] + [tls_libs]
prgs += env_cpp11.Program('debug_client', ["debug_client.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/debug_server/SConscript
+++ websocketpp-0.8.2/examples/debug_server/SConscript
@@ -13,7 +13,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs]
prgs += env_cpp11.Program('debug_server', ["debug_server.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/dev/SConscript
+++ websocketpp-0.8.2/examples/dev/SConscript
@@ -11,7 +11,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
BOOST_LIBS_CPP11 = boostlibs(['unit_test_framework','system','timer','chrono'],env_cpp11) + [platform_libs] + [polyfill_libs]
prgs += env_cpp11.Program('main', ["main.cpp"], LIBS = BOOST_LIBS_CPP11)
--- websocketpp-0.8.2.orig/examples/echo_client/SConscript
+++ websocketpp-0.8.2/examples/echo_client/SConscript
@@ -13,7 +13,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs] + ['z']
prgs += env_cpp11.Program('echo_client', ["echo_client.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/echo_server/SConscript
+++ websocketpp-0.8.2/examples/echo_server/SConscript
@@ -13,7 +13,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs]
prgs += env_cpp11.Program('echo_server', ["echo_server.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/echo_server_both/SConscript
+++ websocketpp-0.8.2/examples/echo_server_both/SConscript
@@ -14,7 +14,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs] + [tls_libs]
prgs += env_cpp11.Program('echo_server_both', ["echo_server_both.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/echo_server_tls/SConscript
+++ websocketpp-0.8.2/examples/echo_server_tls/SConscript
@@ -14,7 +14,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] + [polyfill_libs] + [tls_libs]
prgs += env_cpp11.Program('echo_server_tls', ["echo_server_tls.cpp"], LIBS = ALL_LIBS)
else:
--- websocketpp-0.8.2.orig/examples/external_io_service/SConscript
+++ websocketpp-0.8.2/examples/external_io_service/SConscript
@@ -13,7 +13,7 @@ env_cpp11 = env_cpp11.Clone ()
prgs = []
# if a C++11 environment is available build using that, otherwise use boost
-if env_cpp11.has_key('WSPP_CPP11_ENABLED'):
+if 'WSPP_CPP11_ENABLED' in env_cpp11:
ALL_LIBS = boostlibs(['system'],env_cpp11) + [platform_libs] +
Bug#1003023: ITP: python-django-pint -- Django Quantity Field
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-de...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-django-pint Version : 0.6.3 Upstream Author : Ben Harling * URL : https://github.com/CarliJoy/django-pint/ * License : Expat Programming Lang: Python Description : Django Quantity Field A small Django field extension allowing you to store quantities in certain units and perform conversions easily. Uses pint behind the scenes. Also contains a form field class and form widget that allows a user to choose alternative units to input data. The cleaned_data will output the value in the base_units defined for the field, eg: you specify you want to store a value in grams but will allow users to input either grams or ounces. I intend to maintain this as part of the DPT. -BEGIN PGP SIGNATURE- iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmHSFtIRHGZsYWRpQGRl Ymlhbi5vcmcACgkQ/9PIi5l90WrHBAf/RmsRWUfCu8mewsdh+Kiep+Bhd/bCFwxr Lygt22KUY/cHlS8/JjB9MPADqck1Uj8PsauU9WZcuZM0gFa+B7gA3fX0RoBWsten 8rm2k8TSo8am2im7yKjLFx+WXRkaNQ88VJXaiCT9hGQf67TOV2RD+6QjsPkGLZ7L BuTblYpF3NY5I1VpfwZYN41GACNEFTjGOg/LN2whnEkAY1udRIAbT+eX43yrvW5+ FKqpU1rZhGH6DlpeXtaluKYSJ/gFJWv3tvdqAxE1FDiDVprBAXPSAGqC0DfgYeUM cP0mUTkOmWf7i8XY3cUR46wndq7T1cmW/nGpQTv2o4fzloJ4fMAvPQ== =QhJl -END PGP SIGNATURE-
Bug#1003027: roundcube: XSS vulnerability via HTML messages with malicious CSS content
Package: roundcube Severity: important Tags: security Control: found -1 1.3.17+dfsg.1-1~deb10u1 Control: found -1 1.4.12+dfsg.1-1~deb11u1 Control: fixed -1 1.5.1+dfsg-1 In a recent post roundcube webmail upstream has announced a fix for a cross-site scripting (XSS) vulnerability via HTML messages with malicious CSS content. Upstream fix for the 1.4 LTS branch: https://github.com/roundcube/roundcubemail/commit/b2400a4b592e3094b6c84e6000d512f99ae0eed8 There was no new 1.3 LTS release but AFAICT 1.3 is affected as well and the same fix applies. -- Guilhem. [0] https://roundcube.net/news/2021/12/30/security-update-1.4.13-released https://roundcube.net/news/2021/12/30/update-1.5.2-released signature.asc Description: PGP signature
Bug#1001308: license clarification
thank you for your rfp, however there's this: Assets (graphics, levels, etc.) are available under Attribution-NonCommercial-ShareAlike 4.0 International therefore the game may not be sold without permission with these intact.
Bug#998485: gjiten: FTBFS: configure.in:8: error: AM_INIT_AUTOMAKE expanded multiple times
Hi Ludovic, are you still maintaining this package, or should it be moved to QA maintainance? The FTBFS is trivial to fix, but there is a point that someone should also upgrade to new upstream code (assuming the new upstream is usable). Thanks Adrian On Fri, Nov 05, 2021 at 11:59:03AM +0900, notebook wrote: > Hi, > > maybe it's a good chance to change to the new updated version of gjiten at > https://github.com/DarkTrick/gjiten > > The new version might also encounter packaging problems, but it uses more > recent technology and updates; It's probably more worthful to spend time > there than in the 10 year old package* > > > Regards > Chris - DarkTrick > > > * Yes, I'm trying to promote my updates here :)
Bug#1003037: astra-toolbox: FTBFS: error: parameter packs not expanded with '...'
Source: astra-toolbox Version: 1.8.3-10 Severity: serious Tags: ftbfs Justification: fails to build from source Hi, astra-toolbox recently started to FTBFS, probably due to some updated toolchain package or build dependency.: /usr/bin/nvcc -gencode=arch=compute_35,code=sm_35 -gencode=arch=compute_50,code=sm_50 -gencode=arch=compute_60,code=sm_60 -gencode=arch=compute_60,code=compute_60 -I../build/linux/../.. -I../build/linux/../../include -DASTRA_CUDA -c ../build/linux/../../cuda /3d/mem3d.cu -Xcompiler -fPIC -DPIC -o cuda/3d/.libs/mem3d.o /usr/include/c++/11/bits/std_function.h:435:145: error: parameter packs not expanded with '...': 435 | function(_Functor&& __f) | ^ /usr/include/c++/11/bits/std_function.h:435:145: note: '_ArgTypes' /usr/include/c++/11/bits/std_function.h:530:146: error: parameter packs not expanded with '...': 530 | operator=(_Functor&& __f) | ^ /usr/include/c++/11/bits/std_function.h:530:146: note: '_ArgTypes' make[2]: *** [Makefile:361: cuda/3d/mem3d.lo] Error 1 Andreas astra-toolbox_1.8.3-10.log.gz Description: application/gzip
Bug#1003038: mkfs.hfs does not respect the -v option when creating an HFS volume
Package: hfsprogs Version: 540.1.linux3-4 Hello Maintainers, Creating an HFS volume with a volume name other than the default of "untitled" is currently not possible. It does appear that it should be possible. Here is output exhibiting this issue: == # mkfs.hfs -b 512 -v 'grub' -h /tmp/hfs.img Initialized /tmp/hfs.img as a 5120 MB HFS volume # fsck.hfs /tmp/hfs.img ** /tmp/hfs.img Executing fsck_hfs (version 540.1-Linux). ** Checking HFS volume. The volume name is untitled ** Checking extents overflow file. ** Checking catalog file. ** Checking catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled appears to be OK. == Using -N to print the parameters shows that at least the option parsing allows this: == # mkfs.hfs -N -b 512b -v 'grub' -h /tmp/hfs.img 0 sectors at 512 bytes per sector HFS format parameters: volume name: "grub" block-size: 262144 total blocks: 20480 first free catalog node id: 16 initial catalog file size: 1048576 initial extents file size: 1048576 file clump size: 1048576 == Looking at the package source, I see that HFS volume creation is added as a debian package patch and not part of the upstream source in patch file debian/patches/0005-Re-add-support-for-creating-legacy-HFS-filesystems.patch. The issue appears to be that the volume name passed in as the -v option argument and being written to the hfs parameters struct is being unconditionally overritten in line 325 of the patch file with the default volume name. This can be fixed by swapping the first two aruments to bcopy on that line, however, the comment and the lines directly above it lead me to believe there's potentially more to it. This is causing GRUB HFS tests to fail and it would be nice to get them passing again without disabling the failing test. Thanks, Glenn
Bug#811294: ITP: tabview -- curses command-line CSV and list (tabular data) viewer
On Sun, 17 Jan 2016 18:55:20 +0100 Yuri D'Elia wrote: > Package: wnpp > Severity: wishlist > Owner: "Yuri D'Elia" > > * Package name: tabview > Version : 1.4.1 > Upstream Author : Scott Hansen > * URL : https://github.com/firecat53/tabview > * License : MIT > Programming Lang: Python > Description : curses command-line CSV and list (tabular data) viewer > > tabview is both a minimal, stand-alone curses command-line CSV/tabular-data > viewer and a Python module that can be used to view basic Python types > directly > in an interactive spreadsheet. > > The curses interface offers VIM-like keyboard bindings, sorting and full-text > incremental search. > > --- > > There are currently very few alternatives to tabview in debian. I've used "sc" > and "teapot" (not in Debian) to the same extent, however both are complete > spreadsheet programs (with sc requiring an extra "import" step), whereas > tabview allows to just view a csv/tsv file easily. > > tabview is both helpful stand-alone, but also works greatly when used in > combination with ipython or any interactive python session, allowing one to > browse through a large data table visually. To this extent, I'm using tabview > heavily with the scipy stack. > > I'm planning to maintain this package in the python-modules team. > > Hello! I see that you've done some work packaging this module in Debian already: https://salsa.debian.org/python-team/packages/tabview/ I'm currently packaging CleverCSV and tabview is an optional dependency. I was wondering if you were planning on finishing the work for tabview. For what it's worth, I'd be happy to mentor you and sponsor this package if you commit to maintaining it in Debian :) Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄ OpenPGP_signature Description: OpenPGP digital signature
Bug#1002910: fetchmail is not able to work with an imap server with TLS1.2 encryption
Am 02.01.22 um 16:07 schrieb Matthias Andree: > Am 02.01.22 um 14:03 schrieb Karsten: >> Am 02.01.22 um 12:15 schrieb Matthias Andree: I am the owner of the domain so nobody is hijacked! >>> Are you the owner of "mydomain.de" or of the unnamed domain you intended >>> not to show to the public? >> Do you want to help with this new certificate issue or discuss the ownership >> of domains? > > In this case, the latter. There are dedicated domain names for everyone > to use for documentation and test purposes, > https://datatracker.ietf.org/doc/html/rfc6761#section-6.5 Aha - O.K. >> With the search "install OpenSSL trust store" i could find this article: >> https://support.code42.com/CP/Admin/On-premises/6/Configuring/Use_OpenSSL_to_install_a_keystore >> that explains much of the stuff, but not how to use an self-signed >> certificate. > > https://unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list/ > but check the fine print and lower rated comments, too -- for recent > ca-certificates packages. Thank you - that is very helpful. > Basically you can install the self-signed certificate (if you or a > trusted party signed it, and you have transmitted it over a secure > channel, for instance, via SFTP or SCP) into the trust store (assuming > it suits both the TLS server and the signing CA roles - which was set > when you created it). Just for understanding - the installation is the public certificate of the server, or must be a special file derived from the private certificate? >> >> This worked for more then 5 years with TLS1.2 without any problem. >> Why this must be a problem now? > > Because "working" does not imply "working safely and securely". Yes - but the connection was still encrypted and not plain text. The connection was just not secure against all forms of attacks. >> Take the example Mozilla and please explain why it works without an "OpenSSL >> trust store" ? > > > Mozilla applications ship with their own trust store and do not use > OpenSSL, but incorporate their own TLS library called NSS. O.K. But how this helps to connect to a server with self-signed certificates? >> O.K. Then you have no request to this CA-servers for every connect to a >> server with a certificate, but every private >> server is registered there and every client will request the "trust" once to >> access the server. >> So you can made a profil who is using a server. That's the simple goal of it. > > > No, where does that access happen? The trust store is local to your > computer and fetchmail might use your system's DNS resolver (which can > have privacy implications) and will connect to the servers you point it to. First you send your certificate to the public CA to sign it. Then an client must connect the CA to proove that the public certificate is correct signed. Correct or wrong? > It uses OpenSSL's unless you override that (see man fetchmail for > --ssl... options). I promise to take the time to learn this part about using OpenSSL. > I understand, but too many variables involved and neither of us has time > for guesswork. I don't know how your CA (even if only implied for that > certificate) is set up or whatever else is needed, and I don't intend to > do consulting. I only used this silly OpenSSL command to generate the self-signed certificate and filled the questions OpenSSL asked. It should not be much more complicate to use a local trust store. > Figuratively speaking, you need to learn how to fish, not be given the fish. Fishing get's more and more complex. But it's true and i must learn it. >> When this is a standard procedure, why it is not possible to find existing >> examples how to handle it? >> Why it is still possible to fetch Data with TLS1.2 from the FTP-Server >> without similar problems? > > fetchmail doesn't do FTP, and FTP is being phased out because it's hard > to get right with its two connections, active/passive mode, > firewalls/NAT/conntrack, TLS being added afterwards and I guess it was > superseded by many other protocols that either tunnel through SSH or use > one TLS connection, for instance, DAV. That's the way i thought it is working. TLS is used to establish a secure encrypted connection and afterwards the rest is tunneled through it? Then it is not crucial how complex the protocol is. when two or more ports are needed then more secure connections must be established. > It is probably not about TLS version numbers anyways, but generally > tightened security. You upgraded the entire client system, and that > brought a lot of changes. > https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1 > might also be involved. I have to go through each different service that uses encryption, email, ftp, xmpp, etc. Maybe i will find a general better way to manage the certificates for encryption. Thank you for your invested time! karsten
Bug#1002738: Info received (Bug#1002738: redis-server: Default systemd unit file system protection settings prevent writing of logfiles, crashing redis)
Hi Johannes, > TLDR, if you want, feel free to close this ticket, I'll reopen it if > something changes downstream. Thanks for your mail. I'm happy to keep this bug open in case something comes up, but I'm not sure what I would do if we could definitively demonstrate a bug in Redis' unit file. That is to say, the only solution (whatever the cause might turn out to be) would seem to be to remove all of the hardening features from the unit file... hardly the right solution here. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1003011: xkb-data: character infinity bepo AFNOR variant
Package: xkb-data Version: 2.29-2 Severity: minor Dear Maintainer, the code for the character "∞" for the "French (Bepo, ergonomic, Dvorak way, AFNOR)" (line 630 in the file /usr/share/X11/xkb/symbols/fr) seems wrong. Should be U221E, not UFDD7. Regards. -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) 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
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: > How should I handle this? NMU to sid, let people try it out, and then > deal with buster/bullseye? Yeah, let's proceed with unstable first in any case. > Upload everything all at once? I'm also > going to try building for buster, unless the security team doesn't > think I should bother. I saw https://salsa.debian.org/dilinger/chromium/-/commit/5c05f430e192961527ec9a64bbaa64401dc14d95 , but buster now also includes LLVM/clang 11 (it was introduced to support a more recent Rust toolchain needed for Firefox), so you might be reduce complexity here further: https://tracker.debian.org/pkg/llvm-toolchain-11 It's in buster-proposed-updates since there hasn't been a point release since, but for the purposes of buster-security builds, it doesn't matter (they chroots have been modified to includen buster-proposed-updates temporarily): I'd say if it works out without additional overhead, let's also update buster-security, but it's also important not to overstretch the time/resources, so focusing on bullseye and EOLing buster is also an option for sure. Cheers, Moritz
Bug#1003024: ITP: libimage-scale-perl -- fast, high-quality fixed-point image resizing
Package: wnpp Severity: wishlist Owner: Paul Gevers X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libimage-scale-perl Version : 0.14 Upstream Author : Andy Grundman * URL : https://metacpan.org/release/Image-Scale * License : GPL2+ Programming Lang: Perl Description : fast, high-quality fixed-point image resizing Image::Scale implements several resizing algorithms with a focus on low overhead, speed and minimal features. Algorithms available are: GD's copyResampled (floating-point) GD's copyResampled fixed-point (useful on embedded devices/NAS devices) GraphicsMagick's assortment of resize filters (floating-point) GraphicsMagick's Triangle filter in fixed-point Supported image formats include JPEG, GIF, PNG, and BMP for input, and JPEG and PNG for output. This module came about because the need to improve the very slow performance of floating-point resizing algorithms on platforms without a floating-point unit, such as ARM devices like the SheevaPlug, and the Sparc-based ReadyNAS Duo. Previously it would take many seconds to resize using GD on the ReadyNAS but the conversion to fixed-point with a little assembly code brings this down to the range of well under 1 second. I intent to maintain this package under the Perl Team umbrella. This package is a dependency of Logitech Squeezebox which I also ITP.
Bug#1003026: linux-image-5.15.0-2-amd64: iwlwifi fails to initialize AX201 due to firmware error
Package: src:linux Version: 5.15.5-2 Severity: important Tags: upstream X-Debbugs-Cc: abhijithosk...@gmail.com On the 5.15 and newer kernels (I have tried 5.16-rc7 from experimental), iwlwifi fails to start up, complaining of a firmware error: 5.10.0 kernel works as expected. However, it loads iwlwifi-QuZ-a0-hr-b0-59.ucode. I attempted to force 5.15 to load the above, but that leads to the same result. Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: enabling device (0100 -> 0102) Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: firmware: failed to load iwlwifi-QuZ-a0-hr-b0-66.ucode (-2) Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-66.ucode failed with error -2 Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: firmware: failed to load iwlwifi-QuZ-a0-hr-b0-65.ucode (-2) Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-65.ucode failed with error -2 Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: firmware: failed to load iwlwifi-QuZ-a0-hr-b0-64.ucode (-2) Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: Direct firmware load for iwlwifi-QuZ-a0-hr-b0-64.ucode failed with error -2 Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: firmware: direct-loading firmware iwlwifi-QuZ-a0-hr-b0-63.ucode Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: api flags index 2 larger than supported by driver Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37 Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: loaded firmware version 63.c04f3485.0 QuZ-a0-hr-b0-63.ucode op_mode iwlmvm Jan 02 13:04:11 littlebox kernel: iwlwifi :00:14.3: firmware: failed to load iwl-debug-yoyo.bin (-2) Jan 02 13:04:12 littlebox kernel: iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6 AX201 160MHz, REV=0x354 Jan 02 13:04:12 littlebox kernel: iwlwifi :00:14.3: Detected RF HR B3, rfid=0x10a100 Jan 02 13:04:12 littlebox kernel: iwlwifi :00:14.3: base HW address: 64:79:f0:c8:dc:5a Jan 02 13:04:12 littlebox kernel: iwlwifi :00:14.3 wlo1: renamed from wlan0 ... Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: Microcode SW error detected. Restarting 0x0. Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: Start IWL Error Log Dump: Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: Transport status: 0x004B, valid: 6 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: Loaded firmware version: 63.c04f3485.0 QuZ-a0-hr-b0-63.ucode Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x0071 | NMI_INTERRUPT_UMAC_FATAL Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x22F0 | trm_hw_status0 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | trm_hw_status1 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x004CAD42 | branchlink2 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x004C2DBC | interruptlink1 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x004C2DBC | interruptlink2 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x004C2F1C | data1 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x1000 | data2 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | data3 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | beacon time Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x00025B0E | tsf low Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | tsf hi Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | time gp1 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x0002B8A5 | time gp2 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x0001 | uCode revision type Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x003F | uCode version major Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0xC04F3485 | uCode version minor Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x0351 | hw version Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x18C89004 | board version Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x8037FD22 | hcmd Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x0002 | isr0 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | isr1 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x08F04002 | isr2 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x00C37FCC | isr3 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | isr4 Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | last cmd Id Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x004C2F1C | wait_event Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | l2p_control Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x | l2p_duration Jan 02 13:04:14 littlebox kernel: iwlwifi :00:14.3: 0x |
Bug#715900: Bug fixed in fact!
https://gitee.com/huzheng/stardict-3.0.7/commit/d9d480bdae9c6a95df1662f4a4a34d9de57d78f4 = 不带参数运行这个程序啊！要有正确的输入！ = Hu Zheng 13017203...@139.com 电子名片新出VIP模板啦，快来体验>> 扫一扫, 快速添加名片到手机
Bug#1003009: notcurses FTBFS: notcurses-ffi exists in debian/tmp but is not installed to anywhere
Source: notcurses
Version: 3.0.3+dfsg.1-1
Severity: serious
Tags: ftbfs
https://buildd.debian.org/status/logs.php?pkg=notcurses=3.0.3%2Bdfsg.1-1
...
dh_missing -a -O--buildsystem=cmake
dh_missing: warning: usr/lib/x86_64-linux-gnu/libnotcurses-ffi.so exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/libnotcurses-ffi.so.3 exists in
debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/libnotcurses-ffi.so.3.0.3 exists
in debian/tmp but is not installed to anywhere
dh_missing: warning: usr/lib/x86_64-linux-gnu/pkgconfig/notcurses-ffi.pc exists
in debian/tmp but is not installed to anywhere
dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with
files per package)
* dh_install: libnotcurses++-dev (6), libnotcurses++3 (2),
libnotcurses-core-dev (45), libnotcurses-core3 (4), libnotcurses-dev (5),
libnotcurses3 (2), notcurses-bin (18), notcurses-data (10), python3-notcurses
(0)
* dh_installdocs: libnotcurses++-dev (0), libnotcurses++3 (0),
libnotcurses-core-dev (0), libnotcurses-core3 (0), libnotcurses-dev (0),
libnotcurses3 (0), notcurses-bin (0), notcurses-data (0), python3-notcurses (0)
* dh_installman: libnotcurses++-dev (0), libnotcurses++3 (0),
libnotcurses-core-dev (0), libnotcurses-core3 (0), libnotcurses-dev (0),
libnotcurses3 (0), notcurses-bin (0), notcurses-data (0), python3-notcurses (0)
If the missing files are installed by another tool, please file a bug
against it.
When filing the report, if the tool is not part of debhelper itself,
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide
for debhelper (10.6.3+).
(in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary
when only a subset is built
If the omission is intentional or no other helper can take care of this
consider adding the
paths to debian/not-installed.
Remember to be careful with paths containing "x86_64-linux-gnu", where
you might need to
use a wildcard or (assuming compat 13+) e.g. ${DEB_HOST_MULTIARCH} in
debian/not-installed
to ensure it works on all architectures (see #961104).
make: *** [debian/rules:14: binary-arch] Error 25
Bug#1003015: Makefile creates a symlink testing/buster -> unstable/sid, while it should be testing/bookworm -> unstable/sid
Package: debian-cd Version: 3.1.35 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The Makefile contains this code: # Make sure unstable/sid points to testing/buster, as there is no build # rule for unstable/sid. unstable-map: $(Q)if [ ! -d $(BASEDIR)/data/sid ] ; then \ ln -s buster $(BASEDIR)/data/sid ; \ fi $(Q)if [ ! -d $(BASEDIR)/tools/boot/sid ] ; then \ ln -s buster $(BASEDIR)/tools/boot/sid ; \ fi This clearly needs to be updated to "bookworm". Regards, Daniel - -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 debian-cd depends on: ii apt2.3.13 ii bc 1.07.1-3+b1 ii bzip2 1.0.8-5 ii cpp4:11.2.0-2 ii curl 7.80.0-3 ii dctrl-tools [grep-dctrl] 2.24-3+b1 ii dpkg-dev 1.21.1 ii genisoimage9:1.1.11-3.2 pn libcompress-zlib-perl pn libdigest-md5-perl ii libdpkg-perl 1.21.1 ii libfile-slurp-perl .32-1 ii libyaml-libyaml-perl 0.83+ds-1 ii lynx 2.9.0dev.10-1 ii make 4.3-4.1 ii perl [libdigest-sha-perl] 5.32.1-6 ii tofrodos 1.7.13+ds-5 ii wget 1.21.2-2+b1 ii xorriso1.5.4-2 Versions of packages debian-cd recommends: ii dosfstools 4.2-1 ii hfsutils 3.2.6-15 ii isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-3 ii mtools 4.0.33-1+really4.0.32-1 ii syslinux-common 3:6.04~git20190206.bf6db5b4+dfsg1-3 debian-cd suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmHR/eIACgkQS80FZ8KW 0F13VQ/+LLRXQP6vVxion6boTgg9LEEEnaUPHeprePLNoe5hA0S0wFnIyt3fU/w/ +/QVs4csEpZkLK397gAqR3/au5I/UGzW24lYwMwCtnRdZlwMeYnsRoQx1MPhWerb oX53/kfbesUDT8TOT3TZnNtZg2d2wZlH7+KUA6BrHjlRNFLxYrh7CBYzQ14CxVz0 pCxtyub1RQKUFGhfJ/Sv+C70sStiooECpMoLPmQhvC0XWoZU0E+ZJPkUJTFzeIvJ a3hclib2BNzFTTduPKG8SYgytfTyHKrkZx81J1s9955ZDEMxqoc+QnpuaNFqW2yJ dqyJorijFYki5rnw4p70zzWtX3VDaQkVxtrDPmTmKa9V+HB57/Vw7nk8Jw0KnKxC vdRWYH5WVobeNLdJ5rzgZRhlaeqf99DHFcUhTp7oK9kxheqxlnvKskGdCPvlG+2b ocIx7okMxTWRQYXuzUW0x6U+oQq+2hrTW8Ia9894APNswdsbYw6aNkAydWs2WsOs z/c1wE7M1WdDpYCTGLewIo6kdzaD5NXg4ACwZozJPRjjrdjWvEL/tX7QANbkHxbY G1TRv8I+sWb2uEYRqPEhBX6BA555QJo6srYUuzyYROG/fvOX3moR3AIVY8N+RWiU qKHt63FXf7ClQxY92tq3kpk+jmhIVEaGE2axZ+KBpx0dtcwny9s= =eDGz -END PGP SIGNATURE-
Bug#1002252: [Pkg-electronics-devel] Bug#1002252: pcb-rnd: FTBFS: dh_auto_test: error: make -j4 test VERBOSE=1 returned exit code 2
severity 1002252 important thanks Lucas Nussbaum writes: > During a rebuild of all packages in sid, your package failed to build > on amd64. It looks like noise from the latest librnd version is causing a pcb-rnd test failure. There is no operational bug in either the library or the application pcb-rnd. Upstream reports this is already fixed in their tree, and will apparently be in the next librnd release due in March. Upstream really hates when I pull patches out of his tree to make off-cycle updates, so unless this actually causes someone an operational problem with the existing binary packages, my intent is to just package the next librnd release as soon as possible. Bdale signature.asc Description: PGP signature
Bug#1003021: x11-utils: luit - please upgrade
Package: x11-utils Version: 7.7+5 Severity: normal Dear Maintainer, * The version of luit in x11-utils is very old, and its nominal upstream is defunct. https://lists.x.org/archives/xorg-devel/2018-August/057386.html See this for a summary of the relationship of "xorg luit" to luit: https://invisible-island.net/luit/#metrics * Prior discussion with the package maintainers had no effect. * To remedy the situation, I propose to a) modify x11-utils, making its copy of luit configurable via the alternatives feature (renaming it to "luit1", accessed as "luit") b) to provide an up-to-date package for luit as "luit2", also of course configurable via the alternatives feature. c) After some time, the copy in x11-utils can be replaced by a "recommends". Incidentally, doing this would fix #816289 The point of this bug report is to get feedback on "a" (modify x11-utils). -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages x11-utils depends on: ii libc6 2.33-1 ii libfontconfig1 2.13.1-4.2 ii libfontenc1 1:1.1.4-1 ii libgl1 1.3.4-2+b1 ii libx11-62:1.7.2-2+b1 ii libx11-xcb1 2:1.7.2-2+b1 ii libxaw7 2:1.0.13.1-20191125 ii libxcb-shape0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxext62:1.3.4-1 ii libxft2 2.3.2-2 ii libxi6 2:1.8-1 ii libxinerama12:1.1.4-2 ii libxkbfile1 1:1.1.0-1 ii libxmu6 2:1.1.2-2+b3 ii libxmuu12:1.1.2-2+b3 ii libxrandr2 2:1.5.2-1 ii libxrender1 1:0.9.10-1 hi libxt6 1:1.2.0-20190617 ii libxtst62:1.2.3-1 ii libxv1 2:1.0.11-1 ii libxxf86dga12:1.1.4-1+b3 ii libxxf86vm1 1:1.1.4-1+b2 x11-utils recommends no packages. Versions of packages x11-utils suggests: ii mesa-utils 8.4.0-1+b2 -- no debconf information
Bug#1003025: gr-iio prevents import of python3-libiio
Package: gr-iio Version: 0.3-9+b4 Severity: normal Dear Maintainer, The gr-iio package installs /usr/lib/python3/dist-packages/iio/__init__.py. As a result when any application evaluates import iio The above listed file is evaluated. However this is usually not what is intended. Instead most applications expect to evaluate the file /usr/lib/python3/dist-packages/iio.py installed by python3-libiio -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/6 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gr-iio depends on: ii libc6 2.31-13+deb11u2 ii libgcc-s1 10.2.1-6 ii libgnuradio-iio1 0.3-9+b4 ii libgnuradio-pmt3.8.2 3.8.2.0-14 ii libgnuradio-runtime3.8.2 3.8.2.0-14 ii liblog4cpp5v5 1.1.3-3 ii libpython3.9 3.9.2-1 ii libstdc++610.2.1-6 ii python3 3.9.2-3 gr-iio recommends no packages. gr-iio suggests no packages. -- no debconf information
Bug#1002992: sub...@bugs.debian.org
Made a new upload to mentors after syncing my git tree with salsa. Basically means that the VCS headers which was broken now should be OK --alec
Bug#967275: Bug#967582: libgtkdatabox: depends on deprecated GTK 2
Hi Graham, nice to hear all this! Klavaro is again linking against the library externally, from release 3.12, see: https://sourceforge.net/p/klavaro/news/2021/04/release-312/ Em dom., 2 de jan. de 2022 às 10:11, Graham Inggs escreveu: > Control: tags -1 + pending fixed-in-experimental > Control: block 967275 by -1 > Control: severity 967275 important > Control: block 967831 by -1 > Control: severity 967831 important > > Hi Felipe > > On Sun, 6 Jun 2021 at 23:42, Felipe Castro wrote: > > Hi, I'm the new upstream maintainer of GtkDatabox and we have released > version 1.0.0 this year, which depends now on GTK3, please update it on > Debian. > > The packages which depend on it are klavaro, xoscope and brp-pacu. > > From those, the only upstream which still depends on old gtkdatabox is > brp-pacu, but there is a fork which has done the upgrade to use the new > GTK3 version at GitHub, see: https://github.com/matthew-dews/brp-pacu > > The problem is that they have not released this new version yet, but I > could provide another fork and release, if that is the case. > > Thanks for your work on these packages! > > I've uploaded libtgkdatabox 1.0.0 to experimental. Once it clears NEW > [1], I will prepare uploads of xoscope and brp-pacu which I have > already tested. klavaro seems to be using an embedded copy of > libgtkdatabox. > > Regards > Graham > > > [1] https://ftp-master.debian.org/new.html >
Bug#1002979: FTBFS with camlp5 8.00.02
Dear Stéphane, Many thanks for this report. This link gives more details about this specific problem with the old geneweb 6.08: https://issueexplorer.com/issue/camlp5/camlp5/82 The solution would be to migrate to geneweb 7 (see also bug #986285 about the expected migration to geneweb 7). However, this will require a lot of time to implement & test, since geneweb 7 is very different from geneweb 6. As a result, geneweb might be removed from testing for some weeks or months following the landing of the new ocaml/camlp5 in unstable. With best regards, Guillaume Brochu Le dim. 2 janv. 2022 à 00:12, Stéphane Glondu a écrit : > Source: geneweb > Version: 6.08+git20181019+dfsg-3 > Severity: important > Tags: ftbfs > > Dear Maintainer, > > Your package FTBFS with camlp5 8.00.02 with the following error: > > camlp5r pa_extend.cmo q_MLast.cmo -o pa_macro5.ppo pa_macro5.ml > > File "pa_macro5.ml", line 162, characters 51-52: > > While expanding quotation "patt": > > Parse error: end of input expected after [patt] (in [patt_eoi]) > > This was discovered while preparing the transition to OCaml 4.13.1. > > Packages rebuilt with OCaml 4.13.1 are available at: > > https://ocaml.debian.net/transitions/ocaml-4.13.1/ > > > Cheers, > > -- > Stéphane > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) > 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 >
Bug#978040: Warning: (9034) "crtbeginS.o" not found (on non-intel architectures)
Hi,
On 02-01-2022 14:29, Abou Al Montacir wrote:
If you check on a porter box for ARM or power PC, you will find only arm
or ppc related ifdefs.
So it works for all architectures, but not multiarch.
Isn't multiarch only properly working on some combinations anyways? E.g.
i386 can be multiarch on an amd64 capable computer. And armhf (and
sometimes armel) can be multiarch on (most) arm64 capable hosts? I
understood not all combinations currently (or ever) make sense.
I just checked the configuration on armhf and there wasn't a path to gcc
in the configuration. Shortly after I realized that's probably because
gcc wasn't installed. So while I checked armel, I installed gcc
alongside and after dpkg-reconfigure I got this on armel:
"""
#ifdef cpuaarch64
-Fl/usr/lib/gcc/arm-linux-gnueabi/11
#endif
"""
The cpuaarch64 bit part doesn't look correct, maybe that's because this
is inside an lxc on an arm64 host, so maybe the detection goes wrong.
And then on armel I got:
#ifdef cpuaarch64
-Fl/usr/lib/gcc/arm-linux-gnueabihf/11
#endif
On arm64
#ifdef cpuaarch64
-Fl/usr/lib/gcc/aarch64-linux-gnu/11
#endif
If we can safely suppose that all Debian architectures are using the
very same GCC version and path, then we can remove the ifdef and have a
generic path that works for mutiarch with a minimal effort.
But shouldn't the path depend on for which architecture your building?
However, it is true that if a new gcc version is installed after FPC
then the logic will fall down.
Can't we use a wildcard for the version number? I mean, after 11 comes
12 and 13 and ...
The wildcards work but only for one directory level. This means
/path/to/* and /path/to/prefix* will work, but not /path/to/*/* or
/path/to/prefix*/*
Ack.
If this is judged OK, I propose to close this ticket
As long as we have a new fpc in every Debian release, we're fine in
Debian, but e.g. Ubuntu users may experience issues when they carry the
same fpc over to a new version of Ubuntu that comes with a new gcc
version. So I don't think it's nice.
If we can add a trigger then we can run dpkg-reconfigure
fp-compiler-${VERSION} and get it updated.
I'm not sure your allowed to run dpkg-reconfigure on a trigger as that
requires admin interaction. That sounds weird. As an admin I wouldn't
expect my configuration to get updated (when installing an "unrelated"
package). And we would want to have a trigger on gcc upgrade? I don't
know how triggers work exactly, but wouldn't gcc need to provide the
trigger then?
Paul
OpenPGP_signature
Description: OpenPGP digital signature
Bug#715859: Bug fixed!
Control: tags -1 pending Thanks you for fix this bug in upstream! 在 2022/1/2 16:14, Hu Zheng 写道: See: https://gitee.com/huzheng/stardict-3.0.7/commit/d9d480bdae9c6a95df1662f4a4a34d9de57d78f4 Hu Zheng 13017203...@139.com 电子名片新出VIP模板啦，快来体验>> 扫描二维码添加名片到手机 扫一扫, 快速添加名片到手机 -- 肖盛文 xiao sheng wen Faris Xiao 微信(wechat)：atzlinux 《铜豌豆 Linux》https://www.atzlinux.com 基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page:https://qa.debian.org/developer.php?login=atzlinux%40sina.com GnuPG Public Key: 0x00186602339240CB OpenPGP_0x00186602339240CB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1002975: capnproto: please migrate capnproto 0.8.0 from experimental to unstable -> testing
On Sat, Jan 01, 2022 at 05:12:15PM -0800, tony mancill wrote: Transition request is #1003004. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003004
Bug#995212: chromium: Update to version 94.0.4606.61 (security-fixes)
On Sat, Jan 01, 2022 at 01:23:09PM -0500, Andres Salomon wrote: > > I've got 96.0.4664.110 building on both bullseye and sid Trying it, I see it still build-depends on python-jinja2. That package is now gone, so it's not actually buildable in sid anymore. Correlated, do you know how long do they plan on keeping using python2? That's plainly unsuitable, it really is not going to last much longer in debian. > > the v96 branch of https://salsa.debian.org/dilinger/chromium FWIW, I'm trying to build it myself as well (after injecting an old python-jinja2 and an old python-markupsafe). > Alright, crashes are solved and the packages are now usable. After some > cleanups (listing CVEs in changelogs, This doesn't seem to be done as of the current tip of you v96 branch. > merging/pushing a bunch of > commits in my branch, possibly dropping strong stack protection from > builds to silence warnings from older clang versions, and going through > lintian errors/warnings), it should be ready to upload. TBH, I don't think I am able to judge the appropriateness of most of those changes... Though I suspect I could close most of my eyes and upload it to unstable: can't be much worse than what we have... > How should I handle this? NMU to sid, let people try it out, and then > deal with buster/bullseye? Upload everything all at once? Procedure would be NMU to unstable first, IMHO. > I also haven't heard from anyone on the chromium team yet - should I > add myself as an uploader and do a normal (non-NMU) upload? Do any of > them care? Without hearing from them, adding yourself to Uploaders would be inappropriate. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#959407: Not needed for Debian Python Packages
We now have a more general solution for PEP 517/518 (and PEP 621) based packages in pybuild using a different approach. This package is not needed to support Deiban Python package building. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1000572: fix
This is now fixed in the master branch https://github.com/faiproject/fai/commit/2726525da7fbcd73ff5e949516890fa80ffb6783 -- viele Grüße Thomas
Bug#1003029: xboxdrv: FTBFS with SCons 4.2.0+
Source: xboxdrv
Version: 0.8.8-2
Severity: important
Tags: patch
Hi,
SCons 4.3.0 was released some time ago. I've packaged it and would
like to upload it in the next day or so. Your package FTBFS with that,
for which a patch is attached to fix it.
Regards,
Laszlo/GCS
Description: SCons 4.2.0 no longer has env.has_key()
Check env as an array.
Author: Laszlo Boszormenyi (GCS)
Forwarded: no
Last-Update: 2022-01-02
---
--- xboxdrv-0.8.8.orig/SConstruct
+++ xboxdrv-0.8.8/SConstruct
@@ -41,7 +41,7 @@ def build_bin2h(target, source, env):
with open(target[0].get_path(), "w") as fout:
fout.write("// autogenerated by scons Bin2H builder, do not edit by hand!\n\n")
-if env.has_key("BIN2H_NAMESPACE"):
+if "BIN2H_NAMESPACE" in env:
fout.write("namespace %s {\n\n" % env["BIN2H_NAMESPACE"])
# write down data
@@ -67,7 +67,7 @@ def build_bin2h(target, source, env):
for src in source], ",\n"))
fout.write("\n}\n\n")
-if env.has_key("BIN2H_NAMESPACE"):
+if "BIN2H_NAMESPACE" in env:
fout.write("} // namespace %s\n\n" % env["BIN2H_NAMESPACE"])
fout.write("/* EOF */\n")
Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1
Package: elpa-org Version: 9.5.2+dfsh-1 Followup-For: Bug #1002982 Dear Maintainer, After installation, org-version.el is missing (not auto-generated ?) in /usr/share/emacs/site-lisp/elpa-src/org-9.5.2/ and soft-linked in /usr/share/emacs/site-lisp/elpa/org-9.5.2/ Then the elpa-org 9.5.2 loads the org-version.el from default org 9.3 from emacs 27.1 ( /usr/share/emacs/27.1/lisp/org/org-version.el ) To reproduce the loading of the wrong file: emacs -q then in emacs M-x org-reload give the following message: Successfully reloaded Org Org mode version N/A (N/A !!check installation!! @ /usr/share/emacs/site-lisp/elpa/org-9.5.2/) The full text of the *Messages* buffer at the org-reload execution. Note the directory of the loading of org-version (last previous last loading) Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-comint...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-core...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-emacs-lisp...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-eval...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-exp...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-lob...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-ref...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-table...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-tangle...done Loading /usr/share/emacs/27.1/lisp/obarray...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-compat...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-entities...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-faces...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-footnote...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-keys...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-list...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-macro...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-macs...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-pcomplete...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-src...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-table...done Loading /usr/share/emacs/27.1/lisp/org/org-version.el (source)...done Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org...done The following features were found in load-path, please check if that’s correct: (obarray org-version) Successfully reloaded Org Org mode version N/A (N/A !!check installation!! @ /usr/share/emacs/site-lisp/elpa/org-9.5.2/) *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-org depends on: ii dh-elpa-helper 2.0.10 ii elpa-htmlize1.56-1 ii emacsen-common 3.0.4 Versions of packages elpa-org recommends: ii emacs 1:27.1+1-3.1 ii emacs-gtk [emacs] 1:27.1+1-3.1+b1 Versions of packages elpa-org suggests: ii ditaa 0.10+ds1-1.2 ii org-mode-doc 9.4.0-2 ii texinfo6.8-3 ii texlive-fonts-recommended 2021.20211217-1 ii texlive-latex-extra2021.20211217-1 -- debconf-show failed
Bug#712979: debbugs: get_bug_log can incorrectly return an e-mail body with xsi:type="xsd:long"
On Sun, 02 Jan 2022, Bastian Venthur wrote: > On 01.01.22 22:05, Don Armstrong wrote: > > I'm currently working on it, but my available time is so minimal, > > that additional help would be welcome. > > Awesome news! Is there some repository to check out? I'd love to help if I > can. Not publicly yet; I need to get more of the architecture in place before it can be reasonably collaborated on. But I hope to have it in a place that others can collaborate with me in the next 6 months or so. -- Don Armstrong https://www.donarmstrong.com Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rükert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_]
Bug#1003034: ITP: obs-scene-collection-manager -- plugin for OBS Studio to generate sets of scenes
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho X-Debbugs-Cc: debian-de...@lists.debian.org, Exeldro * Package name: obs-scene-collection-manager Version : 0.0.2 Upstream Author : Exeldro * URL : https://obsproject.com/forum/resources/scene-collection-manager.1434/ * License : GPL-2 Programming Lang: C++ Description : plugin for OBS Studio to generate sets of scenes This plugin allows the user to generate several sets of scenes to use in different scenarios. To choose and use a set of scenes, just click over a name in a menu. Also is possible to filter, backup and restore scene collections. . The Scene Collection Manager will appear on the main menu and on the Tools menu when installed. . This plugin is compatible with OBS 26 or higher.
Bug#715900: Bug fixed!
在 2022/1/2 16:21, Hu Zheng 写道: See: https://gitee.com/huzheng/stardict-3.0.7/commit/d9d480bdae9c6a95df1662f4a4a34d9de57d78f4 The bug still partly exist: atzlinux@debian:/tmp/ec50-report/crash$ /usr/lib/stardict-tools/fest2dict asdfasd Segmentation fault atzlinux@debian:/tmp/ec50-report/crash$ echo $? 139 This is fixed: atzlinux@debian:/tmp/ec50-report/crash$ echo asdasdf > /tmp/a atzlinux@debian:/tmp/ec50-report/crash$ /usr/lib/stardict-tools/fest2dict /tmp/a atzlinux@debian:/tmp/ec50-report/crash$ echo $? 0 also see: https://gitee.com/huzheng/stardict-3.0.7/commit/d9d480bdae9c6a95df1662f4a4a34d9de57d78f4#note_8137981 OpenPGP_0x00186602339240CB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1002591: misdetects socket activated ssh
On Sun, Jan 02, 2022 at 09:25:49PM +0100, Thomas Liske wrote: > Looks like a systemd/cgroup related change in bullseye, buster seems > not to be affected. That sounds correct, I had attributed this behavior to some ssh updates in the past. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#998383: nheko: nheko/{armel,armhf} has unsatisfiable dependency
On Wed, 3 Nov 2021 14:25:41 +0200 Adrian Bunk wrote: Control: reassign -1 src:gst-plugins-good1.0 1.18.5-1 Control: retitle -1 gstreamer1.0-qt5 should again be built on armel/armhf Control: affects -1 nheko On Wed, Nov 03, 2021 at 12:03:20PM +0100, Sebastian Ramacher wrote: > Source: nheko > Version: 0.8.2-2 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > > nheko fails to migrate to testing since it depends on gstreamer1.0-qt5. > This package is not available on armel and armhf. With #894076 fixed, gstreamer1.0-qt5 builds again on armel/armhf. I'll submit a MR for that. Hi Adrian, Any progress on this topic? Thanks, _g. OpenPGP_signature Description: OpenPGP digital signature
Bug#1003008: Error 134633601: Error while parsing number"
Control: severity -1 critical On Sun, Jan 02, 2022 at 09:14:54PM +0300, Eugene Berdnikov wrote: > After upgrade grub-legacy from 0.97-78 to 0.97-79 installation fails > with message "Error 134633601: Error while parsing number": > > - > grub> root (hd0,0) > root (hd0,0) > Filesystem type is ext2fs, partition type 0x8065e03 > grub> setup (hd0) > setup (hd0) > Checking if "/boot/grub/stage1" exists... no > Checking if "/grub/stage1" exists... yes > Checking if "/grub/stage2" exists... yes > Checking if "/grub/e2fs_stage1_5" exists... yes > Running "embed /grub/e2fs_stage1_5 (hd-141250989)"... failed (this is not > fatal) > Running "embed /grub/e2fs_stage1_5 (hd-141250989,-"... failed (this is not > fatal) > Running "install /grub/stage1 (hd-141250989) /grub/stage2 p /grub/menu.lst > "... failed > > Error 134633601: Error while parsing number > - > > Observed on all updated hosts (about ten in my own). Rollback to 0.97-78 > resolves the problem (with the same config files). Ugh, sorry about this. I didn't actually change any patches against the upstream code in 0.97-79, so this must have been broken by the mere act of rebuilding it, I think. I'll see if I can construct a suitable test environment. -- Colin Watson (he/him) [cjwat...@debian.org]
Bug#1003040: ITP: asdf-astropy -- ASDF serialization support for astropy
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, debian-as...@lists.debian.org * Package name: asdf-astropy Version : 0.1.2 Upstream Author : The ASDF Developers * URL : https://github.com/astropy/asdf-astropy * License : BSD-3-Clause Programming Lang: Python Description : ASDF serialization support for astropy This package includes plugins that provide ASDF serialization support for astropy objects. The plugins are automatically enabled when the package is installed. ASDF (Advanced Scientific Data Format) is a proposed next generation interchange format for scientific data, mainly used by the Space Telescope Science Institude (STScI). It is a new build dependency of the gwcs package. I will maintain it within the Debian Astro team in Salsa: https://salsa.debian.org/debian-astro-team/asdf-astropy Best regards Ole
Bug#1003041: krita: Krita 4.4.2 on bullseye crashes most of the time when I try to apply filters on a transparency layer.
Package: krita Version: 1:4.4.2+dfsg-1: amd64 Dear Maintainer, Krita 4.4.2 on Bullseye crashes most of the time when I try to apply Gaussian Blur or any other filter on a transparency mask unless I disable the preview option. It happens when I try to apply other filters as well. I have tested it by installing Krita on a fresh Debian Bullseye on a virtual machine as well and it happens there as well. Here is the console output of Krita when the crash occurs. safi@safi-pc:~$ krita (process:12176): Gtk-WARNING **: 12:27:33.157: Locale not supported by C library. Using the fallback 'C' locale. Invalid profile : "/usr/share/color/icc/colord/Crayons.icc" "Crayon Colors" Invalid profile : "/usr/share/color/icc/colord/x11-colors.icc" "X11 Colors" Could not set current file 0 "brushes/rake_sparse.png" krita.general: Bundle is broken. File "brushes/rake_sparse.png" is missing Could not set current file 0 "brushes/rock_pitted.gih" krita.general: Bundle is broken. File "brushes/rock_pitted.gih" is missing Could not set current file 0 "brushes/square_rough.png" krita.general: Bundle is broken. File "brushes/square_rough.png" is missing krita.general: Due to missing files and wrong entries in the manifest, "/usr/share/krita/bundles/RGBA_brushes.bundle" will be recreated. QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/Craig_02.png" 0 krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/DA_RGBA bluegreen_small.png" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/DA_RGBA bluegreen_small1.png" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/DA_Triangle grain.png" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/Mountain_Brush_01.png" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "brushes/RGBA anim 01.gih" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing Could not set current file 0 "brushes/rake_sparse.png" Could not set current file 0 "brushes/rock_pitted.gih" Could not set current file 0 "brushes/square_rough.png" QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_01_Thick-dry.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_02_Thickpaint.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_03_Rake.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_04_Impasto.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_05_Impasto-details.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "paintoppresets/m)_RGBA_06_Rock.kpp" 0 QBuffer::setBuffer: Buffer is open krita.lib.store: KoStore: You must open before writing krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "preview.png" 0 QBuffer::setBuffer: Buffer is open krita.general: Could not open preview.png krita.lib.store: KoStore: You must open before writing krita.general: Could not write preview.png krita.lib.store: You must open before closing QuaZipFile::open(): file open mode 2 incompatible with ZIP open mode 0 Could not open "META-INF/manifest.xml" 0
Bug#990128: libcurl4-gnutls-dev: Un-installable in multiarch environment again in version 7.80.0-3: /usr/bin/curl-config differs
Hello,
a quite similar bug has been reintroduced in version 7.80.0-3 of
libcurl4-gnutls-dev:
The package is again unistallable in multiarch environments due to
differences in libcurl4-gnutls-dev. This time, it is the -L linker
options that contain the architecture triplet (e.g. amd64-linux-gnu, see
attached diff file).
Should this new difference in curl-config be handled by re-opening this
bug report or should I create a new one?
Best regards
Michael Schmeing
--
Michael Schmeing
Kahlhorststraße 36A
23562 Lübeck
E-Mail: mich...@michael-schmeing.de
Tel.: +49 451 30406604
Mobil: +49 176 22961510
--- amd64/usr/bin/curl-config 2021-12-26 17:22:18.0 +0100
+++ i386/usr/bin/curl-config 2021-12-26 17:22:18.0 +0100
@@ -152,7 +152,7 @@
--libs)
CURLLIBDIR=""
if test "Xyes" = "Xno"; then
- echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lrtmp -lssh2 -lssh2 -lpsl -lnettle -lgnutls -L/usr/lib/x86_64-linux-gnu/mit-krb5 -lgssapi_krb5 -llber -lldap -llber -lzstd -lbrotlidec -lz -pthread
+ echo ${CURLLIBDIR}-lcurl -lnghttp2 -lidn2 -lrtmp -lssh2 -lssh2 -lpsl -lnettle -lgnutls -L/usr/lib/i386-linux-gnu/mit-krb5 -lgssapi_krb5 -llber -lldap -llber -lzstd -lbrotlidec -lz -pthread
else
echo ${CURLLIBDIR}-lcurl
fi
@@ -163,7 +163,7 @@
--static-libs)
if test "Xyes" != "Xno" ; then
- echo -Wl,-Bstatic -lcurl -Wl,-Bdynamic -Wl,-z,relro -Wl,-z,now -lnghttp2 -lidn2 -lrtmp -lssh2 -lssh2 -lpsl -lnettle -lgnutls -L/usr/lib/x86_64-linux-gnu/mit-krb5 -lgssapi_krb5 -llber -lldap -llber -lzstd -lbrotlidec -lz -pthread
+ echo -Wl,-Bstatic -lcurl -Wl,-Bdynamic -Wl,-z,relro -Wl,-z,now -lnghttp2 -lidn2 -lrtmp -lssh2 -lssh2 -lpsl -lnettle -lgnutls -L/usr/lib/i386-linux-gnu/mit-krb5 -lgssapi_krb5 -llber -lldap -llber -lzstd -lbrotlidec -lz -pthread
else
echo "curl was built with static libraries disabled" >&2
exit 1
Bug#1003039: node-terser: Please update node-commander dependency to version 8
Package: node-terser
Version: 4.1.2-9
Severity: important
Tags: patch
Hi,
node-commander 8 changed option parsing. Here is a proposed patch to be
used in replacement of 1001_use_commander_4.patch
Description: support node module commander release 8
same patch than uglifyjs
Author: Yadd
Forwarded: no
Last-Update: 2022-01-03
--- a/bin/uglifyjs
+++ b/bin/uglifyjs
@@ -28,6 +28,15 @@
program.version(info.name + " " + info.version);
program.parseArgv = program.parse;
program.parse = undefined;
+var argv = [];
+process.argv.forEach(function(arg){
+ if(arg.match(/^-([pcmbode]+)$/)) {
+argv = argv.concat(RegExp.$1.split('').map(s => { return '-'+s }));
+ }
+ else argv.push(arg);
+});
+process.argv = argv;
+
if (process.argv.includes("ast")) program.helpInformation = describe_ast;
else if (process.argv.includes("options")) program.helpInformation =
function() {
var text = [];
@@ -65,10 +74,11 @@
program.option("--warn", "Print warning messages.");
program.option("--wrap ", "Embed everything as a function with “exports”
corresponding to “name” globally.");
program.arguments("[files...]").parseArgv(process.argv);
-if (program.configFile) {
-options = JSON.parse(read_file(program.configFile));
+const opts = program.opts();
+if (opts.configFile) {
+options = JSON.parse(read_file(opts.configFile));
}
-if (!program.output && program.sourceMap && program.sourceMap.url != "inline")
{
+if (!opts.output && opts.sourceMap && opts.sourceMap.url != "inline") {
fatal("ERROR: cannot write source map to STDOUT");
}
[
@@ -82,83 +92,83 @@
"toplevel",
"wrap"
].forEach(function(name) {
-if (name in program) {
-options[name] = program[name];
+if (name in opts) {
+options[name] = opts[name];
}
});
-if ("ecma" in program) {
-if (program.ecma != (program.ecma | 0)) fatal("ERROR: ecma must be an
integer");
-options.ecma = program.ecma | 0;
+if ("ecma" in opts) {
+if (opts.ecma != (opts.ecma | 0)) fatal("ERROR: ecma must be an integer");
+options.ecma = opts.ecma | 0;
}
-if (program.beautify) {
-options.output = typeof program.beautify == "object" ? program.beautify :
{};
+if (opts.beautify) {
+options.output = typeof opts.beautify == "object" ? opts.beautify : {};
if (!("beautify" in options.output)) {
options.output.beautify = true;
}
}
-if (program.comments) {
+if (opts.comments) {
if (typeof options.output != "object") options.output = {};
-options.output.comments = typeof program.comments == "string" ?
program.comments : "some";
+options.output.comments = typeof opts.comments == "string" ? opts.comments
: "some";
}
-if (program.define) {
+if (opts.define) {
if (typeof options.compress != "object") options.compress = {};
if (typeof options.compress.global_defs != "object")
options.compress.global_defs = {};
-for (var expr in program.define) {
-options.compress.global_defs[expr] = program.define[expr];
+for (var expr in opts.define) {
+options.compress.global_defs[expr] = opts.define[expr];
}
}
-if (program.keepClassnames) {
+if (opts.keepClassnames) {
options.keep_classnames = true;
}
-if (program.keepFnames) {
+if (opts.keepFnames) {
options.keep_fnames = true;
}
-if (program.mangleProps) {
-if (program.mangleProps.domprops) {
-delete program.mangleProps.domprops;
+if (opts.mangleProps) {
+if (opts.mangleProps.domprops) {
+delete opts.mangleProps.domprops;
} else {
-if (typeof program.mangleProps != "object") program.mangleProps = {};
-if (!Array.isArray(program.mangleProps.reserved))
program.mangleProps.reserved = [];
+if (typeof opts.mangleProps != "object") opts.mangleProps = {};
+if (!Array.isArray(opts.mangleProps.reserved))
opts.mangleProps.reserved = [];
}
if (typeof options.mangle != "object") options.mangle = {};
-options.mangle.properties = program.mangleProps;
+options.mangle.properties = opts.mangleProps;
}
-if (program.nameCache) {
-options.nameCache = JSON.parse(read_file(program.nameCache, "{}"));
+if (opts.nameCache) {
+options.nameCache = JSON.parse(read_file(opts.nameCache, "{}"));
}
-if (program.output == "ast") {
+if (opts.output == "ast") {
options.output = {
ast: true,
code: false
};
}
-if (program.parse) {
-if (!program.parse.acorn && !program.parse.spidermonkey) {
-options.parse = program.parse;
-} else if (program.sourceMap && program.sourceMap.content == "inline") {
+if (opts.parse) {
+if (!opts.parse.acorn && !opts.parse.spidermonkey) {
+options.parse = opts.parse;
+} else if (opts.sourceMap && opts.sourceMap.content == "inline") {
fatal("ERROR: inline source map only works with built-in parser");
}
}
if (~program.rawArgs.indexOf("--rename")) {
options.rename = true;
-} else if (!program.rename) {
+} else if (!opts.rename) {
Bug#1003004: transition: capnproto
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi Release Team, capnproto 0.8.0 has been in experimental for over a year now [1], so there is already an auto-transition page [2]. All of the reverse dependencies *except* for clickhouse should smoothly. clickhouse [3] is FTBFS against 0.8.0, but the package has already been removed from testing due to FTBFS against gcc 11 [4]. Given that clickhouse isn't receiving much attention and we have received requests to update captnproto, we would like to proceed with the transition. Thank you, tony [1] https://tracker.debian.org/pkg/capnproto [2] https://release.debian.org/transitions/html/auto-capnproto.html [3] https://tracker.debian.org/pkg/clickhouse [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996130 Ben file: title = "capnproto"; is_affected = .depends ~ "libcapnp-0.7.0" | .depends ~ "libcapnp-0.8.0"; is_good = .depends ~ "libcapnp-0.8.0"; is_bad = .depends ~ "libcapnp-0.7.0"; signature.asc Description: PGP signature
Bug#916749: systemd-cron: Tries to launch unreachable commands
control: reassign -1 dma Hi, This looks more like normal behaviour. tchet@brix ~ $ [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1 tchet@brix ~ $ echo $? 1 The crontab should maybe have been written this way, to always return "true". [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1 || true I'm assigningg the bug to "dma". dma maintainers can close it if they feel so. Greetings, Package: systemd-cron Version: 1.5.14-2 Severity: important Dear Maintainer, I just switched from cron to systemd cron. I now have every 5 mintes following email : * cron-dma-root-0.service - [Cron] "*/5 * * * * root [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1" Loaded: loaded (/etc/cron.d/dma; generated) Active: failed (Result: exit-code) since Tue 2018-12-18 09:10:03 CET; 74ms ago Docs: man:systemd-crontab-generator(8) Process: 8569 ExecStart=/bin/sh /run/systemd/generator/cron-dma-root-0.sh (code=exited, status=1/FAILURE) Main PID: 8569 (code=exited, status=1/FAILURE) Dec 18 09:10:03 ot-fixe-008 systemd[1]: Starting [Cron] "*/5 * * * * root [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1"... Dec 18 09:10:03 ot-fixe-008 systemd[1]: cron-dma-root-0.service: Main process exited, code=exited, status=1/FAILURE Dec 18 09:10:03 ot-fixe-008 systemd[1]: cron-dma-root-0.service: Failed with result 'exit-code'. Dec 18 09:10:03 ot-fixe-008 systemd[1]: Failed to start [Cron] "*/5 * * * * root [ -x /usr/sbin/dma ] && /usr/sbin/dma -q1". Dec 18 09:10:03 ot-fixe-008 systemd[1]: cron-dma-root-0.service: Triggering OnFailure= dependencies. /usr/sbin/dma does not exist, thus the action should not be executed.
Bug#1003007: libvirt-php FTBFS with PHP 8.1
Source: libvirt-php Version: 0.5.5-3 Severity: serious Tags: ftbfs bookworm sid https://buildd.debian.org/status/fetch.php?pkg=libvirt-php=amd64=0.5.5-3%2Bb1=1641147267=0 ... In file included from ../../src/libvirt-php.c:19: ../../src/libvirt-php.h:161:26: error: expected ‘;’, ‘,’ or ‘)’ before ‘TSRMLS_DC’ 161 | void set_error(char *msg TSRMLS_DC); | ^ ../../src/libvirt-php.h:162:35: error: expected ‘;’, ‘,’ or ‘)’ before ‘TSRMLS_DC’ 162 | void set_error_if_unset(char *msg TSRMLS_DC); | ^ ../../src/libvirt-php.h:163:1: warning: parameter names (without types) in function declaration 163 | void reset_error(TSRMLS_D); | ^~~~ ...
