Bug#1014539: squirrel3: CVE-2022-30292
Hello,
Matthias Geiger wrote on 07/05/2024 at 00:05:36+0200:
> On Thu, 18 Apr 2024 14:40:58 +0200 Matthias Geiger
> wrote:
>
>>
>> //I have prepared a fix; however this needs the FTBFS in #997441
>> adressed first.
>>
>> Will attach a debdiff once that has happened.
>>
>
> See attachement.
>
> best,
I've uploaded this debdiff in DELAYED/7.
Please reach out if there's any issue.
Bests,
--
PEB
diff -Nru squirrel3-3.1/debian/changelog squirrel3-3.1/debian/changelog
--- squirrel3-3.1/debian/changelog 2024-04-29 23:39:09.0 +0200
+++ squirrel3-3.1/debian/changelog 2024-05-13 14:59:34.0 +0200
@@ -1,3 +1,11 @@
+squirrel3 (3.1-8.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Cherry-pick upstream commit as 03-fix-buffer-overflow.diff
+Closes: #1014539, CVE-2022-30292
+
+ -- Matthias Geiger Mon, 13 May 2024 14:59:34 +0200
+
squirrel3 (3.1-8.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff
--- squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff 1970-01-01 01:00:00.0 +0100
+++ squirrel3-3.1/debian/patches/03-fix-buffer-overflow.diff 2024-05-13 14:59:20.0 +0200
@@ -0,0 +1,22 @@
+From a6413aa690e0bdfef648c68693349a7b878fe60d Mon Sep 17 00:00:00 2001
+From: Alberto Demichelis
+Date: Mon, 2 May 2022 12:04:58 +0200
+Subject: [PATCH] fix in thread.call
+
+---
+ squirrel/sqbaselib.cpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/squirrel/sqbaselib.cpp b/squirrel/sqbaselib.cpp
+index 662aeac..e283900 100644
+--- a/squirrel/sqbaselib.cpp
b/squirrel/sqbaselib.cpp
+@@ -1012,6 +1012,7 @@ static SQInteger thread_call(HSQUIRRELVM v)
+ SQObjectPtr o = stack_get(v,1);
+ if(type(o) == OT_THREAD) {
+ SQInteger nparams = sq_gettop(v);
++sq_reservestack(_thread(o), nparams + 3);
+ _thread(o)->Push(_thread(o)->_roottable);
+ for(SQInteger i = 2; i<(nparams+1); i++)
+ sq_move(_thread(o),v,i);
+
diff -Nru squirrel3-3.1/debian/patches/series squirrel3-3.1/debian/patches/series
--- squirrel3-3.1/debian/patches/series 2024-04-29 23:33:43.0 +0200
+++ squirrel3-3.1/debian/patches/series 2024-05-13 14:59:20.0 +0200
@@ -1,2 +1,3 @@
01-fix-spelling-errors.patch
02-sphinx-ext.patch
+03-fix-buffer-overflow.diff
signature.asc
Description: PGP signature
Bug#997441: squirrel3: FTBFS: '! LaTeX Error: File `tgtermes.sty' not found.'
Hi, Thanks for the patch. Fabian, I uploaded the NMU with a 7 days delay. Reach out if you see a good reason to either cancel or delay further this NMU. Bests, -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. From e054c7aa6fdd402ab63709e15103aab1f50e6119 Mon Sep 17 00:00:00 2001 From: Matthias Geiger Date: Mon, 29 Apr 2024 23:38:16 +0200 Subject: [PATCH 1/2] Fix watch file to look for Github tags instead of releases --- debian/changelog | 7 +++ debian/watch | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 592b24f..c303908 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +squirrel3 (3.1-8.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix watch file to look for Github tags instead of releases + + -- Matthias Geiger Fri, 16 Feb 2024 17:46:43 +0100 + squirrel3 (3.1-8) unstable; urgency=medium * Change build dependency from texlive-generic-extra to diff --git a/debian/watch b/debian/watch index c174a72..e3733e4 100644 --- a/debian/watch +++ b/debian/watch @@ -1,4 +1,4 @@ version=4 opts="filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%squirrel-$1.tar.gz%" \ - https://github.com/albertodemichelis/squirrel/releases \ + https://github.com/albertodemichelis/squirrel/tags \ (?:.*?/)?v?(\d[\d.]*)\.tar\.gz debian uupdate -- 2.43.0 From fd3d4b9b6014eef4691759b264491a1a370b78c3 Mon Sep 17 00:00:00 2001 From: Matthias Geiger Date: Mon, 29 Apr 2024 23:39:24 +0200 Subject: [PATCH 2/2] Build-depend on tex-gyre Closes: #997441 --- debian/changelog | 5 +++-- debian/control | 3 ++- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/debian/changelog b/debian/changelog index c303908..b2aacdd 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,9 +1,10 @@ -squirrel3 (3.1-8.1) UNRELEASED; urgency=medium +squirrel3 (3.1-8.1) unstable; urgency=medium * Non-maintainer upload. * Fix watch file to look for Github tags instead of releases + * Build-depend on tex-gyre (Closes: #997441) - -- Matthias Geiger Fri, 16 Feb 2024 17:46:43 +0100 + -- Matthias Geiger Mon, 29 Apr 2024 23:39:09 +0200 squirrel3 (3.1-8) unstable; urgency=medium diff --git a/debian/control b/debian/control index c504be7..43afebb 100644 --- a/debian/control +++ b/debian/control @@ -8,7 +8,8 @@ Build-Depends: debhelper-compat (= 12), texlive, texlive-latex-extra, texlive-plain-generic, - latexmk + latexmk, + tex-gyre, Standards-Version: 4.4.0 Homepage: http://squirrel-lang.org/ Vcs-Git: https://salsa.debian.org/wolff-guest/squirrel3.git/ -- 2.43.0 signature.asc Description: PGP signature
Bug#1037358: mailman3-web: Upgrade from Debian 11 to Debian 12 broke mailman/mailman3-web
Hi,
Martin Krolikowski wrote on 25/06/2023 at
13:18:28+0200:
> Hi,
> the only log messages that could possibly be related to this issue are
> in /var/log/apt/term.log:
> Setting up python3-mailman-hyperkitty (1.2.1-1) ...
> /usr/lib/python3/dist-packages/requests/__init__.py:87:
> RequestsDependencyWarning: urllib3 (1.26.12) or chardet (5.1.0)
> doesn't match a supported version!
> warnings.warn("urllib3 ({}) or chardet ({}) doesn't match a supported "
>
> Regards
> Martin
>
> Am Fr., 23. Juni 2023 um 15:17 Uhr schrieb Pierre-Elliott Bécue
> :
>>
>>
>> Martin Krolikowski wrote on 23/06/2023 at
>> 10:40:12+0200:
>>
>> > Hi,
>> > after the upgrade I ran into the same problem:
>> > # django.db.utils.OperationalError: no such column:
>> > hyperkitty_mailinglist.archive_rendering_mode
>> >
>> > I solved it by following the post upgrade steps described here:
>> > https://docs.mailman3.org/en/latest/upgrade-guide.html
>> > # mailman-web migrate
>> > solved the hyperkitty error above.
>> >
>> > Regards
>>
>> mailman-web is a proxy binary that calls
>> /usr/share/mailman3-web/manage.py which is also proxy-called by a
>> properly configured django-admin command.
>>
>> In all cases, migrate does the DB migration, and it is supposed to be
>> done in the postinst in case of an upgrade.
>>
>> If you needed to do it by hand, it means that the migrate called in
>> postinst failed, I'd be glad if you could find me the errors you got.
>>
>> Cheers!
>> --
>> PEB
So this is actually quite stupid.
While some errors required to be fixed in settings etc, I had plenty
troubles understanding why some django updates were not done, and also
why things worked properly in my case.
It seeps to be because they're done as part of the mailman3-web upgrade,
which did not occur because I did not release any new version of
mailman3-web in bookworm. Why it worked in my case is because it
actually seems I did a "reconfigure" of mailman3-web after fixing the
config file.
So actually, I think I can now fix this issue...
--
PEB
signature.asc
Description: PGP signature
Bug#1014037: mailman3-web: Possible memory leak: uwsgi OOMs after a few weeks
Control: tags -1 +moreinfo Hi, Peter Chubb wrote on 29/06/2022 at 03:11:15+0200: > Package: mailman3-web > Version: 0+20200530-2 > Severity: normal > > Dear Maintainer, > > I have a mailman3 system backed by PostGRES, exim4, and nginx; > and it is set up and works properly. However, the uwsgi process > keeps growing and growing until the system OOMs. typically > after two to three weeks. > > I added more RAM (the system now has 3Gb) but that postponed > but did not fix the problem. As a workaround I now restart > the mailman3 service once a day. > > -- System Information: > Debian Release: bookworm/sid > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.17.0-3-cloud-amd64 (SMP w/1 CPU thread; PREEMPT) > Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 mailman3-web depends on: > ii dbconfig-sqlite3 2.0.21 > ii debconf [debconf-2.0] 1.5.79 > ii init-system-helpers1.63 > ii lsb-base 11.2 > ii python33.9.8-1 > hi python3-django-hyperkitty 1.3.4-4 > ii python3-django-postorius 1.3.5-1 > ii python3-psycopg2 2.9.2-2 > ii python3-whoosh 2.7.4+git6-g9134ad92-5 > ii ucf3.0043 > ii uwsgi-core 2.0.20-4+b2 > ii uwsgi-plugin-python3 2.0.20-4+b2 > > Versions of packages mailman3-web recommends: > ii nginx 1.20.2-2 > ii nginx-core [nginx] 1.20.2-2+b1 > > Versions of packages mailman3-web suggests: > ii postgresql 14+241 Having the same kind of setup for the past 6 years, I never had such an issue. Do you have more intel? -- PEB signature.asc Description: PGP signature
Bug#1033072: [Pkg-mailman-hackers] Bug#1033072: mailman3-web: After upgrade, moderation operations are broken
Hi, Peter Chubb wrote on 17/03/2023 at 00:24:59+0200: > Package: mailman3-web > Version: 0+20200530-2.1 > Severity: normal > > Dear Maintainer, > > I had a working mailman3 installation. I did 'apt upgrade' which pulled > in a new python3-hyperkitty and nginx. Now when trying to manage > 'held messages' on a list: > -- the checkbox next to 'Subject' does not toggle all the checkboxes below > it. > -- Clicking on a held message does not switch to a page where I can manage > the sender of that message. In fact it does nothing. > > I suspect the javascript to run this is broken somehow. > In my bro3wser console when looking at teh javascript I see: > > Uncaught TypeError: Bootstrap's JavaScript requires jQuery. jQuery must be > included before Bootstrap's JavaScript. > at Object.jQueryDetection (bootstrap.min.js:34:98) > at bootstrap.min.js:34:407 > at bootstrap.min.js:6:200 > at bootstrap.min.js:6:288 > main.js:38 Uncaught ReferenceError: $ is not defined > at main.js:38:1 > held_messages:445 Uncaught ReferenceError: $ is not defined > at held_messages:445:7 > held_messages.js:3 Uncaught ReferenceError: $ is not defined > at loadjs (held_messages.js:3:3) > at held_messages:452:1 > > The held_messages source file refers to jquery-3.6.0; but > jquery-1.11.3 is installed in > /var/lib/mailman3/web/static/postorius/libs/jquery > > > I notice that version 3.6 is in > /usr/share/python3-django-postorius/static/postorius/libs/jquery ... > should the nginx snippet in /etc/mailman3 be updated to point here? > > For now I deleted /var/lib/mailman3/web/static/postorius and replaced it > with a symlink to /usr/share/python3-django-postorius/static/postorius This is a race condition. When you upgraded hyperkitty/postorius, mailman3-web did not get updated and therefore the django commands that should be run were not. I think I have a solution for that, but I need to proof-check it. Sorry. -- PEB signature.asc Description: PGP signature
Bug#1030389: [pkg-lxc-devel] Bug#1030389: lxc: Conflict with new systemd cgroup unified hierarchy
Linas Vepstas wrote on 07/02/2023 at 00:05:04+0100: > I'm not using unprivileged containers. They are root containers, and > they are marked to auto-start when the machine boots. > > I'm being aggressive because I'm really angry. I ditched windows for > linux 25 years ago, because linux was really better. It was a joy to > use. It reached an all-time peak around 2005, when one could install > Ubuntu and everything just worked instantly and painlessly. Ever since > then it has been a slow decay, getting less and less stable, harder to > use and diagnose and keep running. If you mean that complex systems bring more complex issues, then I can only agree. What we could do in 2005 is just orders of magnitude less than what we can do now with a Linux Distro. Yes it has some drawbacks. That being said, most of the things can be avoided with proper doc reading. > I don't appreciate your saying that I "dug a hole for myself". You're > the guys digging the holes. Not really, no. We are the guys packaging software. This software changes and therefore we have to cope with these changes. > I am not the one who opened > https://github.com/systemd/systemd/issues/13477 -- someone else did > that three years ago. I don't know what your point is. > I am not the one who opened https://github.com/lxc/lxc/issues/4072 -- > someone else did that a year ago. Same. Yes, people meet issues due to software changes, it's the course of life. > I'm just using search engines to figure out why this and other serious > fundamental bugs halted a reboot. Nothing here is a bug. Systemd chose to enable by default cgroups v2 in Debian 11, and this had some consequences that were handled. These consequences were properly advertised by the means we use to advertise breaking changes. > Stop blaming me for the mess. I'm blaming you for trying to blame others for an unproperly done dist upgrade. This is your responsibility to read changelogs, read the documentation, and do a proper upgrade testing that anything works fine afterwards. This is not ours. -- PEB signature.asc Description: PGP signature
Bug#1030389: [pkg-lxc-devel] Bug#1030389: lxc: Conflict with new systemd cgroup unified hierarchy
Linas Vepstas wrote on 07/02/2023 at 00:35:18+0100: > There is nothing in /usr/share/doc/lxc/README.Debian.gz that provides > the work-around. I am using containers managed by root, started when > the OS boots. > > su - root and then lxc-ls -f reports > > NAMESTATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED > bind-base STOPPED 0 - - -false > > Note the right-most column. Nothing in the README about "unprivileged > containers" would seem to apply. > > apparmor is not installed on this system. > > The only work-around given in the two github issues is to set I also succeed at running privileged containers on my system. Could you print your container config to me please? It's possible some things in your config are conflicting with cgroups v2. > GRUB_CMDLINE_LINUX=systemd.unified_cgroup_hierarchy=false > > in /etc/default/grub.d/cgroup.cfg and the Debian README does not mention this > work-around. > > Perhaps it is possible to put systemd.unified_cgroup_hierarchy=false > into /etc/sysctl.conf ? Or perhaps some other config file? systemd.unified_cgroup_hierarchy=false looks like a kernel command line, I doubt it can be done after having booted. > There is another work-around: > > mkdir -p /sys/fs/cgroup/systemd && mount -t cgroup cgroup -o > none,name=systemd /sys/fs/cgroup/systemd > > However, sticking this mkdir into some /etc/init.d file does not seem > plausible for a server; it feels too hacky. -- PEB signature.asc Description: PGP signature
Bug#1068714: packages.debian.org: Please make links to deb.debian.org use HTTPS instead of HTTP
Package: www.debian.org Severity: serious Tags: security X-Debbugs-Cc: Debian Security Team Hello, In packages.debian.org, links pointing to the different source files useful for a package are pointing to deb.debian.org via HTTP (not HTTPS) links. See https://packages.debian.org/bookworm/python3-pep517, which points for [pep517_0.13.0-2.debian.tar.xz] to http://deb.debian.org/debian/pool/main/p/pep517/pep517_0.13.0-2.debian.tar.xz In these times of supply chain attack reveals etc, I think we would be best to give HTTPS links. Regards, -- PEB
Bug#1043098: [Pkg-mailman-hackers] Bug#1043098: python3-django-hyperkitty: tracebacks with update_index_one_list on mailman2 migration
Hello,
Steve Langasek wrote on 06/08/2023 at 01:10:58+0100:
> Package: python3-django-hyperkitty
> Version: 1.3.4-4
> Severity: important
>
> Dear Maintainer,
>
> Having just upgraded a system to bullseye, I am in the process of migrating
> my mailing lists from the obsolete mailman 2 to mailman3. Following guides
> such as https://docs.mailman3.org/en/latest/migration.html leads me to run,
> as list:
>
> $ django-admin hyperkitty_import --settings mailman-web \
> --pythonpath /var/lib/mailman3/hyperkitty/ -l $list_email $mbox_path
> $
>
> which succeeds (/var/lib/mailman3/hyperkitty/mailman-web.py is a forked copy
> of /etc/mailman3/mailman-web.py with appropriate permissions).
>
> I am then supposed to run update_index_one_list, which fails with a
> confusing error about missing templates:
>
> $ django-admin update_index_one_list --settings mailman-web \
> --pythonpath /var/lib/mailman3/hyperkitty/ -l $list_email
> Indexing 421 emails
> [ERROR/MainProcess] Failed indexing 1 - 421 (retry 5/5):
> search/indexes/hyperkitty/email_text.txt (pid 6818):
> search/indexes/hyperkitty/email_text.txt
> Traceback (most recent call last):
> File
> "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py",
> line 111, in do_update
> backend.update(index, current_qs, commit=commit)
> File "/usr/lib/python3/dist-packages/haystack/backends/whoosh_backend.py",
> line 269, in update
> doc = index.full_prepare(obj)
> File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 236, in
> full_prepare
> self.prepared_data = self.prepare(obj)
> File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 227, in
> prepare
> self.prepared_data[field.index_fieldname] = field.prepare(obj)
> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 235, in
> prepare
> return self.convert(super(CharField, self).prepare(obj))
> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 99, in
> prepare
> return self.prepare_template(obj)
> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 212, in
> prepare_template
> t = loader.select_template(template_names)
> File "/usr/lib/python3/dist-packages/django/template/loader.py", line 47,
> in select_template
> raise TemplateDoesNotExist(', '.join(template_name_list), chain=chain)
> django.template.exceptions.TemplateDoesNotExist:
> search/indexes/hyperkitty/email_text.txt
> Traceback (most recent call last):
> File "/usr/bin/django-admin", line 5, in
> management.execute_from_command_line()
> File "/usr/lib/python3/dist-packages/django/core/management/__init__.py",
> line 381, in execute_from_command_line
> utility.execute()
> File "/usr/lib/python3/dist-packages/django/core/management/__init__.py",
> line 375, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
> File "/usr/lib/python3/dist-packages/django/core/management/base.py", line
> 323, in run_from_argv
> self.execute(*args, **cmd_options)
> File "/usr/lib/python3/dist-packages/django/core/management/base.py", line
> 364, in execute
> output = self.handle(*args, **options)
> File
> "/usr/lib/python3/dist-packages/hyperkitty/management/commands/update_index_one_list.py",
> line 41, in handle
> update_index(listname=options.get("listname")[0],
> File "/usr/lib/python3/dist-packages/hyperkitty/search_indexes.py", line
> 117, in update_index
> update_cmd.update_backend("hyperkitty", "default")
> File
> "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py",
> line 319, in update_backend
> max_pk = do_update(
> File
> "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py",
> line 111, in do_update
> backend.update(index, current_qs, commit=commit)
> File "/usr/lib/python3/dist-packages/haystack/backends/whoosh_backend.py",
> line 269, in update
> doc = index.full_prepare(obj)
> File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 236, in
> full_prepare
> self.prepared_data = self.prepare(obj)
> File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 227, in
> prepare
> self.prepared_data[field.index_fieldname] = field.prepare(obj)
> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 235, in
> prepare
> return self.convert(super(CharField, self).prepare(obj))
> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 99, in
> prepare
> return self.prepare_template(obj)
> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 212, in
> prepare_template
> t = loader.select_template(template_names)
> File "/usr/lib/python3/dist-packages/django/template/loader.py", line 47,
> in select_template
> raise TemplateDoesNotExist(', '.join(template_name_list), chain=chain)
> django.template.exceptions.TemplateDoesNotExist:
> search/indexes/hyperkitty/email_text.txt
> $
>
> This is quite confusing, as
>
Bug#1065477: [Pkg-owncloud-maintainers] Bug#1065477: owncloud-client: Uploads to unstable must have a higher version than present in unstable.
Hello, Sebastian Ramacher wrote on 05/03/2024 at 09:38:13+0100: > Source: owncloud-client > Version: 4.2.0.11670+dfsg-1.1 > Severity: serious > Tags: ftbfs > X-Debbugs-Cc: sramac...@debian.org > > Version check failed: > Your upload included the binary package dolphin-owncloud, version > 4.2.0.11670+dfsg-1.1, for amd64, > however unstable already has version 5.0.0-1+b1. > Uploads to unstable must have a higher version than present in unstable. > > Cheers owncloud-client has been uploaded far before in the past, and was shipping dolphin-owncloud, nautilus-owncloud, et al. In client v5, upstream removed these packages from the owncloud-client source, and therefore they're now packaged through dedicated source packages. These ones are the latest uploads. I'll upload the v5 version of owncloud-client source package which won't ship dolphin-owncloud et al anymore. It's what's been suggested to me, and therefore I can't see a bug here. Could you give me a bit more intel aobut why this would be a serious bug? -- PEB signature.asc Description: PGP signature
Bug#1062387: drogon: NMU diff for 64-bit time_t transition
mwhud...@fastmail.fm wrote on 28/02/2024 at 03:25:55+0100: > Dear maintainer, > > Please find attached a final version of this patch for the time_t > transition. This patch is being uploaded to unstable. > > Note that this adds a versioned build-dependency on dpkg-dev, to guard > against accidental backports with a wrong ABI. > > Thanks! > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.5.0-21-generic (SMP w/16 CPU threads; PREEMPT) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > [2. text/plain; nmu_drogon.debdiff]... That's great but you did not reply to my past question. -- PEB signature.asc Description: PGP signature
Bug#1064397: ITP: client-desktop-shell-integration-nautilus -- Nautilus, Nemo and Caja integration of the owncloud-client
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: client-desktop-shell-integration-nautilus Version : 5.0.0 Upstream Contact: Frank Müller * URL : https://github.com/owncloud/client-desktop-shell-integration-nautilus * License : GPL-2 Programming Lang: Python, Shell, ... Description : Nautilus, Nemo and Caja integration for ownCloud Client. These three extensions were originally integrated in the owncloud-client source package. Upstream decided to extract them to create a new repo. The package will be maintained in the owncloud-team.
Bug#1064355: ITP: client-desktop-shell-integration-dolphin -- ownCloud client integration for Dolphin
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-owncloud-maintain...@lists.alioth.debian.org * Package name: client-desktop-shell-integration-dolphin Version : 5.0.0 Upstream Contact: Fabian Müller * URL : https://github.com/owncloud/client-desktop-shell-integration-dolphin * License : GPL-2 Programming Lang: C++ Description : ownCloud client integration for Dolphin Dolphin ownCloud is an extension that integrates the ownCloud web service with Plasma Desktop (KDE). It was part of src:owncloud-client, but upstream removed it and put it in another repo. I intend to have this package maintained into the owncloud-maintainers team.
Bug#1064029: bookworm-pu: package mailman3/3.3.8-2~deb12u2
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: mailm...@packages.debian.org Control: affects -1 + src:mailman3 Hi, Some bugs affecting mailman3 are found in bookworm. I fixed these in unstable but forgot to do a stable-pu. [ Reason ] Bug #1040708 is about a change in the way sqlalchemy reads postgresql URIs. Historically the prefix in this URI was postgres. Now it's postgresql. Therefore the default config for mailman3 is broken under bookworm. Bug #1038953 is about tracking cron-daemon instead of cron to allow more flexibility should one wish to use something else than cron. It was supposed to be done for some time. [ Impact ] The first one will force users to fix the config if they wish to work with postgresql. [ Tests ] Installed fixed version works fine. [ Risks ] Changes are trivial. [ 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 diff -Nru mailman3-3.3.8/debian/changelog mailman3-3.3.8/debian/changelog --- mailman3-3.3.8/debian/changelog 2023-06-23 01:03:08.0 +0200 +++ mailman3-3.3.8/debian/changelog 2024-02-15 23:59:26.0 +0100 @@ -1,3 +1,11 @@ +mailman3 (3.3.8-2~deb12u2) bookworm; urgency=medium + + * bookworm-pu of two fixes +- s/postgres/postgresql/ in config files +- Add replacement dependency on cron to cron-daemon + + -- Pierre-Elliott Bécue Thu, 15 Feb 2024 23:59:26 +0100 + mailman3 (3.3.8-2~deb12u1) bookworm; urgency=medium * Bookworm-pu of 4 bug fixes diff -Nru mailman3-3.3.8/debian/contrib/mailman.cfg.sample mailman3-3.3.8/debian/contrib/mailman.cfg.sample --- mailman3-3.3.8/debian/contrib/mailman.cfg.sample2023-06-23 01:03:08.0 +0200 +++ mailman3-3.3.8/debian/contrib/mailman.cfg.sample2024-02-15 23:59:26.0 +0100 @@ -170,7 +170,7 @@ # 'configuration' substitutions. url: sqlite:///$DATA_DIR/mailman.db #url: mysql+pymysql://mailman3:mmpass@localhost/mailman3?charset=utf8_unicode=1 -#url: postgres://mailman3:mmpass@localhost/mailman3 +#url: postgresql://mailman3:mmpass@localhost/mailman3 debug: no diff -Nru mailman3-3.3.8/debian/control mailman3-3.3.8/debian/control --- mailman3-3.3.8/debian/control 2023-06-23 01:03:08.0 +0200 +++ mailman3-3.3.8/debian/control 2024-02-15 23:59:26.0 +0100 @@ -44,7 +44,7 @@ Architecture: all Depends: dbconfig-sqlite3 | dbconfig-pgsql | dbconfig-mysql | dbconfig-no-thanks, logrotate, - cron, + cron | cron-daemon, python3-falcon (>> 1.0.0), python3-psycopg2 | python3-pymysql, ucf, diff -Nru mailman3-3.3.8/debian/mailman3.postinst mailman3-3.3.8/debian/mailman3.postinst --- mailman3-3.3.8/debian/mailman3.postinst 2023-06-23 01:03:08.0 +0200 +++ mailman3-3.3.8/debian/mailman3.postinst 2024-02-15 23:59:26.0 +0100 @@ -52,7 +52,7 @@ pgsql) sed -i -e 's|^#\?\s*\(class: mailman\.database\.postgresql\.PostgreSQLDatabase\)$|\1|' \ $mailmancfg_new -sed -i -e "s|^#\?\s*url: postgres://.*$|url: postgres://$dbc_dbuser:$dbc_dbpass@$dbc_dbserver/$dbc_dbname|" \ +sed -i -e "s|^#\?\s*url: postgresql://.*$|url: postgresql://$dbc_dbuser:$dbc_dbpass@$dbc_dbserver/$dbc_dbname|" \ $mailmancfg_new ;; mysql)
Bug#1062387: drogon: NMU diff for 64-bit time_t transition
Hi, mwhud...@debian.org wrote on 01/02/2024 at 09:46:18+0100: > Source: drogon > Version: 1.8.7+ds-1 > Severity: serious > Tags: patch pending > Justification: library ABI skew on upgrade > User: debian-...@lists.debian.org > Usertags: time-t > > Dear maintainer, > > As part of the 64-bit time_t transition required to support 32-bit > architectures in 2038 and beyond > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified > drogon as a source package shipping runtime libraries whose ABI > either is affected by the change in size of time_t, or could not be > analyzed via abi-compliance-checker (and therefore to be on the safe > side we assume is affected). > > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for drogon > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Although > this package will be uploaded to experimental immediately, there will be a > period of several days before we begin uploads to unstable; so if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. I don't really like the new name for the libs, will you change it back at some point? -- PEB signature.asc Description: PGP signature
Bug#1060290: bullseye-pu: package django-mailman3/1.3.5-2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Hello,
Some users brought to my attention that in bullseye, django-mailman3
doesn't scrub messages properly before passing them to any archiver, and
therefore some messages are not archived.
This PU patches django-mailman3 so that it processes messages having a
null-byte in their body properly.
[ Reason ]
The bug probably has existed all the time before the patch made upstream
there:
https://gitlab.com/mailman/django-mailman3/-/commit/5bc1f6e8ca4d95ea4e2be861821cb17f168f8d1b?merge_request_iid=121
[ Impact ]
Messages received by mailman3 might not be archived properly archived.
[ Tests ]
Tests were designed upstream, but require binary files to be added to
the code, which can't be done through a quilt patch, so I have not
included the tests.
[ Risks ]
The patch works properly. Should a bug arise due to the new code,
archiving would be broken.
[ 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
[ Changes ]
Explicit replacement of nullbyte characters by '' in a message body when
scrubbing.
dpkg-source: avertissement: extraction d'un paquet source non signé
(/home/peb/git/debian/mailman-team/django-mailman3/django-mailman3_1.3.5-2.dsc)
dpkg-source: avertissement: extraction d'un paquet source non signé
(/home/peb/git/debian/mailman-team/django-mailman3/django-mailman3_1.3.5-2+deb11u1.dsc)
diff -Nru django-mailman3-1.3.5/debian/changelog
django-mailman3-1.3.5/debian/changelog
--- django-mailman3-1.3.5/debian/changelog 2021-03-04 00:23:46.0
+0100
+++ django-mailman3-1.3.5/debian/changelog 2024-01-08 22:32:29.0
+0100
@@ -1,3 +1,10 @@
+django-mailman3 (1.3.5-2+deb11u1) bullseye; urgency=medium
+
+ * d/p/0001: Fix archiving issues due to nullbytes in message body
+(Closes: #1033256)
+
+ -- Pierre-Elliott Bécue Mon, 08 Jan 2024 22:32:29 +0100
+
django-mailman3 (1.3.5-2) unstable; urgency=medium
* Compile django LC messages at build time
diff -Nru
django-mailman3-1.3.5/debian/patches/0001-Scrubber-now-removes-null-bytes-from-the-scrubbed-me.patch
django-mailman3-1.3.5/debian/patches/0001-Scrubber-now-removes-null-bytes-from-the-scrubbed-me.patch
---
django-mailman3-1.3.5/debian/patches/0001-Scrubber-now-removes-null-bytes-from-the-scrubbed-me.patch
1970-01-01 01:00:00.0 +0100
+++
django-mailman3-1.3.5/debian/patches/0001-Scrubber-now-removes-null-bytes-from-the-scrubbed-me.patch
2024-01-08 22:32:29.0 +0100
@@ -0,0 +1,43 @@
+From: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?=
+Date: Mon, 8 Jan 2024 22:40:38 +0100
+Subject: Scrubber now removes null bytes from the scrubbed message body.
+
+---
+ README.rst | 1 +
+ django_mailman3/lib/scrub.py | 5 -
+ 3 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/README.rst b/README.rst
+index 775b158..98264be 100644
+--- a/README.rst
b/README.rst
+@@ -17,6 +17,7 @@ NEWS
+ * Add a new method get_django_user to return Django User model. (See !99)
+ * Add ``delete_archives`` field to ``mailinglist_deleted`` Signal.
+ * Replaced deprecated ``ugettexy_lazy`` with ``gettext_lazy``. (Closes #37)
++* Scrubber now removes null bytes from the scrubbed message body.
+
+
+ 1.3.4 (2020-06-05)
+diff --git a/django_mailman3/lib/scrub.py b/django_mailman3/lib/scrub.py
+index f35761b..2be66c9 100644
+--- a/django_mailman3/lib/scrub.py
b/django_mailman3/lib/scrub.py
+@@ -248,6 +248,8 @@ class Scrubber():
+ next_part_match = NEXT_PART.search(result)
+ if next_part_match:
+ result = result[0:next_part_match.start(0)]
++# MAS Remove any null butes from the result.
++result = re.sub('\x00', '', result)
+ return result
+
+ def _get_text(self):
+@@ -276,6 +278,7 @@ class Scrubber():
+ if not part_content.endswith('\n'):
+ part_content += '\n'
+ text.append(part_content)
+-return '\n'.join(text)
++# MAS remove any null bytes from the text.
++return re.sub('\x00', '', '\n'.join(text))
+ else:
+ return self._get_text_one_part(self.msg)
diff -Nru django-mailman3-1.3.5/debian/patches/series
django-mailman3-1.3.5/debian/patches/series
--- django-mailman3-1.3.5/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ django-mailman3-1.3.5/debian/patches/series 2024-01-08 22:32:29.0
+0100
@@ -0,0 +1 @@
+0001-Scrubber-now-removes-null-bytes-from-the-scrubbed-me.patch
Bug#1058931: ITP: kdsingleapplication -- KDAB's helper class for single-instance policy applications
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: kdsingleapplication Version : 1.0.0 Upstream Author : Klarälvdalens Datakonsult AB * URL : https://github.com/KDAB/KDSingleApplication * License : MIT Programming Lang: C++ Description : KDAB's helper class for single-instance policy applications KDSingleapplication provides a helper class to make sure that an application is single-instance, that is, can't be started more than once for an user. It is a replacement for QtSingleApplication which is not maintained anymore. It's a dependency of owncloud-client, that I intend to maintain in the owncloud packaging team
Bug#1010273: Possible solution: add --clear flag to collectstatic
Marco Steinacher wrote on 29/11/2023 at 09:25:03+0100: > Hi again, > > Here is an update to my previous message: > > I think the easiest workaround is to add the --clear flag to the > collectstatic command, i.e. > > www-data@mail:/usr/share/mailman3-web$ ./manage.py collectstatic --clear > www-data@mail:/usr/share/mailman3-web$ ./manage.py compress > > With the --clear flag the existing files are deleted before trying to > copy the original file. > https://docs.djangoproject.com/en/4.2/ref/contrib/staticfiles/#collectstatic > > This should solve the problem of old static files not being updated > because of source files that are older than the files installed by the > previous version. > > The --clear flag should probably be added to > debian/mailman3-web.postinst in update_django(), line 198, to fix the > problem in the mailman3-web Debian > package. > https://salsa.debian.org/mailman-team/mailman-suite/-/blob/master/debian/mailman3-web.postinst#L198 > > Marco Hello, I saw this bug report, but I admit it slipped out of my mind. I have updated the django-mailman3 package recently and was planning to finish with a sweep on postorius and hyperkitty and then the web package. I'll include these fixes, and then try to have the relevant fixes backported into bookworm via a stable upload. Thanks for your mails. -- PEB signature.asc Description: PGP signature
Bug#947334: lxc-checkpoint needs the criu package
De : Mathias Gibbens À : Pierre-Elliott Bécue Cc : 947...@bugs.debian.org Date : 25 nov. 2023 15:35:19 Objet : Re: Bug#947334: lxc-checkpoint needs the criu package > On Fri, 2023-11-24 at 11:37 +0100, Pierre-Elliott Bécue wrote: >> Historically it was only in experimental, so I couldn't act upon this >> bug. >> >> Now we can. I'd either add it as a Depends or as a Recommends. > > I don't think criu should be in Depends, as checkpointing/live > migration of containers seems to be a less common use case, and the lxc > package has been working fine in Debian for many years without it. I > put it as a Suggests, since it does enhance the capability of lxc, but > users who don't explicitly need CRIU won't be missing out on any > functionality if they don't have it installed. However, I'll defer to > group consensus on where exactly to list the criu packge for lxc. > > Mathias In that case I'd put it as a Recommends. -- Pierre-Elliott Bécue
Bug#947334: [pkg-lxc-devel] Bug#947334: lxc-checkpoint needs the criu package
Mathias Gibbens wrote on 23/11/2023 at 21:53:54+0100: > Control: tags -1 + pending > > I think it's reasonable to Suggest criu in the bin:lxc package. If > anyone has a strong opinion that it should rather be a Recommends, > please let me know. Historically it was only in experimental, so I couldn't act upon this bug. Now we can. I'd either add it as a Depends or as a Recommends. I was expecting to do a full sweep on the packages I maintain soon, so if you wish I can take care of that at that time. If you want to do a release before, feel free to. :) Cheers! -- PEB signature.asc Description: PGP signature
Bug#1053502: mailman3-web: Package failed to install during upgrade from Debian 11 to 12
Please keep the bug report CC-ed. Steven Verhulst wrote on 06/10/2023 at 13:16:09+0200: > Hi, > > > > /etc/mysql/debian.cnf is a config file auto generated by some debian scripts. > > It contains host / user information for mysql connection. > > According to the contents this file is deprecated and should no longer be > used: > > > > # THIS FILE IS OBSOLETE. STOP USING IT IF POSSIBLE. > > # This file exists only for backwards compatibility for > > # tools that run '--defaults-file=/etc/mysql/debian.cnf' > > # and have root level access to the local filesystem. > > # With those permissions one can run 'mariadb' directly > > # anyway thanks to unix socket authentication and hence > > # this file is useless. See package README for more info. > > # THIS FILE WILL BE REMOVED IN A FUTURE DEBIAN RELEASE. > > > > > > “sed: -e expression #2, char 82: unterminated `s' command” > > Makes me believe that there is an issue with with one the sed > expression in the post-installation script. Yes, I am aware of your beliefs, and they're probably founded, but to be able to dig in I need some context. If you did not fix manually the issue, could you add "set -x" at the beginning of /var/lib/dpkg/info/mailman3-web.postinst script and run a dpkg --configure mailman3-web and give me the output? If some passwords fall in the output, of course feel free to censor them. -- PEB signature.asc Description: PGP signature
Bug#1053502: Fwd: Re: Bug#1053502: mailman3-web: Package failed to install during upgrade from Debian 11 to 12
Steven Verhulst wrote on 06/10/2023 at 13:16:09+0200: > Hi, > > > > /etc/mysql/debian.cnf is a config file auto generated by some debian scripts. > > It contains host / user information for mysql connection. > > According to the contents this file is deprecated and should no longer be > used: > > > > # THIS FILE IS OBSOLETE. STOP USING IT IF POSSIBLE. > > # This file exists only for backwards compatibility for > > # tools that run '--defaults-file=/etc/mysql/debian.cnf' > > # and have root level access to the local filesystem. > > # With those permissions one can run 'mariadb' directly > > # anyway thanks to unix socket authentication and hence > > # this file is useless. See package README for more info. > > # THIS FILE WILL BE REMOVED IN A FUTURE DEBIAN RELEASE. > > > > > > “sed: -e expression #2, char 82: unterminated `s' command” > > Makes me believe that there is an issue with with one the sed expression in > the post-installation script. > > > > Kind regards, > > > > Steven Verhulst > > > > > > On 05/10/2023, 16:23, "Pierre-Elliott Bécue" wrote: > > tags 1053502 +moreinfo > > thanks > > > > Hi, > > > > Steven Verhulst wrote on 05/10/2023 at 10:37:05+0200: > > > >> Package: mailman3-web > >> Version: 0+20200530-2.1 > >> Severity: important > >> > > > >> Dear Maintainer, > >> > > > >> When we upgraded our test mailingserver from Debian 11 to 12 we > >> noticed the following error: > >> > > > >> Setting up mailman3-web (0+20200530-2.1) ... > >> Determining localhost credentials from /etc/mysql/debian.cnf: failed (hosts >> not equal). > >> dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf > >> dbconfig-common: flushing administrative password > >> sed: -e expression #2, char 82: unterminated `s' command > >> dpkg: error processing package mailman3-web (--configure): > >> installed mailman3-web package post-installation script subprocess returned >> error exit status 1 > >> > > > >> From what I understand there seems to be an issue with the > >> post-installation script. > >> > > > >> Since the post-installation script did not run it left us with a > >> broken listserver. Further it is not possible to use APT to update > >> packages as it keep warning about mailman3-web package being broken. > > > > When I read > > > >> Determining localhost credentials from /etc/mysql/debian.cnf: failed (hosts >> not equal). > >> dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf > >> dbconfig-common: flushing administrative password > > > > I tend to think some weird stuff happened on your host. > > > > But to try understanding further the issue, could you please give me > > some hints about what this file contains?
Bug#1053502: mailman3-web: Package failed to install during upgrade from Debian 11 to 12
tags 1053502 +moreinfo thanks Hi, Steven Verhulst wrote on 05/10/2023 at 10:37:05+0200: > Package: mailman3-web > Version: 0+20200530-2.1 > Severity: important > > Dear Maintainer, > > When we upgraded our test mailingserver from Debian 11 to 12 we > noticed the following error: > > Setting up mailman3-web (0+20200530-2.1) ... > Determining localhost credentials from /etc/mysql/debian.cnf: failed (hosts > not equal). > dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf > dbconfig-common: flushing administrative password > sed: -e expression #2, char 82: unterminated `s' command > dpkg: error processing package mailman3-web (--configure): > installed mailman3-web package post-installation script subprocess returned > error exit status 1 > > From what I understand there seems to be an issue with the > post-installation script. > > Since the post-installation script did not run it left us with a > broken listserver. Further it is not possible to use APT to update > packages as it keep warning about mailman3-web package being broken. When I read > Determining localhost credentials from /etc/mysql/debian.cnf: failed (hosts > not equal). > dbconfig-common: writing config to /etc/dbconfig-common/mailman3-web.conf > dbconfig-common: flushing administrative password I tend to think some weird stuff happened on your host. But to try understanding further the issue, could you please give me some hints about what this file contains? -- PEB signature.asc Description: PGP signature
Bug#1041313: RM: volatildap -- ROM; Not maintained anymore, no reverse deps
Package: ftp.debian.org Severity: normal Hi, Please remove src:volatildap from unstable. It's not maintained anymore and serves no purpose in Debian. dak says it should be alright. .-(10:12:39)-(~)-(peb@coccia)- `---> dak rm -nR -s unstable volatildap Will remove the following packages from unstable: python3-volatildap |1.5.0-3 | all volatildap |1.5.0-3 | source Maintainer: Debian Python Team --- Reason --- -- Checking reverse dependencies... No dependency problem found. dak rm -nR -s unstable volatildap 7,89s user 0,74s system 27% cpu 31,225 total Same output with stable and testing, so could you also drop it from testing, and, if possible, from stable, where it should never have landed? Cheers, -- PEB
Bug#1037358: mailman3-web: Upgrade from Debian 11 to Debian 12 broke mailman/mailman3-web
Martin Krolikowski wrote on 23/06/2023 at 10:40:12+0200: > Hi, > after the upgrade I ran into the same problem: > # django.db.utils.OperationalError: no such column: > hyperkitty_mailinglist.archive_rendering_mode > > I solved it by following the post upgrade steps described here: > https://docs.mailman3.org/en/latest/upgrade-guide.html > # mailman-web migrate > solved the hyperkitty error above. > > Regards mailman-web is a proxy binary that calls /usr/share/mailman3-web/manage.py which is also proxy-called by a properly configured django-admin command. In all cases, migrate does the DB migration, and it is supposed to be done in the postinst in case of an upgrade. If you needed to do it by hand, it means that the migrate called in postinst failed, I'd be glad if you could find me the errors you got. Cheers! -- PEB signature.asc Description: PGP signature
Bug#1037358: mailman3-web: Upgrade from Debian 11 to Debian 12 broke mailman/mailman3-web
De : Norbert Preining À : Pierre-Elliott Bécue Cc : 1037...@bugs.debian.org Date : 23 juin 2023 09:05:40 Objet : Re: Bug#1037358: mailman3-web: Upgrade from Debian 11 to Debian 12 broke mailman/mailman3-web > Hi PEB, > >> Indeed, when I fixed the 3.10 testing issues, I failed to have the >> config for mailman3-web fixed. >> >> I'll add these and send a stable-pu. > > Thanks! > >>> - /etc/cron.d/mailman3 contains a call to gatenews which triggers errors >>> and probalby should not be called in the cron script >> >> Right, it still is in my todolist, which is a shame as it's trivial to >> fix. I guess the reason I never dropped it is that it's harmless as the >> script refuses to run. > > Yeah, but the repeated emails from cron with the warning are a bit painful. > > >>> - even with the above changes, the hourly run job fails (that is actually >>> a serious bug!) >>> >>> /usr/lib/python3/dist-packages/whoosh/codec/whoosh3.py:1116: SyntaxWarning: >>> "is" with a literal. Did you mean "=="? >>> elif fixedsize is 0: >>> [ERROR/MainProcess] Failed indexing 1 - 1 (retry 5/5): no such column: >>> hyperkitty_mailinglist.archive_rendering_mode (pid 4974): no such column: >>> hyperkitty_mailinglist.archive_rendering_mode >>> Traceback (most recent call last): >>> File >>> "/usr/lib/python3/dist-packages/django/db/models/fields/related_descriptors.py", >>> line 173, in __get__ >>> rel_obj = self.field.get_cached_value(instance) >>> ^ >>> File "/usr/lib/python3/dist-packages/django/db/models/fields/mixins.py", >>> line 15, in get_cached_value >>> return instance._state.fields_cache[cache_name] >>> >>> KeyError: 'mailinglist' >>> >>> During handling of the above exception, another exception occurred: >>> >>> Traceback (most recent call last): >>> File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line >>> 84, in _execute >>> return self.cursor.execute(sql, params) >>> >>> File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py", >>> line 423, in execute >>> return Database.Cursor.execute(self, query, params) >>> >>> sqlite3.OperationalError: no such column: >>> hyperkitty_mailinglist.archive_rendering_mode >>> >>> The above exception was the direct cause of the following exception: >>> >>> Traceback (most recent call last): >>> File >>> "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py", >>> line 119, in do_update >>> backend.update(index, current_qs, commit=commit) >>> File >>> "/usr/lib/python3/dist-packages/haystack/backends/whoosh_backend.py", line >>> 258, in update >>> doc = index.full_prepare(obj) >>> ^^^ >>> File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 235, in >>> full_prepare >>> self.prepared_data = self.prepare(obj) >>> ^ >>> File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 226, in >>> prepare >>> self.prepared_data[field.index_fieldname] = field.prepare(obj) >>> ^^ >>> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 236, in >>> prepare >>> return self.convert(super().prepare(obj)) >>> >>> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 105, in >>> prepare >>> values = self.resolve_attributes_lookup(current_objects, attrs) >>> ^^ >>> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 125, in >>> resolve_attributes_lookup >>> if not hasattr(current_object, attributes[0]): >>> ^^ >>> File >>> "/usr/lib/python3/dist-packages/django/db/models/fields/related_descriptors.py", >>> line 187, in __get__ >>> rel_obj = self.get_
Bug#1038906: bookworm-pu: package mailman3/3.3.8-1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu Hi, Multiple small bugs could have been fixed before the bookworm release, but having been elsewhere in my mind, I let those slip. I'd therefore like to submit this debdiff for a stable-pu. The package with these fixes has been uploaded to unstable around 20 minutes ago. [ Reason ] Fixes bugs #1030156, #1032684, #1032080, with no codebase change, only packaging changes. [ Impact ] The cron raises an error when it's called, which is annoying. Italian and Romanian users would be sad pandas. The mariadb thing is a bit harsher as any user using mailman3 with mariadb currently needs to fix mailman3 after a reboot. [ Tests ] None, but I did deploy this version on my production server to check that it works. [ Risks ] Changes are trivial [ 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 [ Changes ] Two languages translations for debconf templates One cron removal Systemd service dependencies fixup And a gbp.conf branch update Thanks! <3 diff -Nru mailman3-3.3.8/debian/changelog mailman3-3.3.8/debian/changelog --- mailman3-3.3.8/debian/changelog 2023-01-29 12:41:29.0 +0100 +++ mailman3-3.3.8/debian/changelog 2023-06-23 01:03:08.0 +0200 @@ -1,3 +1,23 @@ +mailman3 (3.3.8-2~deb12u1) bookworm; urgency=medium + + * Bookworm-pu of 4 bug fixes + + -- Pierre-Elliott Bécue Fri, 23 Jun 2023 01:03:08 +0200 + +mailman3 (3.3.8-2) unstable; urgency=medium + + * Drop an unneeded cron from mailman3 + * Add an After=mariadb.service, Wants=mariadb.service in mailman3 service +(this is harmless if mariadb is missing) (Closes: #1030156) + + [ Remus-Gabriel Chelu ] + * Add Romanian translation for debconf templates (Closes: #1032684) + + [ Ceppo ] + * Add Italian translation for debconf templates (Closes: #1032080) + + -- Pierre-Elliott Bécue Fri, 23 Jun 2023 00:49:01 +0200 + mailman3 (3.3.8-1) unstable; urgency=medium * New upstreeam release: 3.3.8 diff -Nru mailman3-3.3.8/debian/gbp.conf mailman3-3.3.8/debian/gbp.conf --- mailman3-3.3.8/debian/gbp.conf 2023-01-29 11:46:07.0 +0100 +++ mailman3-3.3.8/debian/gbp.conf 2023-06-23 01:03:05.0 +0200 @@ -1,2 +1,3 @@ [DEFAULT] pristine-tar = True +debian-branch = debian/bookworm diff -Nru mailman3-3.3.8/debian/mailman3.cron.d mailman3-3.3.8/debian/mailman3.cron.d --- mailman3-3.3.8/debian/mailman3.cron.d 2023-01-29 11:46:07.0 +0100 +++ mailman3-3.3.8/debian/mailman3.cron.d 2023-06-23 00:29:15.0 +0200 @@ -8,6 +8,3 @@ # At 12AM, send mail digests for lists that do periodic as well as threshold delivery 0 12 * * * list if [ -x /usr/bin/mailman ]; then /usr/bin/mailman digests --periodic; fi - -# Every 15 minutes, gate messages from usenet to those lists which have the gateway configured -*/15 * * * * listif [ -x /usr/bin/mailman ]; then /usr/bin/mailman gatenews; fi diff -Nru mailman3-3.3.8/debian/mailman3.service mailman3-3.3.8/debian/mailman3.service --- mailman3-3.3.8/debian/mailman3.service 2023-01-29 11:46:07.0 +0100 +++ mailman3-3.3.8/debian/mailman3.service 2023-06-23 00:44:46.0 +0200 @@ -5,6 +5,8 @@ Documentation=man:mailman(1) Documentation=https://mailman.readthedocs.io/ ConditionPathExists=/etc/mailman3/mailman.cfg +After=mariadb.service +Wants=mariadb.service [Service] ExecStart=/usr/bin/mailman -C /etc/mailman3/mailman.cfg start --force diff -Nru mailman3-3.3.8/debian/po/it.po mailman3-3.3.8/debian/po/it.po --- mailman3-3.3.8/debian/po/it.po 1970-01-01 01:00:00.0 +0100 +++ mailman3-3.3.8/debian/po/it.po 2023-06-23 00:34:03.0 +0200 @@ -0,0 +1,73 @@ +# mailman3 po-debconf Italian translation +# Copyright (C) 2023 mailman3's copyright holder +# This file is distributed under the same license as the mailman3 package. +# Ceppo , 2023. +# +msgid "" +msgstr "" +"Project-Id-Version: mailman3\n" +"Report-Msgid-Bugs-To: mailm...@packages.debian.org\n" +"POT-Creation-Date: 2018-03-15 10:57+0100\n" +"PO-Revision-Date: 2023-02-09 00:00+\n" +"Last-Translator: Ceppo \n" +"Language-Team: Italian \n" +"Language: it\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#. Type: boolean +#. Description +#: ../templates:1001 +msgid "Add the HyperKitty configuration to mailman.cfg?" +msgstr "Aggiungere la configurazione di HyperKitty a mailman.cfg?" + +#. Type: boolean +#. Description +#: ../templates:1001 +msgid "" +"Mailman3 needs additional configuration in mailman.cfg in order to send " +"mess
Bug#1037358: mailman3-web: Upgrade from Debian 11 to Debian 12 broke mailman/mailman3-web
Hey Norbert,
Thanks for the feedback!
Norbert Preining wrote on 12/06/2023 at 06:32:02+0200:
> Package: mailman3-web
> Version: 0+20200530-2.1
> Severity: important
>
> Dear Maintainer,
>
> With the upgrade from Debian 11 to Debian 12 a lot of problems popped up
> around mailman/web:
>
> - /etc/mailman/mailman-web.py needs updates:
>
> # Updates require this, should already be in Debian's package, but isn't
> # See https://gitlab.com/mailman/hyperkitty/-/issues/401
> DEFAULT_AUTO_FIELD = 'django.db.models.AutoField'
> # /usr/lib/python3/dist-packages/django_q/conf.py contains
> # conf.py:TIMEOUT = conf.get("timeout", None)
> # conf.py:RETRY = conf.get("retry", 60)
> # which is broken
> Q_CLUSTER = {
> 'timeout': 300,
> 'save_limit': 100,
> 'orm': 'default',
> 'retry': 360,
> }
>
> since these values are not taken into the Debian packages, although they
> are necessary
Indeed, when I fixed the 3.10 testing issues, I failed to have the
config for mailman3-web fixed.
I'll add these and send a stable-pu.
> - /etc/cron.d/mailman3 contains a call to gatenews which triggers errors
> and probalby should not be called in the cron script
Right, it still is in my todolist, which is a shame as it's trivial to
fix. I guess the reason I never dropped it is that it's harmless as the
script refuses to run.
> - even with the above changes, the hourly run job fails (that is actually
> a serious bug!)
>
> /usr/lib/python3/dist-packages/whoosh/codec/whoosh3.py:1116: SyntaxWarning:
> "is" with a literal. Did you mean "=="?
> elif fixedsize is 0:
> [ERROR/MainProcess] Failed indexing 1 - 1 (retry 5/5): no such column:
> hyperkitty_mailinglist.archive_rendering_mode (pid 4974): no such column:
> hyperkitty_mailinglist.archive_rendering_mode
> Traceback (most recent call last):
> File
> "/usr/lib/python3/dist-packages/django/db/models/fields/related_descriptors.py",
> line 173, in __get__
> rel_obj = self.field.get_cached_value(instance)
> ^
> File "/usr/lib/python3/dist-packages/django/db/models/fields/mixins.py",
> line 15, in get_cached_value
> return instance._state.fields_cache[cache_name]
>
> KeyError: 'mailinglist'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line 84,
> in _execute
> return self.cursor.execute(sql, params)
>
> File "/usr/lib/python3/dist-packages/django/db/backends/sqlite3/base.py",
> line 423, in execute
> return Database.Cursor.execute(self, query, params)
>
> sqlite3.OperationalError: no such column:
> hyperkitty_mailinglist.archive_rendering_mode
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
> File
> "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py",
> line 119, in do_update
> backend.update(index, current_qs, commit=commit)
> File "/usr/lib/python3/dist-packages/haystack/backends/whoosh_backend.py",
> line 258, in update
> doc = index.full_prepare(obj)
> ^^^
> File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 235, in
> full_prepare
> self.prepared_data = self.prepare(obj)
> ^
> File "/usr/lib/python3/dist-packages/haystack/indexes.py", line 226, in
> prepare
> self.prepared_data[field.index_fieldname] = field.prepare(obj)
> ^^
> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 236, in
> prepare
> return self.convert(super().prepare(obj))
>
> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 105, in
> prepare
> values = self.resolve_attributes_lookup(current_objects, attrs)
> ^^
> File "/usr/lib/python3/dist-packages/haystack/fields.py", line 125, in
> resolve_attributes_lookup
> if not hasattr(current_object, attributes[0]):
>^^
> File
> "/usr/lib/python3/dist-packages/django/db/models/fields/related_descriptors.py",
> line 187, in __get__
> rel_obj = self.get_object(instance)
> ^
> File
> "/usr/lib/python3/dist-packages/django/db/models/fields/related_descriptors.py",
> line 154, in get_object
> return qs.get(self.field.get_reverse_related_filter(instance))
>^^^
> File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 431,
> in get
> num = len(clone)
> ^^
> File
Bug#1037498: ITP: weakforced -- Daemon for detecting brute force attacks
De : Jonas Smedegaard À : 1037...@bugs.debian.org Date : 13 juin 2023 16:33:15 Objet : Bug#1037498: ITP: weakforced -- Daemon for detecting brute force attacks > Quoting Pierre-Elliott Bécue (2023-06-13 15:14:15) >> The goal of 'wforce' is to detect brute forcing of passwords across many >> servers, services and instances. In order to support the real world, brute >> force detection policy can be tailored to deal with "bulk, but legitimate" >> users of your service, as well as botnet-wide slowscans of passwords. >> The aim is to support the largest of installations, providing services to >> hundreds of millions of users. >> >> weakforced doesn't have any real alternative for now in Debian as far as I >> can >> see. > > A somewhat related tool already in Debian seems to be crowdsec. > > Just mentioning in case you or others following along might find it > helpful - sounds like weakforced would be useful in Debian regardless. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > * Sponsorship: https://ko-fi.com/drjones > > [x] quote me freely [ ] ask before reusing [ ] keep private Thanks for the pointer ! I clearly missed it ! Cheers, -- Pierre-Elliott Bécue
Bug#1037498: ITP: weakforced -- Daemon for detecting brute force attacks
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: weakforced Version : 2.8.0 Upstream Author : Neil Cook * URL : https://github.com/PowerDNS/weakforced * License : GPL-3 Programming Lang: C++, Python Description : Daemon for detecting brute force attacks The goal of 'wforce' is to detect brute forcing of passwords across many servers, services and instances. In order to support the real world, brute force detection policy can be tailored to deal with "bulk, but legitimate" users of your service, as well as botnet-wide slowscans of passwords. The aim is to support the largest of installations, providing services to hundreds of millions of users. weakforced doesn't have any real alternative for now in Debian as far as I can see. For now these packages will be in collab-maint, but I'll see if they could go somewhere. I'm maintaining them as part of my work at Gandi.net. This is therefore a Gandi.net contribution to the Debian Project.
Bug#1037495: ITP: drogon -- Daemon for detecting brute force attacks
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: drogon Version : 1.8.4 Upstream Author : An Tao * URL : https://github.com/drogonframework/drogon * License : MIT Programming Lang: C++ Description : C++14/17-based HTTP application framework Drogon can be used to easily build various types of web application server programs using C++. Drogon is the name of a dragon in the American TV series "Game of Thrones" that I really like. Drogon is a cross-platform framework, It supports Linux, macOS, FreeBSD, OpenBSD, HaikuOS, and Windows. Its main features are as follows: * Use a non-blocking I/O network lib based on epoll (kqueue under macOS/FreeBSD) to provide high-concurrency, high-performance network IO, please visit the TFB Tests Results for more details; * Provide a completely asynchronous programming mode; * Support Http1.0/1.1 (server side and client side); * Based on template, a simple reflection mechanism is implemented to completely decouple the main program framework, controllers and views. * Support cookies and built-in sessions; * Support back-end rendering, the controller generates the data to the view to generate the Html page. Views are described by CSP template files, C++ codes are embedded into Html pages through CSP tags. And the drogon command-line tool automatically generates the C++ code files for compilation; * Support view page dynamic loading (dynamic compilation and loading at runtime); * Provide a convenient and flexible routing solution from the path to the controller handler; * Support filter chains to facilitate the execution of unified logic (such as login verification, Http Method constraint verification, etc.) before handling HTTP requests; * Support https (based on OpenSSL); * Support WebSocket (server side and client side); * Support JSON format request and response, very friendly to the Restful API application development; * Support file download and upload; * Support gzip, brotli compression transmission; * Support pipelining; * Provide a lightweight command line tool, drogon_ctl, to simplify the creation of various classes in Drogon and the generation of view code; * Support non-blocking I/O based asynchronously reading and writing database PostgreSQL and MySQL(MariaDB) database); * Support asynchronously reading and writing sqlite3 database based on thread pool; * Support Redis with asynchronous reading and writing; * Support ARM Architecture; * Provide a convenient lightweight ORM implementation that supports for regular object-to-database bidirectional mapping; * Support plugins which can be installed by the configuration file at load time; * Support AOP with build-in joinpoints. * Support C++ coroutines This package is needed by weakforced, which I also intend to package. For now these packages will be in collab-maint, but I'll see if they could go somewhere. I'm maintaining them as part of my work at Gandi.net. This is therefore a Gandi.net contribution to the Debian Project.
Bug#1037487: ITP: trantor -- Non-blocking I/O cross-platform TCP network library
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: trantor Version : 1.5.11 Upstream Author : An Tao * URL : https://github.com/an-tao/trantor * License : BSD Programming Lang: C++ Description : Non-blocking I/O cross-platform TCP network library Trantor is a non-blocking I/O cross-platform TCP network library, using C++14. Drawing on the design of Muduo Library This package is needed by weakforced as a transitive dependency of drogon, which I also intend to package. For now these packages will be in collab-maint, but I'll see if they could go somewhere. I'm maintaining them as part of my work at Gandi.net. This is therefore a Gandi.net contribution to the Debian Project.
Bug#1036818: [pkg-lxc-devel] Bug#1036818: Bug#1036818: Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat
Mathias Gibbens wrote on 06/06/2023 at 04:06:14+0200: > [[PGP Signed Part:No public key for 29EEE2D6ECF442F9 created at > 2023-06-06T04:06:14+0200 using RSA]] > On Thu, 2023-06-01 at 18:58 +0200, Pierre-Elliott Bécue wrote: >> > I should have time this weekend when I can spin up a qemu vm to >> > test in, if we're not able to get a root cause identified before >> > then. > > I did try to reproduce the issue over the weekend with qemu. Using > qemu-user-static and systemd-nspawn was insufficient due to lxcfs > needing proper access to the fuse kernel api. After trying and failing > to bootstrap an armhf instance by hand, I grabbed a raspberry pi 2 > bookworm image from raspi.d.n, and got it running under qemu-system- > arm. Within that environment, lxcfs appeared to work correctly > (/var/lib/lxcfs/proc/cpuinfo was correct, no obvious errors or warnings > noticed). I didn't spin up a full lxc container instance within that > environment. > >> I can probably grant you privileges on abel as soon as I get an ack >> from my fellow DSA mates. > > If it's possible to get temporary permissions on abel, that would be > useful. > > One other thing to double check on ci-worker-armhf-01 would be the > contents of /var/lib/lxcfs/proc/cpuinfo, so we can see what lxcfs is > doing from the host side. Unfortunately my teammates have some concerns and I don't have the time for the debate now. What I can do is run any required tests myself. Could you tell me what you wanted to try so that I can try it out for you and report back with the results? -- PEB
Bug#1036818: [pkg-lxc-devel] Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat
De : Mathias Gibbens À : Paul Gevers ; 1036...@bugs.debian.org Cc : Pierre-Elliott Bécue ; Evgeni Golov ; Jochen Sprickerhof Date : 1 juin 2023 13:33:33 Objet : Re: [pkg-lxc-devel] Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat > On Mon, 2023-05-29 at 20:03 +0200, Paul Gevers wrote: >> We have three layers here. The bare metal is arm64. It hosts several >> arm* QEMU VM. Inside the VM we run the lxc. I put the output of all >> three at the bottom. *Maybe* it's relevant that the bare metal still >> runs bullseye while the VM's run bookworm. I'll also share the >> content for an arm64 host (which is a VM where I don't have access to >> the bare metal.) > > [snip] > >> # generating the container and showing inside >> debian@ci-worker-armhf-01:~$ sudo lxc-copy -N elbrus >> autopkgtest-unstable-armhf && sudo lxc-start elbrus && sudo lxc- >> attach elbrus >> root@elbrus:/# cat /proc/cpuinfo >> root@elbrus:/# ls -al /proc/cpuinfo >> -r--r--r-- 1 root root 3878 May 29 17:48 /proc/cpuinfo > > Yeah, that's definitely not right! I don't currently have an > armel/armhf system to test on, but did try using the abel.d.o > porterbox. lxcfs requires elevated permissions to start, which I don't > have on that box. > > Some other things we can look at -- are there any errors/warnings in > the lxcfs service journal and/or the system's dmesg that is running > lxcfs? It might also be useful to start lxcfs with debugging (`-d`) if > there's nothing being logged about populating /proc/cpuinfo. > > I should have time this weekend when I can spin up a qemu vm to test > in, if we're not able to get a root cause identified before then. > > Mathias I can probably grant you privileges on abel as soon as I get an ack from my fellow DSA mates. -- Pierre-Elliott Bécue
Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat
De : Paul Gevers À : 1036...@bugs.debian.org Cc : Evgeni Golov ; Pierre-Elliott Bécue ; Jochen Sprickerhof Date : 29 mai 2023 07:41:30 Objet : Re: Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat > Hi, > > [reducing the people in CC, hope I didn't drop too many and those still there > are interested] > > On Mon, 29 May 2023 00:14:10 + Mathias Gibbens wrote: >> What version of lxcfs is currently installed on the ci.debian.net >> machines? I'm guessing from the kernel version they've been upgraded to >> bookworm, so lxcfs should be at 5.0.3-1, but I'd like to clarify that. > > I just ran $(apt-cache show lxcfs | grep Version) on all the worker hosts and > indeed they all run 5.0.3-1. > >> lxcfs 5.0.3-1 does indeed include the referenced fix for upstream >> issue #553, and has been in testing since 2023-01-22. If the CI >> machines have that version installed, then I'd lean towards a related >> but distinct issue than the one identified at the moment. > > Is there more information I can get for you from one of the effected > architectures? > > Paul > PS: I missed former messages due to a minor mistake in my address, but I'm > now subscribed. I think you should keep gibmat in the Cc list. :) -- Pierre-Elliott Bécue
Bug#1035691: python3-aiosmtpd: unhandled symlink to directory conversion: /usr/share/doc/python3-aiosmtpd/html/_sources -> ../rst
Hi, Le jeudi 25 mai 2023 à 16:25:30+0200, Andreas Beckmann a écrit : > Followup-For: Bug #1035691 > Control: tag -1 patch pending > > I've uploaded a verified fix to DELAYED/1 to reach the bookworm deadline. Could you upload the patch on salsa (branch=master)? Otherwise may I apply in your name that patch on the repo? Will you file the unblock bug or should I do it? Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1036782: mailman3: exim4 configurations not up-to-date
tags 1036782 +moreinfo thanks Hi, Thomas Krichel wrote on 26/05/2023 at 03:10:24+0200: > Package: mailman3 > Version: 3.3.8-1 > Severity: normal > > Dear Maintainer, > > exim4/conf.d/main/25_mm3_macros > exim4/conf.d/transport/55_mm3_transport > > distributed with Mailman3 are not the versions posted at > > https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/mta.html#exim4-configuration > > This leads to mailman3 being unusable with exim4. Use > of the posted configurations in the document above > will fix this. mailman3 doesn't ship these files. No package maintained by the mailman team actually seem to put /etc/exim4/conf.d/main/25_mm3_macros or /etc/exim4/conf.d/transport/55_mm3_transport. Could you please ellaborate on your issue? Regards, -- PEB signature.asc Description: PGP signature
Bug#1010469: [pkg-lxc-devel] Bug#1010469: lxc: as root, lxc-start fails to start with cgroups/cgfsng error setting up limits for devices
Julian Gilbey wrote on 15/05/2023 at 22:05:37+0200: > On Mon, May 15, 2023 at 10:37:32AM +0100, Julian Gilbey wrote: >> [...] >> But now we're back to the original problem cgfsng problem (running >> with --logpriority TRACE): >> >> lxc-start debian-sid 20230515092650.376 WARN cgfsng - >> ../src/lxc/cgroups/cgfsng.c:get_hierarchy:149 - There is no useable devices >> controller >> lxc-start debian-sid 20230515092650.376 ERROR cgfsng - >> ../src/lxc/cgroups/cgfsng.c:cg_legacy_set_data:3098 - No such file >> or directory - Failed to setup limits for the "devices" >> controller. The controller seems to be unused by "cgfsng" cgroup >> driver or not enabled on the cgroup hierarchy >> lxc-start debian-sid 20230515092650.376 ERRORcgfsng - >> ../src/lxc/cgroups/cgfsng.c:cgfsng_setup_limits_legacy:3165 - No such file >> or directory - Failed to set "devices.deny" to "a" >> lxc-start debian-sid 20230515092650.376 ERRORstart - >> ../src/lxc/start.c:lxc_spawn:1893 - Failed to setup legacy device cgroup >> controller limits > > Ah, success! I followed the recipe on > https://wiki.debian.org/LXC/CGroupV2 referenced in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944389 (adding the > lines > > lxc.cgroup.devices.allow = > lxc.cgroup.devices.deny = > > to the end of /var/lib/lxc/debian-sid/config) and it now works. > > But there's no mention of this in /usr/share/doc/lxc/README.Debian.gz, > and I don't need to do this on my other machine, so there's still > something weird going on on this machine. Perhaps it's a hardware > thing? > > Oh joys! > > Best wishes, Ah, I don't remember seeing these logs before, maybe I forgot to ask for a full trace, sorry. Do you see anything in /var/log/audit or /var/log/syslog or /var/log/kern.log about apparmor denies? Cheers, -- PEB signature.asc Description: PGP signature
Bug#1010469: [pkg-lxc-devel] Bug#1010469: Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment
Julian Gilbey wrote on 12/05/2023 at 11:39:33+0200: > On Thu, May 11, 2023 at 11:59:41PM +0200, Pierre-Elliott Bécue wrote: >> >> Julian Gilbey wrote on 11/05/2023 at 16:41:46+0200: >> [...] >> > Hi Pierre-Elliott, >> > >> > I was using debian testing (whatever state it was in at the time). >> > >> > I've just tried reinstalling lxc from scratch with the current debian >> > testing. I haven't been able to get as far as reproducing this error, >> > as I've hit a different snag: >> > [...] > >> > The resulting log file contains the cryptic error messages: >> > >> > lxc-start debian-sid 20230511122856.360 ERROR network - >> > ../src/lxc/network.c:netdev_configure_server_veth:711 - No such file >> > or directory - Failed to attach "vethQ4rt4x" to bridge "lxcbr0", >> > bridge interface doesn't exist >> > >> > That's super-weird; I have no idea what "vethQ4rt4x" is meant to mean. >> >> It's the name the hosts give randomly to the interface it creates for >> the LXC container to get network. >> >> Inside the container it'll be eth0, outside it's a veth intervace, named >> veth$RANDOM stuff. >> >> The issue is in the message: you configured the container to bind this >> interface on a bridge named lxcbr0 that doesn't seem to exist on the >> host. > > Hi Pierre-Elliott, > > Thanks so much for the quick response, that's really helpful! > > Unfortunately, this doesn't seem to be the issue, though: > > # systemctl status lxc-net.service > ● lxc-net.service - LXC network bridge setup > Loaded: loaded (/lib/systemd/system/lxc-net.service; enabled; preset: > enab> > Active: active (exited) since Thu 2023-05-11 20:35:48 BST; 13h ago >Docs: man:lxc > Process: 81843 ExecStart=/usr/libexec/lxc/lxc-net start (code=exited, > statu> >Main PID: 81843 (code=exited, status=0/SUCCESS) > Tasks: 1 (limit: 76868) > Memory: 1.3M > CPU: 70ms > CGroup: /system.slice/lxc-net.service > └─81884 dnsmasq --conf-file=/dev/null -u dnsmasq --strict-order > --> > > May 11 20:35:48 euler systemd[1]: Starting lxc-net.service - LXC network > bridge> > May 11 20:35:48 euler dnsmasq[81884]: started, version 2.89 cachesize 150 > May 11 20:35:48 euler dnsmasq[81884]: compile time options: IPv6 GNU-getopt > DBu> > May 11 20:35:48 euler dnsmasq-dhcp[81884]: DHCP, IP range 10.0.3.2 -- > 10.0.3.25> > May 11 20:35:48 euler dnsmasq-dhcp[81884]: DHCP, sockets bound exclusively to > i> > May 11 20:35:48 euler dnsmasq[81884]: reading /etc/resolv.conf > May 11 20:35:48 euler dnsmasq[81884]: using nameserver 10.0.0.243#53 > May 11 20:35:48 euler dnsmasq[81884]: read /etc/hosts - 7 names > May 11 20:35:48 euler systemd[1]: Finished lxc-net.service - LXC network > bridge> > > And with some details snipped: > > # ifconfig > enp5s0: flags=4163 mtu 1500 > inet [...] netmask 255.255.255.0 broadcast 192.168.0.255 > inet6 [...] prefixlen 64 scopeid 0x20 > ether [...] txqueuelen 1000 (Ethernet) > [...] > > lo: flags=73 mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10 > [...] > > lxcbr0: flags=4099 mtu 1500 > inet 10.0.3.1 netmask 255.255.255.0 broadcast 10.0.3.255 > ether 00:16:3e:00:00:00 txqueuelen 1000 (Ethernet) > RX packets 0 bytes 0 (0.0 B) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 0 bytes 0 (0.0 B) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > tun0: [...] > > wlp3s0: [...] > > > # bridge vlan show > port vlan-id > lxcbr01 PVID Egress Untagged > > > > So lxc-net was established, and it still didn't work :( (And yes, > I've just checked that lxc-start still fails.) But maybe the bridge > is meant to be in the lxc container itself? > > > So I'm still totally stumped. > > Any further ideas/suggestions/things to check would be welcomely > received! > > Best wishes, What do you have in /etc/lxc/lxc-usernet ? Also, what is your container config, please? -- PEB signature.asc Description: PGP signature
Bug#1010469: [pkg-lxc-devel] Bug#1010469: Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment
Julian Gilbey wrote on 11/05/2023 at 16:41:46+0200: > On Mon, Feb 06, 2023 at 11:56:51PM +0100, Pierre-Elliott Bécue wrote: >> >> Julian Gilbey wrote on 08/08/2022 at 15:47:08+0100: >> >> > On Mon, Aug 01, 2022 at 10:44:16PM +0200, Pierre-Elliott Bécue wrote: >> >> Julian Gilbey wrote on 08/06/2022 at 10:50:18+0200: >> >> Hrmpf, this one slipped out of my todolist, I'm sorry for this, this is >> bad. >> >> When you indeed reinstalled your system, which version of Debian did you >> install? >> >> Did you do anything specific before things turned bad again? > > Hi Pierre-Elliott, > > I was using debian testing (whatever state it was in at the time). > > I've just tried reinstalling lxc from scratch with the current debian > testing. I haven't been able to get as far as reproducing this error, > as I've hit a different snag: > > # lxc-create -n debian-sid -t download -- -d debian -r sid -a amd64 > # lxc-start -n debian-sid --logfile /tmp/lxc.log --logpriority DEBUG > lxc-start: debian-sid: ../src/lxc/lxccontainer.c: wait_on_daemonized_start: > 878 Received container state "ABORTING" instead of "RUNNING" > lxc-start: debian-sid: ../src/lxc/tools/lxc_start.c: main: 306 The container > failed to start > lxc-start: debian-sid: ../src/lxc/tools/lxc_start.c: main: 309 To get more > details, run the container in foreground mode > lxc-start: debian-sid: ../src/lxc/tools/lxc_start.c: main: 311 Additional > information can be obtained by setting the --logfile and --logpriority options > > The resulting log file contains the cryptic error messages: > > lxc-start debian-sid 20230511122856.360 ERROR network - > ../src/lxc/network.c:netdev_configure_server_veth:711 - No such file > or directory - Failed to attach "vethQ4rt4x" to bridge "lxcbr0", > bridge interface doesn't exist > > That's super-weird; I have no idea what "vethQ4rt4x" is meant to mean. It's the name the hosts give randomly to the interface it creates for the LXC container to get network. Inside the container it'll be eth0, outside it's a veth intervace, named veth$RANDOM stuff. The issue is in the message: you configured the container to bind this interface on a bridge named lxcbr0 that doesn't seem to exist on the host. > I think this should probably be a separate bug report, though. > Despite some web searching, I have no idea how to fix this problem, > but I now can't use lxc at all :( I think it's something about lxc-net > not connecting the bridging device to the correct network device > (which in my case is enp5s0). enp5s0 is a physical interface, bridging a container directly on it might not achieve what you expect. The usual way is to either use the lxc-net service, or to create a manual bridge (with network/interfaces or systemd-networkd config), allow forwarding on it and the physical interface, and bind the containers on it. You will find some doc on LXC network configuration on LXC's website. :) -- PEB signature.asc Description: PGP signature
Bug#1033917: [pkg-lxc-devel] Bug#1033917: lxc: apparmor profile no longer allows unprivileged guest systemd-logind to start (since bookworm)
Forest wrote on 03/04/2023 at 23:18:10+0200: > Package: lxc > Version: 1:5.0.2-1 > Severity: normal > X-Debbugs-Cc: fores...@sonic.net > > Dear Maintainer, > > After upgrading an unprivileged container from bullseye to bookworm, LXC's > AppArmor profiles are no longer sufficient for the guest's systemd-logind. > > This manifests as a 25 second hang when running certain commands (notably > sudo -i and su -) in the container. It also produces a lot of errors in the > host & guest logs. > > Before the upgrade to bookworm, the hangs did not occur, and systemd-logind > started without trouble. > > > -- Host journal: > > Apr 02 18:30:01 debtesting CRON[6361]: pam_unix(cron:session): session opened > for user root(uid=0) by (uid=0) > Apr 02 18:30:01 debtesting CRON[6362]: (root) CMD ([ -x /etc/init.d/anacron ] > && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start > >/dev/null; fi) > Apr 02 18:30:01 debtesting CRON[6361]: pam_unix(cron:session): session closed > for user root > Apr 02 18:30:16 debtesting audit[6365]: AVC apparmor="DENIED" > operation="mount" info="failed flags match" error=-13 > profile="lxc-container-default-cgns" name="/" pid=6365 comm="(d-logind)" > flags="rw, rslave" > Apr 02 18:30:16 debtesting kernel: kauditd_printk_skb: 13 callbacks suppressed > Apr 02 18:30:16 debtesting kernel: audit: type=1400 > audit(1680485416.414:324): apparmor="DENIED" operation="mount" info="failed > flags match" error=-13 profile="lxc-container-default-cgns" name="/" pid=6365 > comm="(d-logind)" flags="rw, rslave" > Apr 02 18:30:16 debtesting audit[6369]: AVC apparmor="DENIED" > operation="mount" info="failed flags match" error=-13 > profile="lxc-container-default-cgns" name="/" pid=6369 comm="(d-logind)" > flags="rw, rslave" > Apr 02 18:30:16 debtesting kernel: audit: type=1400 > audit(1680485416.426:325): apparmor="DENIED" operation="mount" info="failed > flags match" error=-13 profile="lxc-container-default-cgns" name="/" pid=6369 > comm="(d-logind)" flags="rw, rslave" > Apr 02 18:30:16 debtesting audit[6373]: AVC apparmor="DENIED" > operation="mount" info="failed flags match" error=-13 > profile="lxc-container-default-cgns" name="/" pid=6373 comm="(d-logind)" > flags="rw, rslave" > Apr 02 18:30:16 debtesting kernel: audit: type=1400 > audit(1680485416.450:326): apparmor="DENIED" operation="mount" info="failed > flags match" error=-13 profile="lxc-container-default-cgns" name="/" pid=6373 > comm="(d-logind)" flags="rw, rslave" > Apr 02 18:30:16 debtesting audit[6377]: AVC apparmor="DENIED" > operation="mount" info="failed flags match" error=-13 > profile="lxc-container-default-cgns" name="/" pid=6377 comm="(d-logind)" > flags="rw, rslave" > Apr 02 18:30:16 debtesting kernel: audit: type=1400 > audit(1680485416.522:327): apparmor="DENIED" operation="mount" info="failed > flags match" error=-13 profile="lxc-container-default-cgns" name="/" pid=6377 > comm="(d-logind)" flags="rw, rslave" > Apr 02 18:30:16 debtesting audit[6381]: AVC apparmor="DENIED" > operation="mount" info="failed flags match" error=-13 > profile="lxc-container-default-cgns" name="/" pid=6381 comm="(d-logind)" > flags="rw, rslave" > Apr 02 18:30:16 debtesting kernel: audit: type=1400 > audit(1680485416.534:328): apparmor="DENIED" operation="mount" info="failed > flags match" error=-13 profile="lxc-container-default-cgns" name="/" pid=6381 > comm="(d-logind)" flags="rw, rslave" > > > -- Guest journal: > > Apr 02 18:30:16 lxbox sudo[136]: root : TTY=pts/7 ; PWD=/root ; USER=root > ; COMMAND=/bin/bash > Apr 02 18:30:16 lxbox sudo[136]: pam_limits(sudo-i:session): Could not set > limit for 'core' to soft=0, hard=-1: Operation not permitted; uid=0,euid=0 > Apr 02 18:30:16 lxbox sudo[136]: pam_unix(sudo-i:session): session opened for > user root(uid=0) by (uid=0) > Apr 02 18:30:16 lxbox dbus-daemon[97]: [system] Activating via systemd: > service name='org.freedesktop.login1' > unit='dbus-org.freedesktop.login1.service' requested by ':1.2' (uid=0 pid=136 > comm="sudo -i") > Apr 02 18:30:16 lxbox systemd[1]: Starting modprobe@drm.service - Load Kernel > Module drm... > Apr 02 18:30:16 lxbox (modprobe)[137]: modprobe@drm.service: Executable > /sbin/modprobe missing, skipping: No such file or directory > Apr 02 18:30:16 lxbox systemd[1]: modprobe@drm.service: Deactivated > successfully. > Apr 02 18:30:16 lxbox systemd[1]: Finished modprobe@drm.service - Load Kernel > Module drm. > Apr 02 18:30:16 lxbox systemd[1]: Starting systemd-logind.service - User > Login Management... > Apr 02 18:30:16 lxbox (d-logind)[138]: systemd-logind.service: Failed to set > up mount namespacing: Permission denied > Apr 02 18:30:16 lxbox (d-logind)[138]: systemd-logind.service: Failed at step > NAMESPACE spawning /lib/systemd/systemd-logind: Permission denied > Apr 02 18:30:16 lxbox systemd[1]: systemd-logind.service: Main process > exited, code=exited, status=226/NAMESPACE > Apr 02 18:30:16 lxbox
Bug#1032706: [pkg-lxc-devel] Bug#1032706: lxc-snapshot cannot restore containers with loop storage backend
severity 1032706 important thanks Hi, "Sperl, Mario" wrote on 11/03/2023 at 09:30:06+0100: > Package: lxc > Version: 1:5.0.2-1 > Severity: grave > Justification: causes data loss > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? I tried to generate a snapshot with > lxc-snapshot for a test container that is more than 1G of size. Snapshot > generation does not show any problems but the restore does only restore 1G so > the container is not able to start after restore. >* What exactly did you do (or not do) that was effective (or > ineffective)? One can create a new loop file with correct size and copy > the snapshot contents in here but this renders this command absolute useless > when using loop backend >* What was the outcome of this action? Container cannot start >* What outcome did you expect instead? A container that does start > normally after restoring. Lowering the severity for multiple reasons: 1. The data is not lost, only the changes after the latest snapshot are, as the snapshots are not deleted by a call to restore. The snapshot is actually a full-fledged lxc directory under snaps, that you can reuse almost directly. I admit not losing the changes after the latest snapshot would be better, but I feel that this sole point is not enough to keep the bug as 'grave'; 2. A snapshot should not be restored inplace, as suggested by the command's manpage. The -N option is only useful for restoration and allows one to create a new container based on the snapshot. It's actually this feature that doesn't work when the rootfs is on a loop device ; 3. This bug is tied specifically to a backend little to no user use, other filesystems seem to produce the proper result. If it comes to that, I'd rather remove the loop feature than having LXC out of bookworm. I'll still try to have a proper upstream solution offer before the release. -- PEB signature.asc Description: PGP signature
Bug#1033272: ITP: libre-graph-api-cpp-qt-client -- C++/Qt Libre Graph API client
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libre-graph-api-cpp-qt-client Version : 1.0.1 Upstream Author : Michael Barz * URL : https://github.com/owncloud/libre-graph-api-cpp-qt-client * License : Apache-2.0 Programming Lang: C++ Description : C++/Qt client implementation of Libre Graph API The Libre Graph API is an API for open Cloud Collaboration. It provides an open source standard for open Cloud Collaboration. See the Libre Graph Home for more details. This package is a new dependency on owncloud-client, and will be maintained in the Next-Owncloud Team.
Bug#1010469: [pkg-lxc-devel] Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment
Julian Gilbey wrote on 08/08/2022 at 15:47:08+0100: > On Mon, Aug 01, 2022 at 10:44:16PM +0200, Pierre-Elliott Bécue wrote: >> Julian Gilbey wrote on 08/06/2022 at 10:50:18+0200: >> >> > notfixed 1010469 1:4.0.11-1 >> > thanks >> > >> >> I decided to reinstall my system from scratch, and now this bug has >> >> gone away. So as no-one else could reproduce it and I have no idea >> >> what has changed on my system as a result of reinstalling, I'm closing >> >> it with an "unreproducible" tag. >> > >> > Oh dear, oh dear, oh dear. It's just happened again. >> > >> > I am so completely stumped by this one. >> >> What apparmor profile are you trying to run your container with? > > Dear Pierre-Elliott, > > I'm not sure which profile I'm using; I just installed lxc and am > using whatever the default is. > > Looking at /var/lib/lxc/containername/config, I see the lines: > > lxc.apparmor.profile = generated > lxc.apparmor.allow_nesting = 1 > > which hopefully means something to you! Hrmpf, this one slipped out of my todolist, I'm sorry for this, this is bad. When you indeed reinstalled your system, which version of Debian did you install? Did you do anything specific before things turned bad again? Cheers, -- PEB signature.asc Description: PGP signature
Bug#1030389: [pkg-lxc-devel] Bug#1030389: lxc: Conflict with new systemd cgroup unified hierarchy
Linas Vepstas wrote on 06/02/2023 at 22:59:05+0100: > On Mon, Feb 6, 2023 at 8:29 AM Pierre-Elliott Bécue wrote: > > No, but it sounds plausible that either you don't have apt-listchanges > > I do have apt-listchanges, but Debian auto-updates itself nightly, and > does not inform me of what changes it makes. I don't know how to > disable the auto-update feature. If you have unattended-upgrades installed, Debian indeed self-updates on a daily basis. That being said, it does not change the distro version. The systemd update that made unified cgroups hierarchy the default has been between buster's release and bullseye's release. Hence, the systemd version of buster does *not* break unprivileged containers. As you're on bullseye, it means that you did, at some point, a stable upgrade. And if you were still able to run your unprivileged containers, then either you did reboot when you did your stable upgrade and found out about lxc-unpriv-start, or you did *not* reboot after your stable upgrade. > and therefore didn't read the news entry telling how to make > unprivileged containers work with cgroupsv2, > > My unpriviledged contains have worked *just fine* for a decade! And > then they broke a few days ago. Creating a breaking change that is > silent and incompatible is not acceptable. This took me two days to > debug, and it took down a running server, https://gnucash.org for that > time interval. The breaking change is not silent. It is advertised in the news file of systemd the way *ALL* breaking changes have always been. As Debian does not accept breaking changes on stable versions, they all come with a stable upgrade (when the codename and the major version changes). As these upgrade are supposed to be done by hand, and with apt-listchanges installed (it's installed by default, only people doing specific stuff don't have it, and it's generally not a good idea), you should have be presented the breaking changes on all your packages. As I don't know what your admin practices are, and how you did your buster -> bullseye upgrade, I can't know where it went wrong, but I'm sorry to state that it's not on systemd's side and *certainly not* on LXC's side, as the change made in LXC was only to make it able to work again with unified cgroup hierarchy, which was enabled by systemd v247.2-2. This change has more than 2 years, now. > or you installed directly > LXC on bullseye and didn't read the readme present in > /usr/share/doc/lxc (file: README.Debian.gz). > > It is fundamentally wrong to expect users to be rocket surgeons. Being > unable to boot your system after a power outage is bad. Taking three > days to figure out why your server, that thousands of people depend > on, failed to boot, is a horror. Requiring a PhD in operating system > theory and days plundering the bowels of how this obscure and arcane > subsystem works is not acceptable. What is fundamentally wrong is being aggressive. No one here is your punching ball, and you are not entitled to anything more than the system you get. You are not a customer, and I am not a client support host. Debian, as any Free Operating System requires one to read its documentation, and the changelogs between the releases. In particular, stable upgrades should be done manually, and the documentation we provide allows one to avoid a lot of caveats. It seems clear to me that whatever you did, you did not follow our guidelines. The file I referred to is supposed to be shown by apt-listchanges. Yet, even without that, reading the content of /usr/share/doc is not something obscure or an arcane move, it's what any person should do by default, or at least when they meet a problem. > When you lose electrical power, and get it back again, the system > should be able to boot and run. Blaming me for not reading some > obscure and unknown README file after making a BREAKING CHANGE is > criminal. > > This is representative of the stupid thought that the systemd folks > engage in regularly. I'm tired of spending days trying to repair > systems that worked just fine the day before. Changes to apt packages > should not render a system unbootable. And breaking stuff, ... on > purpose ... just to break it ... that's criminal. You should really get some fresh air before throwing a tantrum in a bug system and present youself quite badly. > I'd punch all of you in the nose if I could. This is just gross > negligence and incompetence. You people need to grow up and stop > acting like Peter Pan. It's' time to behave like responsible, grown > adults. Take some pride in doing good work, instead of crapping on > your users! I'm sorry, but your behaviour is not acceptable. You've clearly not followed the proper guidelines to upgrade your system By doing so, you dug a hole, which you fell in later. And now, you're being aggressive, behaving in a
Bug#1030389: [pkg-lxc-devel] Bug#1030389: lxc: Conflict with new systemd cgroup unified hierarchy
Control: tags -1 -newcomer +wontfix Control: severity -1 normal Hi, Linas Vepstas wrote on 03/02/2023 at 23:17:36+0100: > Package: lxc > Version: 1:4.0.6-2+deb11u1 > Severity: important > Tags: newcomer > X-Debbugs-Cc: linasveps...@gmail.com > > Dear Maintainer, > > Hit the bug described here: > > https://github.com/systemd/systemd/issues/13477 > > and also here: > > https://github.com/lxc/lxc/issues/4072 > > According the the first github report, sometime around 2019 or earlier, > 'systemd now defaults to the "unified" cgroup hierarchy setup' as > explained in the second comment. This means that the directory entry > `/sys/fs/cgroup/systemd` is now missing. This prevents LXC containers > from booting, as explained in the second github report. Running > `lxc-start -F ` reveals the error message: > ``` > Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted > ``` > > There are two known work-arounds, I can confirm that both work. One is > to create the missing cgroup entry mainually: > ``` > mkdir -p /sys/fs/cgroup/systemd && mount -t cgroup cgroup -o > none,name=systemd /sys/fs/cgroup/systemd > ``` > > which is stunningly hacky and inadvisable, but it does confirm the > root cause of the problem: that directory is missing. > > The other work-around is to boot the host and disable the unified > hierarchy, like so: > ``` > # echo 'GRUB_CMDLINE_LINUX=systemd.unified_cgroup_hierarchy=false' > > /etc/default/grub.d/cgroup.cfg > # update-grub > # shutdown -r now > ``` > > Both of these work for me. LXC is 100% unusable without this. How is > it possible that this has not been reported to Debian before? Am I the > only person on the planet using LXC on Debian??? No, but it sounds plausible that either you don't have apt-listchanges and therefore didn't read the news entry telling how to make unprivileged containers work with cgroupsv2, or you installed directly LXC on bullseye and didn't read the readme present in /usr/share/doc/lxc (file: README.Debian.gz). In both cases, LXC is doing fine within Debian, and many people use it on a daily basis. -- PEB
Bug#1028994: [Pkg-mailman-hackers] Bug#1028994: mailman3: (autopkgtest) needs update for Python 3.11
Hi, James Addison wrote on 17/01/2023 at 15:17:43+0100: > Source: mailman3 > Version: 3.3.7-3 > Followup-For: Bug #1028994 > > Dear Maintainer, > > There is hopefully good news relating to this bug: upstream has > discovered the same problem and fixed it after version v3.3.7 - the > fix is included in v3.3.8 of mailman3. > > (the fix includes removal of a 'coroutine' decorator that causes the failure, > instead declaring the associated method using 'async def' instead of 'def') > > See the following links for the changes between the mentioned versions, and > the contents of the fix: > > - https://gitlab.com/mailman/mailman/-/compare/3.3.7...3.3.8 > > - > https://gitlab.com/mailman/mailman/-/commit/1954815f32fea4d9d920cdc74f63bcc24d3b6c49 > > Note: version 3.3.8 of the package retains Python 3.10 support, which > may be helpful if the Debian project decides to rollback to that > version of Python for the upcoming bookworm release. I intend to do a full sweep on mailman suite in the next week, so don't worry too much! :) -- PEB
Bug#997073: apt-cacher-ng: current version stopped working for client (initial error: confusing proxy mode or prohibited port)
Hi Eduard, Pierre-Elliott Bécue wrote on 27/10/2021 at 20:52:10+0100: > [[PGP Signed Part:Signature made by expired key 29BFA0D079290ACA > Pierre-Elliott Bécue ]] > Same issue here: > > Err :1 http://HTTPS///deb.debian.org/debian unstable InRelease > 403 Configuration error (confusing proxy mode) or prohibited port (see > AllowUserPorts) [IP : ::1 3142] > Lecture des listes de paquets... Fait > E: Impossible de récupérer > http://HTTPS///deb.debian.org/debian/dists/unstable/InRelease 403 > Configuration error (confusing proxy mode) or prohibited port (see > AllowUserPorts) [IP : ::1 3142] This reported bug has been hanging since your release of apt-cacher-ng 3.7.3-1. It makes in my case http://HTTPS/// method to fetch https sources not working anymore despite still being documented in the package. Are you aware of this situation? Is it intentional? Could it be fixed via configuration? If it indeed is a bug, do you plan on fixing it before bookworm becomes stable and nobody can use the http://HTTPS feature anymore? Cheers! -- PEB signature.asc Description: PGP signature
Bug#1012636: isync: license conflict with libsasl2
Hi Oswald, Bastian Germann wrote on 12/11/2022 at 16:46:44+0100: > I see that in git there is now LicenseRef-isync-GPL-exception applied to > mbsync. Would you agree to release isync 1.4.5 or do I need to import your license exception? Cheers! -- PEB signature.asc Description: PGP signature
Bug#1013480: hyperkitty: FTBFS: TypeError: __init__() got an unexpected keyword argument 'providing_args'
Charlemagne Lasse wrote on 14/11/2022 at 11:08:06+0100: > Am Mo., 14. Nov. 2022 um 10:53 Uhr schrieb Pierre-Elliott Bécue > : >> I really don't need reminders about the bugs on my packages. > > This is not a reminder. I was just going through the mailman3 packages > to understand what is currently blocking the migration of packages. > And when I found out what is blocking it, I've only checked if this > problem is solved upstream or not. And if it was solved upstream, I > added information about the situation in the already existing bug. Adding tags and links via the appropriate bug commands is indeed helpful, Cc-ing me explicitely and also cc-ing the mailman team list is not the same and is indeed something I feel as putting pressure on me to do the work faster. >> Please refrain from putting pressure on people with the expectation that >> they'll do what you want at the tine you want. >> >> This is the last time I reply to such sollicitations. > > I don't understand why you are so unfriendly. Well, see upwards. The feeling I expressed there is reinforced by your previous communications: on bug #998223, you started to interact by asking the "results" of the new contributors, which I found a bit rude because it felt like they were accountable for something. Never the less, I replied politely that currently we were stuck waiting for upstream to fix the issues with sqlalchemy 1.4 and telling that except someone were to help them, there was nothing we could do. >From that you went on the upstream bug to ask them to work in it: with this: "@msapiro, any idea who to get upstream to have a look at the MR? Possibly before it is too late and everyone kicked out mailman3" I found it a bit rude again, especially since multiple people asked if they had a timeline earlier and they did not reply, I therefore asked you there to stop this behaviour. Then a fix arrived but was not released, and you pinged on november the 4th, and then again, mailman 3.3.7 got released 3 days ago, and on the 13th, you were pinging again and opening a bug to ask 3.3.7 to be packaged. This is no DEFCON1, while I could appreciate a ping two weeks after the release, you let no time to no one to start working on it that you immediately asked us to do so. I had started work on Friday, and decided to not mind and releasing without underlining once again that your enthusiasm was a bit pushy. Then today, you have me receive *6* mails because you Cc-ed me directly + the mailman team list + two bug reports because hyperkitty and django-mailman3 need fixes that were suspended because I preferred to have mailman3 fixed first. I already receive plenty mails, including those you send to the bug report, I really need to not receive multiple copies of mails I already receive, and I also need to be given *at least* a week or two before being asked to fix stuff, *especially* since you know I'm active, having released a first draft for mailman 3.3.7 (which still requires some fixing). So, please, take a breath. Feel free to mail bugs, feel free to add metadata, feel free to submit patches, but don't Cc people on a first message, wait a bit and then ask them if they saw your mails on bugs. I use mailman3, and I would be sad to not be able to make it be in bookworm, I won't ignore the suite, but I need you (and anyone else) to leave me some space, and to remember that we all have a personal life. Cc-ing me is not respecting that. Bests, -- PEB
Bug#1013500: django-mailman3: FTBFS: TypeError: __init__() got an unexpected keyword argument 'providing_args'
De : Charlemagne Lasse À : Pierre-Elliott Bécue ; Debian Mailman Team ; 1013...@bugs.debian.org; Jonas Meurer Date : 14 nov. 2022 10:46:08 Objet : Re: django-mailman3: FTBFS: TypeError: __init__() got an unexpected keyword argument 'providing_args' > Control: tags -1 + fixed-upstream patch > > This problem currently blocks various mailman3 related packages from > migrating to Debian bookwoom. > > But it seems like this is fixed by 1.3.8: > https://pypi.org/project/django-mailman3/ > > (btw. thanks for the mailman 3.3.7 upload) Hi, I really don't need reminders about the bugs on my packages. Please refrain from putting pressure on people with the expectation that they'll do what you want at the tine you want. Regards, -- Pierre-Elliott Bécue
Bug#1013480: hyperkitty: FTBFS: TypeError: __init__() got an unexpected keyword argument 'providing_args'
De : Charlemagne Lasse À : Pierre-Elliott Bécue ; Debian Mailman Team ; Jonas Meurer ; 1013...@bugs.debian.org Date : 14 nov. 2022 10:51:44 Objet : Re: hyperkitty: FTBFS: TypeError: __init__() got an unexpected keyword argument 'providing_args' > Control: tags -1 + fixed-upstream patch > > This problem currently blocks various mailman3 related packages from > migrating to Debian bookwoom. > > But it seems like this is fixed by 1.3.6: > https://docs.mailman3.org/projects/hyperkitty/en/latest/news.html#news-1-3-6 Hi, I really don't need reminders about the bugs on my packages. Please refrain from putting pressure on people with the expectation that they'll do what you want at the tine you want. This is the last time I reply to such sollicitations. Regards, -- Pierre-Elliott Bécue
Bug#998223: Contributors for Mailman 3 in Debian / your RFH
De : Charlemagne Lasse À : Debian Mailman Team ; Amir Sarabadani ; Kunal Mehta ; Moritz Muehlenhoff ; debian-w...@lists.debian.org; Pierre-Elliott Bécue ; Jonas Meurer ; 998...@bugs.debian.org Date : 15 oct. 2022 09:31:10 Objet : Re: Bug#998223: Contributors for Mailman 3 in Debian / your RFH > Hi, > > Where can we find results from the new contributors? Because it looks > at the moment like Debian bookworm might become the third Debian > release (after buster + bullseye) which is unsuitable as a base system > for software project servers (redmine + mailman3 + gitolite). At > least, for the last two releases, redmine was to blame here but now it > looks like mailman3 might be the blocker. > > See also https://lists.debian.org/debian-devel-announce/2022/10/msg4.html > for the Debian bookworm timeline Hi, gitolite has been superseeded by gitolite3 a long time ago, and the latter is in bullseye, in buster and will be in bookworm. See https://tracker.debian.org/pkg/gitolite3 Redmine indeed had troubles. Mailman3 has been part of buster and bullseye, but the release of sqlalchemy 1.4 is not compatible with it and therefore there is a chance that it will not make it in bookworm. There is nothing that any contributor can do except taking the time to help mailman upstream to be fixed and work with sqlalchemy 1.4. Regards. -- Pierre-Elliott Bécue
Bug#1014810: owncloud-client: CVE-2021-44537
Hi, Le mardi 12 juillet 2022 à 12:10:27+0200, Moritz Mühlenhoff a écrit : > Source: owncloud-client > X-Debbugs-CC: t...@security.debian.org > Severity: important > Tags: security > > Hi, > > The following vulnerability was published for owncloud-client. > > CVE-2021-44537[0]: > | ownCloud owncloud/client before 2.9.2 allows Resource Injection by a > | server into the desktop client via a URL, leading to remote code > | execution. > > https://owncloud.com/security-advisories/cve-2021-44537/ > > 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-44537 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44537 > > Please adjust the affected versions in the BTS as needed. Sorry for not including this bug report and CVE in my 2.11.0.8354 release, I had it in mind in July and things fell off because of summer holiday and then I forgot about it. That being said, the 2.11.0.8354 version is not vulnerable which is at least a good thing. I added a fixed-in entry on the bug, if I can do something else to make sure the security tracker is happy, please do tell. Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them.
Bug#768073: Status of package in the NEW queue
Per Lundberg wrote on 06/09/2022 at 10:36:00+0200: > Hi, > > I think we are probably a number of people excited to see this (soon!) > finally making it into Debian proper. :) I am currently running LXD as > a snap, but it would just be so much nicer and cleaner to be able to > use the "real" packages for this. > > The package is currently in the Debian "new" queue, where it has been since > August 4: https://ftp-master.debian.org/new/lxd_5.0.0-1.html > > Are there any impediments from seeing this making its way into > unstable/experimental anytime soon, or is it just a matter of the FTP masters > not having had time to look into it yet? > > Best regards, Something stays in NEW until a ftpmaster has time to review it. From there, either it's accepted or rejected, but in both cases it gets out from NEW. Nothing can be done on our side, except asking ftpmasters to review faster, but it's something to do only in urgent cases, and a new package, even as exciting as LXD, is anything but urgent. Cheers! -- PEB signature.asc Description: PGP signature
Bug#1010469: [pkg-lxc-devel] Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment
Julian Gilbey wrote on 08/06/2022 at 10:50:18+0200: > notfixed 1010469 1:4.0.11-1 > thanks > >> I decided to reinstall my system from scratch, and now this bug has >> gone away. So as no-one else could reproduce it and I have no idea >> what has changed on my system as a result of reinstalling, I'm closing >> it with an "unreproducible" tag. > > Oh dear, oh dear, oh dear. It's just happened again. > > I am so completely stumped by this one. What apparmor profile are you trying to run your container with? -- PEB signature.asc Description: PGP signature
Bug#1011589: Updating the transcend Uploaders list
Source: transcend Version: 0.3.dfsg2-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the transcend package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011588: Updating the taoframework Uploaders list
Source: taoframework Version: 2.1.svn20090801-14.1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the taoframework package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011587: Updating the supertuxkart Uploaders list
Source: supertuxkart Version: 1.2+ds2-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the supertuxkart package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011586: Updating the powermanga Uploaders list
Source: powermanga Version: 0.93.1-4 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the powermanga package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011585: Updating the pangzero Uploaders list
Source: pangzero Version: 1.4.1+git20121103-5 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the pangzero package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011584: Updating the nikwi Uploaders list
Source: nikwi Version: 0.0.20120213-4 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the nikwi package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011582: Updating the kxl Uploaders list
Source: kxl Version: 1.1.7-17 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the kxl package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011583: Updating the libsdl2 Uploaders list
Source: libsdl2 Version: 2.0.14+dfsg2-3 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the libsdl2 package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011581: Updating the ketm Uploaders list
Source: ketm Version: 0.0.6-25 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the ketm package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011580: Updating the kanatest Uploaders list
Source: kanatest Version: 0.4.8-4 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the kanatest package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011579: Updating the hex-a-hop Uploaders list
Source: hex-a-hop Version: 1.1.0+git20140926-1.1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the hex-a-hop package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011578: Updating the freealut Uploaders list
Source: freealut Version: 1.1.0-6 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the freealut package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011577: Updating the clanlib Uploaders list
Source: clanlib Version: 1.0~svn3827-8 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the clanlib package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011576: Updating the chromium-bsu Uploaders list
Source: chromium-bsu Version: 0.9.16.1-2 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the chromium-bsu package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011574: O: zzuf -- transparent application fuzzer
Package: wnpp The current maintainer of zzuf, Sam Hocevar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: zzuf Binary: zzuf Version: 0.15-1 Maintainer: Sam Hocevar Build-Depends: debhelper (>= 9.0), dh-autoreconf Architecture: any Standards-Version: 3.9.7 Format: 3.0 (quilt) Files: 048fd6378308968f168d54b2491826c7 1617 zzuf_0.15-1.dsc 660781890c98a394c7d5996d1d4259b2 493559 zzuf_0.15.orig.tar.gz 6cff2d47b6aee561d26df084d8168de5 2972 zzuf_0.15-1.debian.tar.xz Checksums-Sha256: 98b0f16e2071828acd4f78bc78a62284b1a817d137c47be526e63c99ad493150 1617 zzuf_0.15-1.dsc a34f624503e09acd269c70d826aac2a35c03e84dc351873f140f0ba6a792ffd6 493559 zzuf_0.15.orig.tar.gz 4326410bf40142b1784292240d95d44903b8873e14f78aaef6133f8b9be015fb 2972 zzuf_0.15-1.debian.tar.xz Package-List: zzuf deb devel optional arch=any Directory: pool/main/z/zzuf Priority: source Section: devel Package: zzuf Source: zzuf (0.15-1) Version: 0.15-1+b1 Installed-Size: 175 Maintainer: Sam Hocevar Architecture: amd64 Depends: libc6 (>= 2.15) Description-en: transparent application fuzzer Zzuf is a transparent fuzzer. It works by intercepting applications' file and network operations and changing random bits in their input. Its behaviour is deterministic, making it easy to reproduce bugs. . Zzuf has support for variable fuzzing ratio, character filtering, fuzzing decision based on filenames and optional network fuzzing. It can also stop processes that run for too long or that output too much data. Description-md5: 27dbe1f74dc9503e917a86ba5a96a833 Tag: implemented-in::c, role::program Section: devel Priority: optional Filename: pool/main/z/zzuf/zzuf_0.15-1+b1_amd64.deb Size: 62246 MD5sum: 51f2e27b3b819b276078135dc3793375 SHA256: 30947ff9d6d7b55b337848e1440d3119ac4deb45f021c6d588f34f914347051a -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011575: Updating the asc Uploaders list
Source: asc Version: 2.6.1.0-7 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Sam Hocevar has not been working on the asc package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011573: O: yasm -- modular assembler with multiple syntaxes support
Package: wnpp The current maintainer of yasm, Sam Hocevar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: yasm Binary: yasm Version: 1.3.0-2.1 Maintainer: Sam Hocevar Build-Depends: debhelper (>= 9.0), dh-autoreconf, bison, gettext, xmlto, python2 Architecture: any Standards-Version: 3.9.6 Format: 3.0 (quilt) Files: cc3fda7934f6a0285e44bafd2d395b8b 1895 yasm_1.3.0-2.1.dsc fc9e586751ff789b34b1f21d572d96af 1492156 yasm_1.3.0.orig.tar.gz c8cce265f0cfad7b3955ad98e6fb892e 8256 yasm_1.3.0-2.1.debian.tar.xz Vcs-Browser: http://svn.debian.org/wsvn/sam-hocevar/pkg-misc/unstable/yasm/ Vcs-Svn: svn://svn.debian.org/sam-hocevar/pkg-misc/unstable/yasm Checksums-Sha256: 35f87f5d8f8f123643a244d76006b6f772af72c5148ab87ec4e189aec9b37373 1895 yasm_1.3.0-2.1.dsc 3dce6601b495f5b3d45b59f7d2492a340ee7e84b5beca17e48f862502bd5603f 1492156 yasm_1.3.0.orig.tar.gz 473e9f318bd274dee92db4ee3247f7e64cd709a569ce1825fdf935cd01490409 8256 yasm_1.3.0-2.1.debian.tar.xz Homepage: http://www.tortall.net/projects/yasm/ Package-List: yasm deb devel optional arch=any Directory: pool/main/y/yasm Priority: source Section: devel Package: yasm Version: 1.3.0-2.1 Installed-Size: 2131 Maintainer: Sam Hocevar Architecture: amd64 Depends: libc6 (>= 2.14) Description-en: modular assembler with multiple syntaxes support Yasm is a complete rewrite of the NASM assembler. It supports multiple assembler syntaxes (eg, NASM, GAS, TASM, etc.) in addition to multiple output object formats (binary objects, COFF, Win32, ELF32, ELF64) and even multiple instruction sets (including AMD64). It also has an optimiser module. Description-md5: dea64a38f47da6fb51ac8a3e78582601 Multi-Arch: foreign Homepage: http://www.tortall.net/projects/yasm/ Tag: devel::compiler, devel::machinecode, implemented-in::c, role::program Section: devel Priority: optional Filename: pool/main/y/yasm/yasm_1.3.0-2.1_amd64.deb Size: 409260 MD5sum: 1c1c1f750d842763a319a26aef05ed36 SHA256: 0298de20ea7666c31ea2d085d9a140263405cef81db8c9fae0497cf2b5ff5b85 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011572: O: toilet -- display large colourful characters in text mode
Package: wnpp The current maintainer of toilet, Sam Hocevar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: toilet Binary: toilet, toilet-fonts Version: 0.3-1.3 Maintainer: Sam Hocevar Build-Depends: debhelper (>= 5.0), pkg-config, libcaca-dev (>= 0.99.beta18), zlib1g-dev, autotools-dev Architecture: any all Standards-Version: 3.9.3 Format: 3.0 (quilt) Files: df4a4353207597e5dc1996f331f17204 1907 toilet_0.3-1.3.dsc 9b72591cb22a30c42a3184b17cabca6f 864880 toilet_0.3.orig.tar.gz ccb48027e0dbd3b483784bfcf7b166a8 3440 toilet_0.3-1.3.debian.tar.xz Vcs-Browser: http://svn.debian.org/wsvn/sam-hocevar/pkg-misc/unstable/toilet/ Vcs-Svn: svn://svn.debian.org/sam-hocevar/pkg-misc/unstable/toilet Checksums-Sha256: a780abc711b6e7a9fe1f758f049b00ce35b542e39edc4af8017875bc2df2d83f 1907 toilet_0.3-1.3.dsc 89d4b530c394313cc3f3a4e07a7394fa82a6091f44df44dfcd0ebcb3300a81de 864880 toilet_0.3.orig.tar.gz 18a7abb885ac16a23e136f4a73ae8ce0841a5ad6d0bd42eb8b0e908e1d9fbd50 3440 toilet_0.3-1.3.debian.tar.xz Package-List: toilet deb text optional arch=any toilet-fonts deb text optional arch=all Directory: pool/main/t/toilet Priority: source Section: text -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011571: O: rinetd -- Internet TCP redirection server
Package: wnpp The current maintainer of rinetd, Sam Hocevar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: rinetd Binary: rinetd Version: 0.62.1sam-1.1 Maintainer: Sam Hocevar Build-Depends: debhelper (>= 9.0), dh-autoreconf Architecture: any Standards-Version: 3.9.6 Format: 3.0 (quilt) Files: 2848490a1633f63ed987cb3f53843499 1715 rinetd_0.62.1sam-1.1.dsc 9bfd549eda816d7ca05ef33d1db663c7 115120 rinetd_0.62.1sam.orig.tar.gz 69ea4a30e05002b7717e8cb53e2aa0aa 4024 rinetd_0.62.1sam-1.1.debian.tar.xz Checksums-Sha256: 72a4e225232ad1e7847dcf2ba10e685a1295a5572efbdcac4bd3da3fb9d90c3e 1715 rinetd_0.62.1sam-1.1.dsc fd04fd75d0035349c6210957d1cf964c22e8daac58f96e4e7cdbc3d4795699fb 115120 rinetd_0.62.1sam.orig.tar.gz 8382179cfcaad05283de1b729e2662d3cc2548a2f4942f5d2a6d79690b970083 4024 rinetd_0.62.1sam-1.1.debian.tar.xz Package-List: rinetd deb net optional arch=any Directory: pool/main/r/rinetd Priority: source Section: net Package: rinetd Version: 0.62.1sam-1.1 Installed-Size: 73 Maintainer: Sam Hocevar Architecture: amd64 Depends: libc6 (>= 2.15) Description-en: Internet TCP redirection server rinetd redirects TCP connections from one IP address and port to another, with basic IP-based access control. . rinetd is a single-process server which handles any number of connections to the address/port pairs specified in the file /etc/rinetd.conf. Since rinetd runs as a single process using nonblocking I/O, it is able to redirect a large number of connections without a severe impact on the machine. This makes it practical to run services on machines inside an IP masquerading firewall. Description-md5: c779dc6fda8c28eb8fd8878f71d69c09 Tag: interface::daemon, network::server, network::service, role::program, use::proxying Section: net Priority: optional Filename: pool/main/r/rinetd/rinetd_0.62.1sam-1.1_amd64.deb Size: 22236 MD5sum: 6f7740540f0f94422188f7d8608fec29 SHA256: ea7462047c7b3fa7e694bbfebb5f3832af6201947ec35d9bba4c61cd9756a552 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011568: O: gtkgl2 -- OpenGL context support for GTK+ (development files)
Package: wnpp The current maintainer of gtkgl2, Sam Hocevar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: gtkgl2 Binary: libgtkgl2.0-dev, libgtkgl2.0-1 Version: 2.1.0-0.3 Maintainer: Sam Hocevar Build-Depends: debhelper-compat (= 13), libgl-dev, libgtk2.0-dev Architecture: any Standards-Version: 4.5.0 Format: 3.0 (quilt) Files: ea16ab8c25f583dad61ed798ce006c2a 1904 gtkgl2_2.1.0-0.3.dsc 8d9c2008dff97c7ada0e416025ea0e79 57136 gtkgl2_2.1.0.orig.tar.xz 65919dcc6aa2b7a5de6929753bae5b5a 6740 gtkgl2_2.1.0-0.3.debian.tar.xz Checksums-Sha256: 7fabb978b746e69f002575cb67cc836e987478a1a69dfce70b4417b7a33aee52 1904 gtkgl2_2.1.0-0.3.dsc 8a4aa97b39fdefdf6d9f133afbecb9c198acf467da8de4a5eb04727a59965c1a 57136 gtkgl2_2.1.0.orig.tar.xz 0f62424a248d619bf5835e12e25f4bdb4753166977251dae290533b9fff19164 6740 gtkgl2_2.1.0-0.3.debian.tar.xz Homepage: http://www.mono-project.com/GtkGLArea Package-List: libgtkgl2.0-1 deb libs optional arch=any libgtkgl2.0-dev deb libdevel optional arch=any Testsuite: autopkgtest Testsuite-Triggers: gcc, pkg-config, xauth, xvfb Directory: pool/main/g/gtkgl2 Priority: source Section: libs -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011569: O: elk -- scheme interpreter
Package: wnpp The current maintainer of elk, Sam Hocevar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: elk Binary: elk, libelk0, libelk0-dev, elkdoc Version: 3.99.8-4.2 Maintainer: Sam Hocevar Build-Depends: debhelper (>= 9.0), dh-autoreconf, groff, libelf-dev, libx11-dev, libxext-dev, libxmu-dev, libxt-dev, libice-dev, libsm-dev, libmotif-dev, libgdbm-dev, libxaw7-dev Architecture: any all Standards-Version: 3.9.6 Format: 3.0 (quilt) Files: cd8714fe75a00a8041ca911732d0cb2b 2086 elk_3.99.8-4.2.dsc 1e929fc5159dcb81d1c747f2351a6a19 879908 elk_3.99.8.orig.tar.gz 460e84869f4cffd3ad86685a60c70c3c 8156 elk_3.99.8-4.2.debian.tar.xz Vcs-Browser: https://salsa.debian.org/debian/elk Vcs-Git: https://salsa.debian.org/debian/elk.git Checksums-Sha256: 19fcee63132a88837e12e13e66b14bdd600a5428fd1e0e316f782e376b53e287 2086 elk_3.99.8-4.2.dsc 1db2b6b92a693b056c597aaf5cddc617a640bd6b24a218a725286d7490117cf9 879908 elk_3.99.8.orig.tar.gz afd4c595a19db8798f7afdde22c90fbf1a49df3574db1792da22f368d5fa5376 8156 elk_3.99.8-4.2.debian.tar.xz Homepage: http://sam.zoy.org/elk/ Package-List: elk deb interpreters optional arch=any elkdoc deb doc optional arch=all libelk0 deb libs optional arch=any libelk0-dev deb libdevel optional arch=any Directory: pool/main/e/elk Priority: source Section: lisp -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011570: O: libcaca -- development files for libcaca
Package: wnpp The current maintainer of libcaca, Sam Hocevar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: libcaca Binary: libcaca-dev, libcaca0, caca-utils Version: 0.99.beta19-2.2 Maintainer: Sam Hocevar Build-Depends: debhelper (>= 8.1.3~), dh-autoreconf, pkg-config, libncursesw5-dev, libslang2-dev, libx11-dev, libimlib2-dev, freeglut3-dev, texlive-fonts-recommended, doxygen-latex Architecture: any Standards-Version: 3.9.3 Format: 3.0 (quilt) Files: cca202f9263a97fd8a5b0bc59da60e4b 2379 libcaca_0.99.beta19-2.2.dsc a3d4441cdef488099f4a92f4c6c1da00 1203495 libcaca_0.99.beta19.orig.tar.gz 20672594f1b274f7dfef1ac3ff7c758a 15020 libcaca_0.99.beta19-2.2.debian.tar.xz Vcs-Browser: http://svn.debian.org/wsvn/sam-hocevar/pkg-misc/unstable/libcaca/ Vcs-Svn: svn://svn.debian.org/sam-hocevar/pkg-misc/unstable/libcaca Checksums-Sha256: 104441468035910d534efea7cfb3f297ebbea634debf5fcb042101d6eb44e2bd 2379 libcaca_0.99.beta19-2.2.dsc 128b467c4ed03264c187405172a4e83049342cc8cc2f655f53a2d0ee9d3772f4 1203495 libcaca_0.99.beta19.orig.tar.gz 98eef7fc803224cbabc226f1e6488b25316f0b6282077db02d8cb490a5a919dc 15020 libcaca_0.99.beta19-2.2.debian.tar.xz Homepage: http://caca.zoy.org/wiki/libcaca Package-List: caca-utils deb utils optional arch=any libcaca-dev deb libdevel optional arch=any libcaca0 deb libs optional arch=any Testsuite: autopkgtest Testsuite-Triggers: build-essential, pkg-config Directory: pool/main/libc/libcaca Priority: source Section: libs -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1011563: O: ftgl -- development files for libftgl
Package: wnpp The current maintainer of ftgl, Sam Hocevar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: ftgl Binary: libftgl-dev, libftgl2 Version: 2.4.0-2.1 Maintainer: Sam Hocevar Uploaders: Manuel A. Fernandez Montecelo Build-Depends: debhelper (>= 11~), freeglut3-dev, libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev, libfreetype6-dev (>> 2.0.9), libcppunit-dev, doxygen-latex, ghostscript, imagemagick, pkg-config, texlive-fonts-recommended Architecture: any Standards-Version: 4.2.1 Format: 3.0 (quilt) Files: 82eafe9657162d8db1721bde68e60a22 2110 ftgl_2.4.0-2.1.dsc d040f3e78f34f5ebd1db2d2fd5c25501 529408 ftgl_2.4.0.orig.tar.xz a689c11e1d7c8e9b97168c3a67d48d1c 9236 ftgl_2.4.0-2.1.debian.tar.xz Vcs-Browser: https://salsa.debian.org/ftgl-team/ftgl Vcs-Git: https://salsa.debian.org/ftgl-team/ftgl.git Checksums-Sha256: d2e7044812b978d5e20ab9e0d0761e49a244744843617d57d78c95610aa2d19b 2110 ftgl_2.4.0-2.1.dsc e3e07a4b4aa5db98d69c621887001dc21b0cfce607868c0e0e4e37bcc7558676 529408 ftgl_2.4.0.orig.tar.xz 9f0151ea6dcc4913fd217a9425f4917dc765743feb960e90a4b4ba5891d9b1aa 9236 ftgl_2.4.0-2.1.debian.tar.xz Homepage: https://github.com/frankheckenbach/ftgl Package-List: libftgl-dev deb libdevel optional arch=any libftgl2 deb libs optional arch=any Directory: pool/main/f/ftgl Priority: source Section: devel
Bug#1011565: O: clif -- C language interpreter
Package: wnpp The current maintainer of clif, Sam Hocevar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: clif Binary: clif Version: 0.93-9.1 Maintainer: Sam Hocevar Build-Depends: debhelper (>= 5.0), libx11-dev, libxt-dev, texlive, libelf-dev Architecture: any Standards-Version: 3.8.3 Format: 3.0 (quilt) Files: e1b991c0998d69291315a0c216d36eff 1318 clif_0.93-9.1.dsc a8df47654860fb1fcf6833c716b2a3ee 537384 clif_0.93.orig.tar.gz 6025625e75e3ea058e9ba048551c7c77 19564 clif_0.93-9.1.debian.tar.xz Checksums-Sha256: 97b90f942e06da1e4afc00eb67ca70ea4fe353f2b435bbeedf7a20b259fbc24c 1318 clif_0.93-9.1.dsc e15075c1279cf2f85de27ae599f0fee2a4f11737ea96a26c055660662f15be69 537384 clif_0.93.orig.tar.gz 547a58c0cbcd2f6505a027aa35aac1debd37a2fcc99fc4cb96fc61feee8758f5 19564 clif_0.93-9.1.debian.tar.xz Package-List: clif deb interpreters optional arch=any Directory: pool/main/c/clif Priority: source Section: interpreters Package: clif Source: clif (0.93-9.1) Version: 0.93-9.1+b1 Installed-Size: 1424 Maintainer: Sam Hocevar Architecture: amd64 Depends: libc6 (>= 2.14), libelf1 (>= 0.131), libx11-6 Description-en: C language interpreter Clif, a C-like Interpreter Framework, is and open-ended system for fast development of programs with C syntax. The program is compiled and if syntactically correct, code is immediately generated. The code is generated for a virtual machine. The virtual machine is a part of the framework. Description-md5: 9a25d6e0da8cf54ff392b50fd5fa344a Tag: devel::interpreter, devel::lang:c, devel::library, implemented-in::c, interface::commandline, role::devel-lib, role::program, scope::utility, works-with::software:source Section: interpreters Priority: optional Filename: pool/main/c/clif/clif_0.93-9.1+b1_amd64.deb Size: 1199388 MD5sum: 6505ca9064b4c886482941e6c7e79ed8 SHA256: ba9165674b72ffa1e49fb581c5357137d83aa98a662c6ebd8af7dbddd870e1b2
Bug#1011564: O: bvi -- binary file editor
Package: wnpp The current maintainer of bvi, Sam Hocevar , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: bvi Binary: bvi Version: 1.4.0-1 Maintainer: Sam Hocevar Build-Depends: debhelper (>= 9.0), dh-autoreconf, libncurses5-dev Architecture: any Standards-Version: 3.9.6 Format: 3.0 (quilt) Files: c456c5e02f8194f01c1e66843f81a3d9 1777 bvi_1.4.0-1.dsc aa83eb8b2b6b0bb6cdd8e6beef12b775 139202 bvi_1.4.0.orig.tar.gz b4fa29bdabcd64c12c0b36603097d55a 2676 bvi_1.4.0-1.debian.tar.xz Vcs-Browser: http://svn.debian.org/wsvn/sam-hocevar/pkg-misc/unstable/bvi/ Vcs-Svn: svn://svn.debian.org/svn/sam-hocevar/pkg-misc/unstable/bvi Checksums-Sha256: 300b714e2cfb233c31333ee4da79ae37d00ee72c965f5833b42f5dc0f57e0bb0 1777 bvi_1.4.0-1.dsc 015a3c2832c7c097d98a5527deef882119546287ba8f2a70c736227d764ef802 139202 bvi_1.4.0.orig.tar.gz 959c7e0ff5e09a0e892e51fee2a157e3a61fff0cb185f8398dacfdcdc8cfbb85 2676 bvi_1.4.0-1.debian.tar.xz Package-List: bvi deb editors optional arch=any Directory: pool/main/b/bvi Priority: source Section: editors Package: bvi Source: bvi (1.4.0-1) Version: 1.4.0-1+b3 Installed-Size: 275 Maintainer: Sam Hocevar Architecture: amd64 Depends: libc6 (>= 2.14), libncurses6 (>= 6), libtinfo6 (>= 6) Description-en: binary file editor The bvi is a display-oriented editor for binary files, based on the vi text editor. If you are familiar with vi, just start the editor and begin to edit! If you never heard about vi, maybe bvi is not the best choice for you. Description-md5: 82e028998d9812c24a56e1a511b425cd Tag: interface::text-mode, role::program, scope::utility, uitoolkit::ncurses, use::editing, works-with::file Section: editors Priority: optional Filename: pool/main/b/bvi/bvi_1.4.0-1+b3_amd64.deb Size: 58272 MD5sum: 5b4e2f002b9ac1bd2da075bc70c7eb7e SHA256: 1fe1c58c49b4a11c44f5b624eacd656a0a4756d68d29c9b6cb4d9cbb4f6f36de
Bug#1003566: Please modify your dependencies from python3-mistune to python3-mistune0
Pierre-Elliott Bécue wrote on 24/02/2022 at 22:04:28+0100: > [[PGP Signed Part:Good signature from 29BFA0D079290ACA Pierre-Elliott Bécue > (trust ultimate) created at 2022-02-24T22:36:30+0100 using > RSA]] > Hi, > > Following up some exchanges, we agreed within the Python Team to > reupload mistune 0.8.4 under the mistune0 source package. As it passed > NEW, I'm currently doing a sourceful upload and replacing any occurence > of mistune in this package by mistune0. > > Therefore, in 15 days, I'll make all these bugs RC, in order to be able > to update src:mistune to mistune v2 no later than the end of March. > > To rely on python3-mistune0, add it as a dependency of your package, and > make a Debian patch to replace any occurrence of a mistune import or > usage to mistune0. > > This is not ideal, but I guess upstreams will make themselves compatible > with mistune v2 in some future and you'll be able to drop such patches. > > In the meantime, this avoids conflicts between mistune 0.8.4 and 2.0.0 > as both can be installed, and this also allows for things depending on > mistune v2 to enter testing. > > With best regards, As announced, making these bugs RC. I intend to upload the new release of mistune2 on April the 1st. Cheers! -- PEB signature.asc Description: PGP signature
Bug#1002376: Fwd: Please modify your dependencies from python3-mistune to python3-mistune0
Sorry for not mailing that to you too. There's a mistune0 package that will allow you to fix that bug, while I'll upload soon an update of python3-mistune. See the forwarded message below. Pierre-Elliott Bécue wrote on 24/02/2022 at 22:04:28+0100: > [[PGP Signed Part:Good signature from 29BFA0D079290ACA Pierre-Elliott Bécue > (trust ultimate) created at 2022-02-24T22:36:30+0100 using > RSA]] > Hi, > > Following up some exchanges, we agreed within the Python Team to > reupload mistune 0.8.4 under the mistune0 source package. As it passed > NEW, I'm currently doing a sourceful upload and replacing any occurence > of mistune in this package by mistune0. > > Therefore, in 15 days, I'll make all these bugs RC, in order to be able > to update src:mistune to mistune v2 no later than the end of March. > > To rely on python3-mistune0, add it as a dependency of your package, and > make a Debian patch to replace any occurrence of a mistune import or > usage to mistune0. > > This is not ideal, but I guess upstreams will make themselves compatible > with mistune v2 in some future and you'll be able to drop such patches. > > In the meantime, this avoids conflicts between mistune 0.8.4 and 2.0.0 > as both can be installed, and this also allows for things depending on > mistune v2 to enter testing. > > With best regards, signature.asc Description: PGP signature -- PEB signature.asc Description: PGP signature
Bug#1003565: [Pkg-matrix-maintainers] Bug#1003565: Please modify your dependencies from python3-mistune to python3-mistune0
Jonas Smedegaard wrote on 25/02/2022 at 00:00:17+0100: > [[PGP Signed Part:No public key for 2C7C3146C1A00121 created at > 2022-02-25T00:00:14+0100 using RSA]] > Quoting Pierre-Elliott Bécue (2022-02-24 23:33:04) >> Le 24 février 2022 23:11:51 GMT+01:00, Jonas Smedegaard a >> écrit : >> >Quoting Pierre-Elliott Bécue (2022-02-24 22:52:24) >> >> >> >> Jonas Smedegaard wrote on 24/02/2022 at 22:44:03+0100: >> >> >> >> > Quoting Pierre-Elliott Bécue (2022-02-24 22:04:28) >> >> >> Following up some exchanges, we agreed within the Python Team to >> >> >> reupload mistune 0.8.4 under the mistune0 source package. As it >> >> >> passed NEW, I'm currently doing a sourceful upload and replacing >> >> >> any occurence of mistune in this package by mistune0. >> >> > >> >> > Please in future post only to not already closed bugreports ;-) >> >> >> >> As you'll have work to do, I'm sorry but I stand by my mail sent to >> >> your already closed bugreports. :) >> > >> >If you mean *different* work than what you have described above >> >(believed already done for bugs #1002163 #1003571 #1003565) then >> >please elaborate what work is - when you reopen the bugreports (no >> >need to elaborate now). > >> I am not convinced that you did that : >> >> > and make a Debian patch to replace any occurrence of a mistune >> > import or usage to mistune0. >> >> Of course maybe I misread the changes you made in m2r. > > Ahh, I totally missed the detail that the package you introduced to > unstable was broken and had to be redesigned, before relying on it. It was not unusable, but was still conflicting with python3-mistune, as it was installing on the same paths. To allow both to coexist, one had to use different paths, and the solution designed was to have the old mistune be installed as "mistune0" in /u/l/python3/dist-packages. Now it's done and in testing, feel free to patch your package accordingly! Theoretically it's just a s/mistune/mistune0/g in all .py files, setup.py and requirements.txt. Cheers! -- PEB signature.asc Description: PGP signature
Bug#1003565: [Pkg-matrix-maintainers] Bug#1003565: Please modify your dependencies from python3-mistune to python3-mistune0
Le 24 février 2022 23:11:51 GMT+01:00, Jonas Smedegaard a écrit : >Quoting Pierre-Elliott Bécue (2022-02-24 22:52:24) >> >> Jonas Smedegaard wrote on 24/02/2022 at 22:44:03+0100: >> >> > [[PGP Signed Part:No public key for 2C7C3146C1A00121 created at >> > 2022-02-24T22:44:00+0100 using RSA]] >> > Quoting Pierre-Elliott Bécue (2022-02-24 22:04:28) >> >> Following up some exchanges, we agreed within the Python Team to >> >> reupload mistune 0.8.4 under the mistune0 source package. As it >> >> passed NEW, I'm currently doing a sourceful upload and replacing >> >> any occurence of mistune in this package by mistune0. >> > >> > Please in future post only to not already closed bugreports ;-) >> >> As you'll have work to do, I'm sorry but I stand by my mail sent to >> your already closed bugreports. :) > >If you mean *different* work than what you have described above >(believed already done for bugs #1002163 #1003571 #1003565) then please >elaborate what work is - when you reopen the bugreports (no need to >elaborate now). > > >Kind regards, > > - Jonas > >-- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private I am not convinced that you did that : > and make a Debian patch to replace any occurrence of a > mistune import or usage to mistune0. Of course maybe I misread the changes you made in m2r. Cheers, -- Pierre-Elliott Bécue From my phone
Bug#1003565: [Pkg-matrix-maintainers] Bug#1003565: Please modify your dependencies from python3-mistune to python3-mistune0
Jonas Smedegaard wrote on 24/02/2022 at 22:44:03+0100: > [[PGP Signed Part:No public key for 2C7C3146C1A00121 created at > 2022-02-24T22:44:00+0100 using RSA]] > Quoting Pierre-Elliott Bécue (2022-02-24 22:04:28) >> Following up some exchanges, we agreed within the Python Team to >> reupload mistune 0.8.4 under the mistune0 source package. As it passed >> NEW, I'm currently doing a sourceful upload and replacing any >> occurence of mistune in this package by mistune0. > > Please in future post only to not already closed bugreports ;-) As you'll have work to do, I'm sorry but I stand by my mail sent to your already closed bugreports. :) Cheers! -- PEB signature.asc Description: PGP signature
Bug#1003565: Please modify your dependencies from python3-mistune to python3-mistune0
Hi, Following up some exchanges, we agreed within the Python Team to reupload mistune 0.8.4 under the mistune0 source package. As it passed NEW, I'm currently doing a sourceful upload and replacing any occurence of mistune in this package by mistune0. Therefore, in 15 days, I'll make all these bugs RC, in order to be able to update src:mistune to mistune v2 no later than the end of March. To rely on python3-mistune0, add it as a dependency of your package, and make a Debian patch to replace any occurrence of a mistune import or usage to mistune0. This is not ideal, but I guess upstreams will make themselves compatible with mistune v2 in some future and you'll be able to drop such patches. In the meantime, this avoids conflicts between mistune 0.8.4 and 2.0.0 as both can be installed, and this also allows for things depending on mistune v2 to enter testing. With best regards, -- PEB signature.asc Description: PGP signature
Bug#1005722: ITP: mistune0 -- Markdown parser for Python 3
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: mistune0 Version : 0.8.4 Upstream Author : 2014-2018 Hsiaoming Yang * URL : https://github.com/lepture/mistune * License : BSD-3-Clause Programming Lang: Python3 Description : Markdown parser for Python 3 This is a source repackaging of mistune to allow a coexistence of mistune v 2 or more (in src:mistune) along with mistune 0.8.4 (in src:mistune0), as reverse dependencies won't be able to move forward as fast as one would expect. This repackaging is the result of a discussion in bug 1003567.
Bug#768073: [pkg-lxc-devel] Bug#768073: ITP: lxd - The Linux Container Daemon
Mathias Gibbens wrote on 06/02/2022 at 03:38:03+0100: > [[PGP Signed Part:No public key for 29EEE2D6ECF442F9 created at > 2022-02-06T03:38:03+0100 using RSA]] > For those following this ITP, the end is in sight! I have whittled > down the huge list of missing dependencies to just nine packages, all > of which are ready for upload. They're just waiting on sponsorship > and/or other dependencies to make it through into unstable. > > The packaging work for LXD is also largely complete. The git repo is > available on salsa [1], and I would invite interested parties to take a > look and provide any feedback. This is the most complicated package > I've created to date, so I'm sure there's room for improvement. I can do the sponsorship, send me the list of things to review by mail! :) -- PEB signature.asc Description: PGP signature
Bug#1003567: Please make a separate package for mistune 2.x
Nilesh Patra wrote on 05/02/2022 at 20:23:44+0100:
> [[PGP Signed Part:No public key for 00BAE74B343369F1 created at
> 2022-02-05T20:23:44+0100 using RSA]]
> On 2/6/22 12:20 AM, Julian Gilbey wrote:
>> On Fri, Feb 04, 2022 at 09:27:59PM +0530, Nilesh Patra wrote:
>>> On 2/4/22 9:18 PM, Julian Gilbey wrote:
[...]
_mistune.py within the Debian package,
and have nbconvert do "import nbconvert.filters._mistune as mistune"
(see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py).
That seems like an eminently sensible solution to this problem.
>>>
>>> But that'd lead to a number of mistune's embedded copies in a huge number
>>> of packages; since majority of
>>> the rev-deps (when I last checked) haven't adapted to this new version.
>>> When they do,
>>> and it becomes a overhead to fix each one later.
>>> Even worse, if we discover a security problem sometime later, then all such
>>> packages would be
>>> effected, and that honestly does not look like a good idea to me.
>> I have just had another idea, which might solve all of the problems:
>> create a new Debian package called mistune0 (or mistune1), which
>> contains the legacy version of mistune, but with the Python module
>> called "mistune0" instead of "mistune". Then it will be
>> co-installable with mistune 2.x, and the packages which still depend
>> on mistune 0.8.4 could be patched to say "import mistune0 as mistune"
>> until they are updated upstream. This will also avoid having multiple
>> copies of the legacy code in the archive, which addresses the security
>> issue, and allow those packages which have migrated to mistune 2.x to
>> still say "import mistune".
>
> Ah, looks like we just had to think in the reverse direction from the initial
> proposal (mistune-{0,1} instead of mistune-{1,2}).
> Indeed, that sounds like a much better plan.
> I hope PEB agrees with this as well, would like to hear from them :)
>
> Thanks for the discussion, Julian :)
>
> Regards,
> Nilesh
I'd like other python team member's opinion on this, and I'm not eager
to maintain that legacy package, as I tend to not want to maintain
obsolete software. Still, I can do the initial work of creating it.
--
PEB
signature.asc
Description: PGP signature
Bug#1003567: Please make a separate package for mistune 2.x
Le 4 février 2022 16:57:59 GMT+01:00, Nilesh Patra a écrit : >On 2/4/22 9:18 PM, Julian Gilbey wrote: >> Basically, the mistune upstream author has completely messed up on >> this by making what is essentially a completely different package with >> superficially similar functionality but the same name. > >True. > >> [...] >> _mistune.py within the Debian package, >> and have nbconvert do "import nbconvert.filters._mistune as mistune" >> (see /usr/lib/python3/dist-packages/nbconvert/filters/markdown_mistune.py). >> That seems like an eminently sensible solution to this problem. > >But that'd lead to a number of mistune's embedded copies in a huge number of >packages; since majority of >the rev-deps (when I last checked) haven't adapted to this new version. When >they do, >and it becomes a overhead to fix each one later. >Even worse, if we discover a security problem sometime later, then all such >packages would be >effected, and that honestly does not look like a good idea to me. > >I somehow do not understand the urgency of uploading this newer version, as >the maintainer said: > >| I intend to upload src:mistune 2.0.0 to unstable between March the >| 15th and April the 15th (depending on the progress of its >| reverse-dependencies). > >We could simply wait a little more for the dust to settle, IMHO. > >Regards, >Nilesh > Because some packages I maintain depend on mistune 2.x and mistune 0.8.4 is, whether we like it or not, obsolete. I can't really afford to wait for a year to try having mailman3 in testing again... -- Pierre-Elliott Bécue From my phone
Bug#1003567: Please make a separate package for mistune 2.x
Hi Michael, "Michael R. Crusoe" wrote on 24/01/2022 at 11:39:23+0100: > [[PGP Signed Part:No public key for 3C26763F6C67E6E2 created at > 2022-01-24T11:39:23+0100 using RSA]] > On Tue, 11 Jan 2022 22:38:44 +0100 p...@debian.org wrote: >> Package: python3-schema-salad >> Severity: wishlist >> >> Dear maintainer, >> >> Your package python3-schema-salad depends on python3-mistune 0.8.4 >> which is no longer maintained and deprecated in favour of version >> 2.0.0. >> >> As python3-mistune 2.0.0 is not backward compatible, I reverted the >> upload of it that I did in unstable and python3-mistune 0.8.4 will >> stay around a bit longer. >> >> In the meantime, please try to see if upstream of >> python3-schema-salad either released a version that is compatible >> with python3-mistune 2.0.0 or if python3-schema-salad can easily be >> fixed to support such a version. As soon as you're ready to upload >> your package please update this bug report and we'll try to >> coordinate so that I release python3-mistune at a time that is fit >> for you to also release python3-schema-salad. > > Dear Pierre-Elliott Bécue, > > Thank you for trying to find a way forward in this mess. I am also the > upstream maintainer for schema-salad. We have yet to find a way to > support mistune 2.x > > Here is our attempt so far: > > https://github.com/common-workflow-language/schema_salad/pull/496/files?short_path=5c6a130#diff-5c6a1301c6b59b30a040d747d065e861d3dd98bde0e5a4356d92d594e9835986 > > And an issue I opened with mistune directly about a regression in > multi-line list handling that goes against multiple markdown specs: > https://github.com/lepture/mistune/issues/296 > > We have not decided if we will switch to another library, wait for a > fixed mistune 2.x release, or keep with the older version. > >> I intend to upload src:mistune 2.0.0 to unstable between March the > >> 15th and April the 15th (depending on the progress of its >> reverse-dependencies). I'll raise the severity of this bug >> approximately a month before making such an upload. > > Since Mistune 2.0.0 regresses its support for standard markdown, I ask > that a separate package be made for mistune 2.x to give more time for > mistune 0.8.x users to migrate to mistune 2.x or another library entirely. > > Cheers, I'm not formally against it, but it's not really standard in my opinion. It'd lead to maintenance of two packages, probably on some long term (as it'd relieve the pressure to migrate for maintainers of reverse-deps of mistune). Besides, having a source package named "mistune2" while upstream's package is named "mistune" adds also another layer of complexity. I'd like to have some python team members' opinion on this, and I am not sure to be eager to do it as of now. Cheers! -- PEB signature.asc Description: PGP signature
Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD
Hi Mathias,
Mathias Gibbens wrote on 29/01/2022 at 03:41:40+0100:
> On Fri, 2022-01-28 at 01:33 +0100, Pierre-Elliott Bécue wrote:
>> I've made some changes I've decided to upload on salsa and on
>> experimental.
>>
>> If you're able to test these changes on some clean environment, I'd
>> be
>> happy if you could do it as I like the time to redo a clean testing
>> environment for lxc right now.
>>
>> If you can't, I'll try to do it this weekend or during the next week.
>
> Thanks! I took a quick look this evening and noticed one thing -- the
> directory `usr/lib/*/lxc/rootfs` is still listed in the d/lxc.install
> file. Can that also get moved over into the liblxc-common package? LXD
> expects to be able to use that directory similarly to lxc when starting
> up containers.
Ah, sorry. It slipped out from my sight.
> As it looks like liblxc-common is including the
> /usr/sbin/init.lxc{,.static} binaries it can't be an Architecture: all
> package, so having a directory with an architecture-dependent path
> hopefully won't be an issue. (Side note, in d/control, would it make
> sense to keep liblxc-common as Architecture: linux-any to match all the
> other binary packages that are built?)
Indeed! You're right. I've changed to linux-any.
> I'll do a build and test of LXD in a fresh environment this weekend
> and report back on any other issues I find.
Thanks for your feedback and for spotting these issues. :)
--
PEB
signature.asc
Description: PGP signature
Bug#1002564: [pkg-lxc-devel] Bug#1002564: lxc: packaging adjustments for LXD
Le dimanche 26 décembre 2021 à 16:03:41+, Mathias Gibbens a écrit : > On Sun, 26 Dec 2021 12:33:43 -0300 Antonio Terceiro > wrote: > > On Sat, Dec 25, 2021 at 02:25:06PM +, Evgeni Golov wrote: > > > On December 25, 2021 12:35:45 PM UTC, Antonio Terceiro > wrote: > > > >They probably would need to be provided by a (NEW) lxc-common > package. > > > >If we ever need to transition to liblxc2, we don't want both > liblxc* > > > >packages providing those files. > > > > > > On Ubuntu, this package us called liblxc-common, which we probably > > > should also use, to make life of other consumers easier? > > > > Sure! I didn't check there first. > > I think a liblxc-common package should work just fine. I haven't > found any other files in the lxc package that LXD is expecting to have > around, but if I do I'll update this bug. > > I'm happy to help test any changes to the packaging when they're > ready. > > Thanks! I've made some changes I've decided to upload on salsa and on experimental. If you're able to test these changes on some clean environment, I'd be happy if you could do it as I like the time to redo a clean testing environment for lxc right now. If you can't, I'll try to do it this weekend or during the next week. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#993232: lxc: Cannot add ipv4 gateway for network device "eth0" when not bringing up the interface.
Control: tags -1 +moreinfo Le dimanche 29 août 2021 à 12:23:09+0800, John a écrit : > Package: lxc > Version: 1:4.0.10-1 > Severity: normal > X-Debbugs-Cc: jo...@wonghome.net > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > After upgraded lxc from 4.0.6-2 to 4.0.10-1. lxc container cannot start. > I find the error with "lxc-start -l trace" like below: > > network.c:lxc_network_setup_in_child_namespaces_common:3894 - Cannot > add ipv4 gateway for network device "eth0" when not bringing up the interface > network.c:lxc_setup_network_in_child_namespaces:4038 - Function not > implemented - Failed to setup netdev > conf.c:lxc_setup:4080 - Failed to setup network > start.c:do_start:1291 - Failed to setup container "vbox" > > If I rollback to 4.0.6-2, everything work fine as before. > If I remove the line "lxc.net.0.ipv4.gateway = 10.0.3.1" in > "/var/lib/lxc/vbox/config" (container config), > the container can start again, but result no network , only loopback > interface (lo) in container (no eth0 in container). From where I stand, I'm unable to reproduce: ❯ sudo lxc-create toto -t debian -- -r bullseye [snip] ❯ sudo service lxc-net start ❯ ip a [snip] 7: lxcbr0: mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 00:16:3e:00:00:00 brd ff:ff:ff:ff:ff:ff inet 10.0.3.1/24 brd 10.0.3.255 scope global lxcbr0 valid_lft forever preferred_lft forever ❯ sudo lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED toto STOPPED 0 - --false ❯ sudo vim /var/lib/lxc/toto/config [adding ip conf] ❯ sudo cat /var/lib/lxc/toto/config # Template used to create this container: /usr/share/lxc/templates/lxc-debian # Parameters passed to the template: -r bullseye # For additional config options, please look at lxc.container.conf(5) # Uncomment the following line to support nesting containers: #lxc.include = /usr/share/lxc/config/nesting.conf # (Be aware this has security implications) lxc.net.0.type = veth lxc.net.0.hwaddr = 00:16:3e:cb:a1:76 lxc.net.0.link = lxcbr0 lxc.net.0.flags = up lxc.net.0.ipv4.address = 10.0.3.3/24 lxc.net.0.ipv4.gateway = 10.0.3.1 lxc.apparmor.profile = generated lxc.apparmor.allow_nesting = 1 lxc.rootfs.path = dir:/var/lib/lxc/toto/rootfs # Common configuration lxc.include = /usr/share/lxc/config/debian.common.conf # Container specific configuration lxc.tty.max = 4 lxc.uts.name = toto lxc.arch = amd64 lxc.pty.max = 1024 ❯ sudo lxc-start toto ❯ sudo lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED toto RUNNING 0 - 10.0.3.3 -false Please, try creating a new unprivileged container and make some tests with it, as for what I see, it doesn't seem like LXC is buggy. Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#964745: lxc-start fails when specifying a custom lxc.net.0.hwaddr (on armv7l)
Hi Santiago, I'd like to resume on that bug: did you either find a solution for it or an explanation for this behaviour? Could you try to have a go with lxc4? Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#991759: lxc fails to start a container with xfs root after host is booted
Control: tags -1 +wontfix Le dimanche 01 août 2021 à 12:05:05+0300, Markus Iehoven a écrit : > Package: lxc > Version: 1:4.0.6-2 > Severity: important > > Debian GNU/Linux 11 (bullseye) 5.10.0-8-amd64 #1 SMP Debian 5.10.46-3 > > I have a lxc container with root on a LVM volume formated to XFS. The > container can not be started after host is rebooted. look like XFS > module is not loaded at this time. modprobe xfs fixes the problem. But > I thinks that it should be done automatically > > ~# lxc-start -n mongo -F > > lxc-start: mongo: storage/storage_utils.c: mount_unknown_fs: 298 > Failed to determine FSType for "/dev/fast/mongo" > lxc-start: mongo: conf.c: lxc_mount_rootfs: 1257 Failed to mount > rootfs "/dev/fast/mongo" onto "/usr/lib/x86_64-linux-gnu/lxc/rootfs" > with options "(null)" > lxc-start: mongo: conf.c: lxc_setup_rootfs_prepare_root: 3142 Failed > to setup rootfs for > lxc-start: mongo: conf.c: lxc_setup: 3278 Failed to setup rootfs > lxc-start: mongo: start.c: do_start: 1218 Failed to setup container "mongo" > lxc-start: mongo: sync.c: __sync_wait: 36 An error occurred in > another process (expected sequence number 5) > lxc-start: mongo: start.c: __lxc_start: 1999 Failed to spawn container > "mongo" > lxc-start: mongo: tools/lxc_start.c: main: 308 The container failed to start > lxc-start: mongo: tools/lxc_start.c: main: 313 Additional information > can be obtained by setting the --logfile and --logpriority options > > it works: > ~# modprobe xfs && lxc-start -n mongo Hi, I am sorry but this is not something to be done by LXC: LXC is an end user program that should not load any third party driver automatically. It's the job of the system administrator to add to modules-load.d the configuration to load such modules on their machines. With best regards, -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#997666: flufl.bounce: please update to 4.0
Hi David, Le samedi 23 octobre 2021 à 20:27:10-0300, David Bremner a écrit : > Source: flufl.bounce > Version: 3.0.1-1 > Severity: wishlist > Tags: upstream > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > flufl.bounce is an important part of the operation of > mailman3. Mailmain3 upstream informs me that the bounces currently > bugging me are detected properly with version 4.0 of the library. It > would be nice to be able to fix this mailman3 problem within Debian. Sorry for having taken that long. I've not put a close statement in my upload because I wanted to make sure that you are aware that uploading 4.0 in stable is probably not an option. Would you like me to backport this package? Cheers. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for principles than to live up to them. signature.asc Description: PGP signature
Bug#1004192: bullseye-pu: package django-allauth/0.44.0+ds-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lafo...@gnumonks.org
Hi,
Due to some changes in Python that upstream failed to take into account,
django-allauth 0.44.0+ds-1 fails to work with the OpenID auth method.
The fix in itself is a simple patch replacing the call to a now
nonexistent function of the base64 module by a call to another which
replaces it.
The debdiff is attached, and the fix already is in unstable and testing.
The other changes are the gbp.conf git-debian-branch variable and the
addition of a Forwarded: tag in two patches to make lintian happier.
Additional information:
[ Impact ]
Without this upload, openid auth mechanism can't work. In bullseye,
django-allauth is mostly used by mailman3, so the scope of impacted
users is mailman3 users.
[ Tests ]
There is no test covering the code, as upstream did not provide unit
tests or functional tests. I ran pyflakes3 on it.
[ Risks ]
Code change is trivial
[ Checklist ]
[x] *all* changes are documented in the d/changelog
- Except the gbp.conf change as it is not even a packaging change.
[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
[ Other info ]
Thanks for your work <3
diff -Nru django-allauth-0.44.0+ds/debian/changelog
django-allauth-0.44.0+ds/debian/changelog
--- django-allauth-0.44.0+ds/debian/changelog 2021-01-18 02:25:56.0
+0100
+++ django-allauth-0.44.0+ds/debian/changelog 2022-01-22 13:55:10.0
+0100
@@ -1,3 +1,11 @@
+django-allauth (0.44.0+ds-1+deb11u1) bullseye; urgency=medium
+
+ * Import from 0.47.0-1 the patch to fix OpenID failures.
+(Closes: #1003069)
+ * Disable forwarding for two patches
+
+ -- Pierre-Elliott Bécue Sat, 22 Jan 2022 13:55:10 +0100
+
django-allauth (0.44.0+ds-1) unstable; urgency=medium
[ Ondřej Nový ]
diff -Nru django-allauth-0.44.0+ds/debian/gbp.conf
django-allauth-0.44.0+ds/debian/gbp.conf
--- django-allauth-0.44.0+ds/debian/gbp.conf2021-01-18 02:25:56.0
+0100
+++ django-allauth-0.44.0+ds/debian/gbp.conf2022-01-22 13:51:42.0
+0100
@@ -1,2 +1,3 @@
[DEFAULT]
pristine-tar = True
+debian-branch = debian/bullseye
diff -Nru
django-allauth-0.44.0+ds/debian/patches/0001-Remove-all-privacy-breack-links-from-documentation.patch
django-allauth-0.44.0+ds/debian/patches/0001-Remove-all-privacy-breack-links-from-documentation.patch
---
django-allauth-0.44.0+ds/debian/patches/0001-Remove-all-privacy-breack-links-from-documentation.patch
2021-01-18 02:25:56.0 +0100
+++
django-allauth-0.44.0+ds/debian/patches/0001-Remove-all-privacy-breack-links-from-documentation.patch
2022-01-22 13:54:22.0 +0100
@@ -2,6 +2,8 @@
Date: Tue, 12 Dec 2017 10:35:57 +0100
Subject: Remove all privacy breack links from documentation
+Forwarded: not-needed
+
---
README.rst | 22 --
1 file changed, 22 deletions(-)
diff -Nru
django-allauth-0.44.0+ds/debian/patches/0003-fix-openid-Use-decodebytes-instead-of-decodestring.patch
django-allauth-0.44.0+ds/debian/patches/0003-fix-openid-Use-decodebytes-instead-of-decodestring.patch
---
django-allauth-0.44.0+ds/debian/patches/0003-fix-openid-Use-decodebytes-instead-of-decodestring.patch
1970-01-01 01:00:00.0 +0100
+++
django-allauth-0.44.0+ds/debian/patches/0003-fix-openid-Use-decodebytes-instead-of-decodestring.patch
2022-01-22 13:55:01.0 +0100
@@ -0,0 +1,36 @@
+From: Karthikeyan Singaravelan
+Date: Thu, 20 Jan 2022 00:25:36 +0100
+Subject: fix(openid): Use decodebytes instead of decodestring
+Applied-Upstream:
https://github.com/pennersr/django-allauth/commit/425dc774fb5d032204b92f0870c3802202259ad3
+
+Co-authored-by: Raymond Penners
+---
+ AUTHORS | 1 +
+ allauth/socialaccount/providers/openid/utils.py | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/AUTHORS b/AUTHORS
+index 4e2ffb6..3fd282b 100644
+--- a/AUTHORS
b/AUTHORS
+@@ -90,6 +90,7 @@ Joshua Sorenson
+ Julen Ruiz Aizpuru
+ Justin Michalicek
+ Justin Pogrob
++Karthikeyan Singaravelan
+ Kevin Dice
+ Koichi Harakawa
+ Lee Semel
+diff --git a/allauth/socialaccount/providers/openid/utils.py
b/allauth/socialaccount/providers/openid/utils.py
+index cf32213..bfd766c 100644
+--- a/allauth/socialaccount/providers/openid/utils.py
b/allauth/socialaccount/providers/openid/utils.py
+@@ -102,7 +102,7 @@ class DBOpenIDStore(OIDStore):
+ for stored_assoc in stored_assocs:
+ assoc = OIDAssociation(
+ stored_assoc.handle,
+-base64.decodestring(stored_assoc.secret.encode("utf-8")),
++base64.decodebytes(stored_assoc.secret.encode("utf-8")),
+ stored_assoc.issued,
+ stored_assoc.lifetime,
+
Bug#1003069: openid exception "AttributeError: module 'base64' has no attribute 'decodestring'"
Le lundi 03 janvier 2022 à 16:55:37+0100, Harald Welte a écrit :
> Package: python3-django-allauth
> Version: 0.44.0+ds-1
> Severity: normal
>
> I'm running a bullseye installation with mailman3-web and wanted to enable
> openid
> authentication via the python3-django-allouth package. However, when using
> it,
> I get the following exception / backtrace:
>
> ERROR:django.request:Internal Server Error: /accounts/openid/login/
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py",
> line 34, in inner
> response = get_response(request)
> File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line
> 115, in _get_response
> response = self.process_exception_by_middleware(e, request)
> File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line
> 113, in _get_response
> response = wrapped_callback(request, *callback_args, **callback_kwargs)
> File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line
> 71, in view
> return self.dispatch(request, *args, **kwargs)
> File "/usr/lib/python3/dist-packages/django/views/generic/base.py", line
> 97, in dispatch
> return handler(request, *args, **kwargs)
> File
> "/usr/lib/python3/dist-packages/allauth/socialaccount/providers/openid/views.py",
> line 45, in get
> return self.perform_openid_auth(form)
> File
> "/usr/lib/python3/dist-packages/allauth/socialaccount/providers/openid/views.py",
> line 94, in perform_openid_auth
> auth_request = client.begin(endpoint)
> File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line
> 359, in begin
> return self.beginWithoutDiscovery(service, anonymous)
> File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line
> 382, in beginWithoutDiscovery
> auth_req = self.consumer.begin(service)
> File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line
> 610, in begin
> assoc = self._getAssociation(service_endpoint)
> File "/usr/lib/python3/dist-packages/openid/consumer/consumer.py", line
> 1178, in _getAssociation
> assoc = self.store.getAssociation(endpoint.server_url)
> File
> "/usr/lib/python3/dist-packages/allauth/socialaccount/providers/openid/utils.py",
> line 105, in getAssociation
> base64.decodestring(stored_assoc.secret.encode("utf-8")),
> AttributeError: module 'base64' has no attribute 'decodestring'
>
>
> It seems like base64.decodestring() has been deprecated since python 3.8 but
> somehow this module
> has not been updated.
>
> Upstream has a fix in
> https://github.com/pennersr/django-allauth/commit/425dc774fb5d032204b92f0870c3802202259ad3
Thanks for your bug report!
I've applied that commit in 0.47.0. As soon as it enters testing, I'll
do a stable-pu to have it in the next bullseye minor release.
With best regards,
--
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2
It's far easier to fight for principles than to live up to them.
signature.asc
Description: PGP signature
