Bug#977781: yarnpkg: fails to download modules
> Since yarnpkg add command did not return an error, the autpkgtest was > succeeding even though it did not add any modules to node_modules > directory. > I did a bisect (sort of). Removing cache is not an issue till commit 232ee703 (New upstream version 1.22.4+debian) But, it is an issue at commit d40971ee (Refresh patches (remove parts no longer needed) The one commit in between them - New upstream version 1.22.10+~cs18.39.16 ( 40af4cca ) could be the one which introduced this.
Bug#977781: yarnpkg: fails to download modules
> Since yarnpkg add command did not return an error, the autpkgtest was > succeeding even though it did not add any modules to node_modules > directory. > I did a bisect (sort of). Removing cache is not an issue till commit 232ee703 (New upstream version 1.22.4+debian) But, it is an issue at commit d40971ee (Refresh patches (remove parts no longer needed) The one commit in between them - New upstream version 1.22.10+~cs18.39.16 ( 40af4cca ) could be the one which introduced this. signature.asc Description: This is a digitally signed message part.
Bug#967027: cinnamon: uses libcroco which is unmaintained upstream
Il 20/12/2020 20:41, Norbert Preining ha scritto: > Hi Simon, hi Fabio, > >> cinnamon >= 4.8.0 uses a bundled copy of libcroco. The last remaining thing >> https://salsa.debian.org/cinnamon-team/cinnamon/-/merge_requests/12 >> cinnamon-settings-daemon 4.8.2-2 fails to build on s390x, which is >> https://salsa.debian.org/cinnamon-team/cinnamon-settings-daemon/-/merge_requests/3 >> https://salsa.debian.org/cinnamon-team/cinnamon-settings-daemon/-/merge_requests/4 > Thanks Simon for the MR and checking on the build status, much > appreciated! > >> @Norbert: can you upload new cinnamon-settings-daemon please? (needed > Thanks Fabio for preparing/merging. I am doing test builds now and will > upload both cinnamon and cinnamon-settings-daemon after the builds have > completed. @Norbert: thanks, unfortunately the migration to testing of some components has begun and having made a further upload of cinnamon (with medium urgency) will block the completion for another 5 days > > All the best > > Norbert > > -- > PREINING Norbert https://www.preining.info > Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 >
Bug#975591: update-rc.d disable
On Mon, 21 Dec 2020, Tom H wrote:
> > It means “do not call this init script in any runlevel”,
> > which *ought* to be very obvious.
>
> "do not call this init script in any runlevel" can be understood as
> "kill it in any runlevel".
No, absolutely not, NO, NO, *NO*. *GAH!*
> But you want to disable an init script, start it manually, change
(or start the daemon manually without that init script)
> runlevels, and expect it to keep on running. I consider that a corner
> case because, by default on Debian, runlevels 2-5 are the same, so
They are not, they are just configured identically.
Also, don’t deviate from the point in question with irrelevent
details. If you must, imaging some kind of dæmon that handles,
oh, say a fuse filesystem.
> method. Like Bob P, I'd rather not have to deal with the unintended
> consequences of a change in API (of "remove" or "disable").
Looking at their descriptions, I agree. But a new facility
to achieve this is definitely needed.
> > (Curiously wondering whether systemd handles _this_ right…)
>
> If you disable a service, it can be started manually or as a
> dependency of of another service.
>
> If you mask a service, it cannot be started at all.
Not even by calling /usr/sbin/${foo}d? The problem here is that
these are terminated by the initscript, even if that was not used
to start them. I guess systemd can distinguish that but am not sure.
But that’s not the main point anyway…
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
*
Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.
Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.
*
Bug#975591: update-rc.d disable
On Mon, Dec 21, 2020 at 12:16 AM Ian Jackson
wrote:
> Thorsten Glaser writes ("Bug#975591: update-rc.d disable"):
>> On Sun, 20 Dec 2020, Tom H wrote:
>>>
>>> It depends what's meant by "disable".
>>
>> Which part of “disable an init script” did you not understand?
>
> This is really rather rude. It seemed to me that Tom was asking
> reasonable questions. People must be allowed to have a
> misapprehension without getting this kind of obnoxious reply.
>
>> It means “do not call this init script in any runlevel”,
>
> Tom, my apologies.
>
>> which *ought* to be very obvious.I
>
> I have come into the middle of this conversation and am missing
> many technical details (and am full of wine) but: ISTM that a
> "disable" action which stopsprevents init script from stopping an
> already- running daemon is rather odd. Perhaps Tom H assumed that
> that wouldn't be the case, or something.
>
> Anyway, there is no excuse for this kind of behaviour towards
> xsomeone who is trying to collaburate with us to make things work
> properly.
Many thanks, but I'm OK with being called clueless :)
Bug#975591: update-rc.d disable
On Sun, Dec 20, 2020 at 11:44 PM Thorsten Glaser wrote: > On Sun, 20 Dec 2020, Tom H wrote: >>> There *absolutely* HAS to be some way to disable an init script > >> It depends what's meant by "disable". > > Which part of “disable an init script” did you not understand? Perhaps all of it :) >> If it means "disable from starting at boot", then > > No. > >> If it means "disable from starting at all", then > "update-rc.d > > No. > > It means “do not call this init script in any runlevel”, > which *ought* to be very obvious. "do not call this init script in any runlevel" can be understood as "kill it in any runlevel". >> It feels like a lot of work for an unusual corner case. > > It’s by no means an unusual corner case. > > Installing a package to have a dæmon binary (or really any > file from it) available but not intending for the initscript > to run isn’t anything special. There’s even standardised-ish > ways to do so (chmod -x the dæmon binary), which however > won’t be usable if users need to start it manually. The current "update-rc.d disable" does achieve this. But you want to disable an init script, start it manually, change runlevels, and expect it to keep on running. I consider that a corner case because, by default on Debian, runlevels 2-5 are the same, so "update-rc.d disable" has to mean, by default, disable "" in runlevels 2-5. So, if you start "" manually and change runlevels, it'd be a bug if it weren't stopped. If you know in which runlevel "" shouldn't be stopped (let's assume "3"), you can run "update-rc.d disable 245" or "update-rc.d disable 2 4 5" or run three separate invocations (the syntax's unclear to me). So the current API does provide you with an imperfect but usable method. Like Bob P, I'd rather not have to deal with the unintended consequences of a change in API (of "remove" or "disable"). > (Curiously wondering whether systemd handles _this_ right…) If you disable a service, it can be started manually or as a dependency of of another service. If you mask a service, it cannot be started at all.
Bug#968400: cockpit-ws: Warning on upgrades
Control: tag -1 patch pending Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15065 Hello Cesare, thanks for your report! I sent an upstream PR to fix that. Martin
Bug#977803: arm-trusted-firmware: suggestions for the packaging
Source: arm-trusted-firmware Severity: wishlist Tags: patch Hello. Please consider the attached suggestions for the packaging part. arm-trusted-firmware-suggestions.tar.gz Description: application/gzip
Bug#977752: spip: package spip is unusable without libapache2-mod-php
Hi, On 20/12/20 6:23 pm, David Prévot wrote: > Control: severity -1 wishlist > > Le 20/12/2020 à 05:50, Abhijith PA a écrit : >> Package: spip >> Version: 3.2.8-1 >> Severity: grave >> Justification: renders package unusable >> >> Hello, >> >> After a fresh install and going through README.debian. I cannot >> start apache2 service due to, > […] >> After installing libapache2-mod-php, this went OK. >> >> Let me know if it just me. > > You don’t need Apache to host a website, you need a webserver (e.g., > Apache, Nginx, Lighttpd, etc., usually something providing httpd in > Debian). In order to run PHP scripts, you probably need to set up something > like php-fpm. Using libapache2-mod-php with Apache is another way to do it > (php-fpm works also fine with Apache). Ah, I didn't think so far. Sorry for the noise. --abhijith
Bug#977799: [PATCH] hard-coded bin/python causes pytest failures in other packages
P.S. Please don't upload immediately. There are still a couple of cases where I'm not yet sure if it's Elpy's fault, or whether Jedi needs a bit of additional system integration. I hope to be able to say for sure by the 22nd. Thanks, Nicholas signature.asc Description: PGP signature
Bug#810890: caddy in Debian, git repo at Salsa
Geert, You should be able to create the repos with “dh-make-golang create-salsa-project” Stephen > On Dec 20, 2020, at 8:48 PM, Geert Stappers wrote: > > On Sun, 25 Dec 2016 15:41:37 +0100 Andrew Shadura wrote: >> (I have done base for cloudflare package but didn't check any new >> version in some time nor did I track if there is any other dependency >> packaged and they were quite a bit of them). I can send you the >> cloudflare work if you're interested in it or wait for me to finish >> it. >> >> >> I think it'd be great if you uploaded what you've done somewhere. Or >> at least mailed me a tarball :) > > > Hello Debian Go People, > Hello Debian Go People with create privilege at Salsa, > > > Please create git repo > https://salsa.debian.org/go-team/packages/golang-github-caddyserver > in addition to > https://salsa.debian.org/go-team/packages/golang-github-caddyserver-certmagic > > It is for packaging Caddy. > ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890 ) > > > Thanks > > Geert Stappers > > > P.S. > The extra copy of this you might got, is due Bcc signature.asc Description: Message signed with OpenPGP
Bug#977802: Useless in Bullseye
Package: php-token-stream Severity: serious [ Filed by the maintainer to see the package removed from testing. ] Hi, php-token-stream was released in Debian, as part of the PHPUnit stack but as of PHPUnit 9, this package is not useful in Debian anymore. I see little point in releasing Bullseye with this package, and also intend to request its removal unless advised otherwise (but would welcome if someone follows up with a removal request in the wean time). Regards David signature.asc Description: PGP signature
Bug#977801: Useless in Bullseye
Package: php-finder-facade Severity: serious [ Filed by the maintainer to see the package removed from testing. ] Hi, php-finder-facade was released in Debian, as part of the PHPUnit stack but as of PHPUnit 9, this package is not useful in Debian anymore. I see little point in releasing Bullseye with this package, and also intend to request its removal unless advised otherwise (but would welcome if someone follows up with a removal request in the wean time). Regards David signature.asc Description: PGP signature
Bug#965098: geda-gaf orphaned
On Fri, 27 Nov 2020 10:56:18 -0700 (MST) Bdale Garbee wrote: > In light of Kai-Martin Knaak's comments here, I won't push harder for > geda-gaf to be removed from Debian. > > However, since I have no intention of doing more work on it myself, I > just filed bug #975985 marking geda-gaf as orphaned. > > Bdale I just added my intention to adopt the package to this bug. ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgpYW_KqP_yKB.pgp Description: OpenPGP digital signature
Bug#977800: ITP: apertium-get -- Helper for Apertium and Giellatekno languages and pairs
Package: wnpp Severity: wishlist Owner: Kartik Mistry X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: apertium-get Version : 1.0.0 Upstream Author : Apertium Project Management Committee * URL : https://apertium.org/ * License : GPL-3+ Programming Lang: Python Description : Helper for Apertium and Giellatekno languages and pairs Helper script to download and build Apertium and Giellatekno languages and pairs. Q. Why is this package useful/relevant? is it a dependency for another package? A. Apertium helper scripts. Recommended by Apertium. Q. How do you plan to maintain it? inside a packaging team? A. Debian Science Team. -- Kartik Mistry | કાર્તિક મિસ્ત્રી kartikm.wordpress.com
Bug#975985: intend to adopt
Hi Bdale. I use geda-gaf several times a week. Because of recent progress in geda-gaf I do not feel inclined to switch to lepton-eda. So I hereby express my intend to adopt the package and act as a maintainer. However, this is the first time I touch Debian maintenance. I would happily accept pointers where to start. Am reading the "Debian New Maintainers' Guide" right now. Is there any other place to look at? Viele Grüße, ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgpHfefEBlAXc.pgp Description: OpenPGP digital signature
Bug#977799: [PATCH] hard-coded bin/python causes pytest failures in other packages
Package: python-jedi
Version: 0.17.2-1
Severity: important
Control: tag -1 +patch
Hi Piotr,
Sorry to bother you again so soon! With 0.17.2-1 I was able to make progress
debugging Elpy's pytests, and I think I found one more issue in python-jedi.
I've attached a (tested) patch, which I hope you'll agree is the correct
approach, and if not, please advise how else to proceed. With this fix I was
finally able to begin to identify the issues specific to Elpy :-)
TestRPCGetNames.test_should_not_fail_with_args_as_args
elpy/tests/test_jedibackend.py:30: in setUp
self.backend = jedibackend.JediBackend(self.project_root, env)
elpy/jedibackend.py:32: in __init__
self.environment = jedi.create_environment(environment_binaries_path,
/usr/lib/python3/dist-packages/jedi/api/environment.py:379: in
create_environment
return _create_environment(path, safe, **kwargs)
/usr/lib/python3/dist-packages/jedi/api/environment.py:386: in
_create_environment
return Environment(_get_executable_path(path, safe=safe), env_vars=env_vars)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
path = '/usr', safe = False
def _get_executable_path(path, safe=True):
"""
Returns None if it's not actually a virtual env.
"""
if os.name == 'nt':
python = os.path.join(path, 'Scripts', 'python.exe')
else:
python = os.path.join(path, 'bin', 'python')
if not os.path.exists(python):
> raise InvalidPythonEnvironment("%s seems to be missing." % python)
E jedi.api.environment.InvalidPythonEnvironment: /usr/bin/python
seems to be missing.
/usr/lib/python3/dist-packages/jedi/api/environment.py:399:
InvalidPythonEnvironment
Regards,
Nicholas
>From 3fce4962ea0089e1168ecee99a58e93c9e3eed2d Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves
Date: Sun, 20 Dec 2020 21:56:42 -0500
Subject: [PATCH] Add 0001-Search-for-python3-in-_get_executable_path.patch
---
debian/changelog | 8 ++
...-for-python3-in-_get_executable_path.patch | 26 +++
debian/patches/series | 1 +
3 files changed, 35 insertions(+)
create mode 100644
debian/patches/0001-Search-for-python3-in-_get_executable_path.patch
create mode 100644 debian/patches/series
diff --git a/debian/changelog b/debian/changelog
index 0ee5a6a..8c0c8ae 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+python-jedi (0.17.2-2) UNRELEASED; urgency=medium
+
+ [ Nicholas D Steeves ]
+ * Add 0001-Search-for-python3-in-_get_executable_path.patch. See message
+in patch header for more information.
+
+ -- Nicholas D Steeves Sun, 20 Dec 2020 21:54:56 -0500
+
python-jedi (0.17.2-1) unstable; urgency=medium
* New upstream release (closes: 977558)
diff --git
a/debian/patches/0001-Search-for-python3-in-_get_executable_path.patch
b/debian/patches/0001-Search-for-python3-in-_get_executable_path.patch
new file mode 100644
index 000..34253b4
--- /dev/null
+++ b/debian/patches/0001-Search-for-python3-in-_get_executable_path.patch
@@ -0,0 +1,26 @@
+From: Nicholas D Steeves
+Date: Sun, 20 Dec 2020 21:53:19 -0500
+Subject: Search for python3 in _get_executable_path
+Forwarded: not-needed
+
+Python2 is no longer supported in Debian, and our virtual environments
+provide both bin/python and bin/python3.
+
+This change is required for Elpy's pytests to not fail due to missing
/usr/bin/python.
+---
+ jedi/api/environment.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/jedi/api/environment.py b/jedi/api/environment.py
+index 89e4716..61f34f0 100644
+--- a/jedi/api/environment.py
b/jedi/api/environment.py
+@@ -394,7 +394,7 @@ def _get_executable_path(path, safe=True):
+ if os.name == 'nt':
+ python = os.path.join(path, 'Scripts', 'python.exe')
+ else:
+-python = os.path.join(path, 'bin', 'python')
++python = os.path.join(path, 'bin', 'python3')
+ if not os.path.exists(python):
+ raise InvalidPythonEnvironment("%s seems to be missing." % python)
+
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..9d9ce29
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Search-for-python3-in-_get_executable_path.patch
--
2.29.2
Bug#977558: fixed in python-jedi 0.17.2-1
Hi Piotr, "Debian Bug Tracking System" writes: > This is an automatic notification regarding your Bug report > which was filed against the python-jedi package: > > #977558: python-jedi: please package 0.17.2 > > It has been closed by Debian FTP Masters > (reply to Piotr Ożarowski ). > Thank you for the quick upload, much appreciated! Regards, Nicholas signature.asc Description: PGP signature
Bug#810890: caddy in Debian, git repo at Salsa
On Sun, 25 Dec 2016 15:41:37 +0100 Andrew Shadura wrote: > (I have done base for cloudflare package but didn't check any new > version in some time nor did I track if there is any other dependency > packaged and they were quite a bit of them). I can send you the > cloudflare work if you're interested in it or wait for me to finish > it. > > > I think it'd be great if you uploaded what you've done somewhere. Or > at least mailed me a tarball :) Hello Debian Go People, Hello Debian Go People with create privilege at Salsa, Please create git repo https://salsa.debian.org/go-team/packages/golang-github-caddyserver in addition to https://salsa.debian.org/go-team/packages/golang-github-caddyserver-certmagic It is for packaging Caddy. ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810890 ) Thanks Geert Stappers P.S. The extra copy of this you might got, is due Bcc signature.asc Description: PGP signature
Bug#957576: nagios4: ftbfs with GCC-10
Control: severity -1 important nagios4/4.4.6-2 currently in unstable seems to build fine with gcc-10/10.2.0-18 on the builders [1], so I guess this was fixed? I'm downgrading the severity to let nagios4 migrate to testing. Emmanuel Bourg [1] https://buildd.debian.org/status/package.php?p=nagios4=unstable
Bug#976892: autoconf: Please package new version (2.70)
Hi, Now that gettext 0.20.1 has made it to Debian Sid, it would be nice to have autoconf 2.70 as well. Please let me know if you would like me to help with the packaging: I can take a stab at providing a patch to the current version. Yours truly, John Zaitseff -- John Zaitseff ╭───╮ Email: j.zaits...@zap.org.au The ZAP Group │ Z │ GnuPG: 0x0D254111C4EE569B Sydney, Australia ╰───╯ https://www.zap.org.au/~john/
Bug#977798:
Regarding the duplicate part, please ignore, as I received the confirmation and bug ID a few minutes after (and for) my second attempt. I'm certain the first attempt never made it your way. Thanks! Regards, Sam
Bug#977798: /usr/bin/feh: Memory leak when feh compiled with exif=1
Subject: /usr/bin/feh: Memory leak when feh compiled with exif=1 Package: feh Version: 3.1.3-1 Severity: wishlist File: /usr/bin/feh Dear Maintainer, Apologies if this ends up as a duplicate, I fear the automated one sent via sendmail using reportbug wasn't actually sent (I haven't received a confirmation email yet). First time doing this and still learning. * What led up to the situation? Feh memory consumption increases, until all resident & swap is consumed, then crashes (OOM). * What exactly did you do (or not do) that was effective (or ineffective)? Nothing out of the ordinary other than use feh, with exim=1 flag enabled. * What was the outcome of this action? Memory climbed until [1094530.907681] feh invoked oom-killer: gfp_mask=0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), order=0, oom_score_adj=0 [1094530.909500] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),task=feh,pid=929,uid=1000 [1094530.909542] Out of memory: Killed process 929 (feh) total-vm:345800kB, anon-rss:233248kB, file-rss:60kB, shmem-rss:0kB, UID:1000 pgtables:334kB oom_score_adj:0 [1094531.086376] oom_reaper: reaped process 929 (feh), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB * What outcome did you expect instead? Memory usage to be constant & not end up with OOM, feh crashing/stopping. Please note, I followed up with the developer on this, refer to https://github.com/derf/feh/issues/553 He identified and fixed the issue in the (now latest) version 3.6.1: https://feh.finalrewind.org/ >>Fix excessive memory consumption when showing long-running slideshows with thousands to tens of thousands of images and feh has been compiled with exif=1 (see https://github.com/derf/feh/issues/553) >>Fix memory leak when showing long-running slideshows with relatively few images and feh has been compiled with exif=1 (ibid.) >>Fix memory leak when reloading an image and feh has been compiled with exif=1 >>Fix memory leak in --draw-exif >>Fix memory leak when reloading HTTP files with --no-conversion-cache The request if possible, is to update the package in debian to 3.6.1. -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 10 (buster) Release:10 Codename: buster Architecture: armv6l Kernel: Linux 5.4.79+ Kernel taint flags: TAINT_DIE, TAINT_CRAP Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_NZ.UTF-8), LANGUAGE=en_NZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_NZ.U Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages feh depends on: ii libc6 2.28-10+rpi1 ii libcurl4 7.64.0-4+deb10u1 ii libexif12 0.6.21-5.1+deb10u5 ii libimlib2 1.5.1-1 ii libpng16-16 1.6.36-6 ii libx11-6 2:1.6.7-1+deb10u1 ii libxinerama1 2:1.1.4-2 ii yudit-common 2.9.6-8 Versions of packages feh recommends: ii libjpeg-progs 1:9b-1 feh suggests no packages. -- no debconf information Regards, Sam
Bug#977797: provide gcc-source metapackage
Source: gcc-defaults Version: 4:10.2.0-1 Severity: minor Control: affects -1 src:open-ath9k-htc-firmware The open-ath9k-htc-firmware package builds a custom cross-toolchain prior to the firmware. To reduce my maintenance burden of bumping the version and also catch incompatibilities sooner, it would be appreciated if you could provide a metapackage as gcc-source. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: This is a digitally signed message part.
Bug#977796: mocha,node-postcss: both ship usr/share/nodejs/nanoid/*
Package: mocha,node-postcss Severity: serious User: debian...@lists.debian.org Usertags: piuparts Control: found -1 8.2.1+ds1+~cs29.4.27-1 Control: found -1 8.2.1+~cs5.3.23-1 Hi, during a test with piuparts I noticed your package failed to install because it tries to overwrite other packages files. >From the attached log (scroll to the bottom...): Selecting previously unselected package node-postcss. Preparing to unpack .../node-postcss_8.2.1+~cs5.3.23-1_all.deb ... Unpacking node-postcss (8.2.1+~cs5.3.23-1) ... dpkg: error processing archive /var/cache/apt/archives/node-postcss_8.2.1+~cs5.3.23-1_all.deb (--unpack): trying to overwrite '/usr/share/nodejs/nanoid/async/index.browser.js', which is also in package mocha 8.2.1+ds1+~cs29.4.27-1 Errors were encountered while processing: /var/cache/apt/archives/node-postcss_8.2.1+~cs5.3.23-1_all.deb cheers, Andreas mocha=8.2.1+ds1+~cs29.4.27-1_node-postcss=8.2.1+~cs5.3.23-1.log.gz Description: application/gzip
Bug#977795: uscan,mk-origtargz: inconsistency about Files-Included: hint
Package: devscripts Version: 2.20.5 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 manpage for mk-origtargz talks about support for Files-Included hint, and refers to manpage for uscan for an example. But manpage for uscan does not mention Files-Included at all. Setting severity "normal" as I don't know if this is only a matter of updating documentation for uscan, or there is code missing in uscan. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/f7Y0ACgkQLHwxRsGg ASFj9g/7BFZaM9LVNiE95hpaCsF71XQSJoOT1WARfcKCUlK9kqwedxFatmB0bCs8 ItBoJJPNr69MBChfUO50bxW6K+nJ/XvAW1GQxUvyNPlAGPVEseLIttnwzw/DnQcK U/r+vLEoVM7VZmq7L5DGgRYTA+zeKAjG9BOXo3+dBnvSBgScl9ONa6zBAUByLYgf rki7F7/vSCp2a4VUkaERz/wtbeKt7RnryPqZJWj90ltaOi9OuZGHGbh3eU+/jKKY zf8CLTMlC5+p5xK8If93PoWTKE/u4hNadh2cSDi4XWPh6RiXXqktb0uB4VUlvRE4 oyFMmazrCKcWyjGoZjysczyAxhB8v5DWyahRVPsLW9YVtWl27AarB1OmH8x9TB9i CNfAhXxkQUroQqsAHaWkppzibV73JwJd02uCv8aSdB9TzmhGdSVirRelN7qzbdOR ZJhuixiuAJkl6tHaIObKfGNBnyabFirzVlUXtwhF6uM7N0tyIkisLOeJpb5yaJEz gcOxuoz8K69aOVngv2VpS173zw6I6/i3DGzLCjk5jsEotZKYNpiKmA/RPk9ctBvg AapTvsRiwlyM2HLVOF3fXHZL00nJR7v3KLibxlbtMekdh/XpTnwL/YIdeOhLg0Np xKMZA8+WzMeIE/iB7Eh5H9b4XiNOvz8azfoviVPNrQR9BsL98ZU= =A+9W -END PGP SIGNATURE-
Bug#977794: ntpsec: Stops after seeing an old version of openssl is used
Package: ntpsec Version: 1.2.0+dfsg1-1+b1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Update ntpsec to the latest(1.2.0+dfsg1-1+b1) on Sid I got in /var/log/daemon.log: Dec 21 00:20:27 lleopard ntpd[5327]: INIT: Built with OpenSSL 1.1.1h 22 Sep 2020, 1010108f Dec 21 00:20:27 lleopard ntpd[5327]: INIT: Running with OpenSSL 1.1.1d 10 Sep 2019, 1010104f Dec 21 00:20:27 lleopard ntpd[5327]: INIT: Old OpenSSL library, bailing Dec 21 00:20:27 lleopard systemd[1]: ntpsec.service: Main process exited, code=exited, status=1/FAILURE Dec 21 00:20:27 lleopard systemd[1]: ntpsec.service: Failed with result 'exit- code'. * What exactly did you do (or not do) that was effective (or ineffective)? Updating libssl1.1 (1.1.1i-1) over (1.1.1d-2) did solve the problem * What was the outcome of this action? * What outcome did you expect instead? I'd expect the update of ntpsec triggers too the update of libssl1.1 to a compatible version. HTH Pere -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), LANGUAGE=ca_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ntpsec depends on: ii adduser 3.118 ii init-system-helpers 1.57 ii libbsd0 0.10.0-1 ii libc62.29-7 ii libcap2 1:2.27-1 ii libssl1.11.1.1i-1 ii lsb-base 11.1.0 ii netbase 5.6 ii python3 3.8.2-3 ii python3-ntp 1.2.0+dfsg1-1+b1 ii tzdata 2019b-2 Versions of packages ntpsec recommends: ii cron [cron-daemon] 3.0pl1-134 ii systemd 244-3 Versions of packages ntpsec suggests: ii apparmor 2.13.3-5 pn certbot pn ntpsec-doc pn ntpsec-ntpviz -- Configuration Files: /etc/apparmor.d/usr.sbin.ntpd changed [not included] /etc/ntpsec/ntp.conf changed [not included] -- no debconf information
Bug#975687: xterm: loses text lines, even descenders from some lines
On Sun, Dec 20, 2020 at 11:39:15PM +, Thorsten Glaser wrote: > Thomas Dickey dixit: > > >I'm guessing that it's timing, e.g., xterm could wait a few milliseconds > >to retry and then give up on that loop, in case the window events don't > >arrive rapidly enough. > > “rapidly enough” as criterium isn’t going to help everyone. > > We have multi-GHz desktop bolides, few-MHz m68k/SPARC/POWER/… machines, > and running X11 over various network protocols (X, VNC, RDP, NX, x2go), > with varying latencies. > > If the solution for this issue with XCheckWindowEvent is dependent on > such things, I’d argue that not using XCheckWindowEvent is the correct > fix instead ☺ I'm aware of that. It's called a "dilemma" (in this case, a bug which I'm easily able to reproduce versus one that I'm not). Since I'm able to reproduce the case with the active-icon, I might decide to use XCheckWindowEvent with a timeout for that scenario and the XWindowEvent for the other. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#977782: buster-pu: package postsrsd/1.5-2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
Upstream recently discovered a potential remote denial-of-service attack in
postsrsd (CVE-2020-35573) [1]. Fortunately, this issue is currently not
exploitable in Debian due to gcc optimizing the problematic loop away. Thus,
the
security has decided not to issue a DSA [2], but instead suggested to fix it
through a stable update.
This issue is already fixed in postsrsd/1.10-1 in unstable and testing.
I've prepared a backport of the one-line fix to stable, and attached the source
debdiff. I've verified that this doesn't break anything and the package still
works properly.
Cheers,
Oxan
[1]
https://github.com/roehling/postsrsd/commit/4733fb11f6bec6524bb8518c5e1a699288c26bac
[2] https://security-tracker.debian.org/tracker/CVE-2020-35573
diff -Nru postsrsd-1.5/debian/changelog postsrsd-1.5/debian/changelog
--- postsrsd-1.5/debian/changelog 2019-02-23 14:27:44.0 +0100
+++ postsrsd-1.5/debian/changelog 2020-12-19 01:36:37.0 +0100
@@ -1,3 +1,11 @@
+postsrsd (1.5-2+deb10u1) buster; urgency=medium
+
+ * CVE-2020-35573: Ensure timestamp tags aren't too long before trying to
+decode them, to protect against a potential denial-of-service attack
+(backported from upstream commit 4733fb1).
+
+ -- Oxan van Leeuwen Sat, 19 Dec 2020 01:36:37 +0100
+
postsrsd (1.5-2) unstable; urgency=medium
* Increase hashlength for unit tests (cherry-picked from upstream db9ed58)
diff -Nru
postsrsd-1.5/debian/patches/0004-SECURITY-Fix-potential-denial-of-service-attack-agai.patch
postsrsd-1.5/debian/patches/0004-SECURITY-Fix-potential-denial-of-service-attack-agai.patch
---
postsrsd-1.5/debian/patches/0004-SECURITY-Fix-potential-denial-of-service-attack-agai.patch
1970-01-01 01:00:00.0 +0100
+++
postsrsd-1.5/debian/patches/0004-SECURITY-Fix-potential-denial-of-service-attack-agai.patch
2020-12-19 01:36:37.0 +0100
@@ -0,0 +1,29 @@
+From: =?utf-8?q?Timo_R=C3=B6hling?=
+Date: Sat, 12 Dec 2020 10:42:28 +0100
+Subject: SECURITY: Fix potential denial of service attack against PostSRSd
+
+I discovered that PostSRSd could be tricked into consuming a lot of CPU
+time with an SRS address that has an excessively long time stamp tag,
+e.g.
+
+SRS0==T=0...@example.com
+
+(cherry picked from commit 4733fb11f6bec6524bb8518c5e1a699288c26bac)
+
+Fixes CVE-2020-35573.
+---
+ srs2.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/srs2.c b/srs2.c
+index b07a664..6a2eebb 100644
+--- a/srs2.c
b/srs2.c
+@@ -230,6 +230,7 @@ srs_timestamp_check(srs_t *srs, const char *stamp)
+ time_t now;
+ time_t then;
+
++ if (strlen(stamp) != 2) return SRS_ETIMESTAMPOUTOFDATE;
+ /* We had better go around this loop exactly twice! */
+ then = 0;
+ for (sp = stamp; *sp; sp++) {
diff -Nru postsrsd-1.5/debian/patches/series postsrsd-1.5/debian/patches/series
--- postsrsd-1.5/debian/patches/series 2019-02-23 14:27:44.0 +0100
+++ postsrsd-1.5/debian/patches/series 2020-12-19 01:36:37.0 +0100
@@ -1,3 +1,4 @@
0001-Adapt-init-scripts-for-Debian-practices.patch
0002-Increase-hash-length-for-unit-tests.patch
0003-Hook-up-endianness-sizeof-long-detection-code-in-SHA.patch
+0004-SECURITY-Fix-potential-denial-of-service-attack-agai.patch
Bug#963834: isync: new upstream version
Package: isync Version: 1.3.0-2 Followup-For: Bug #963834 X-Debbugs-Cc: deb...@microjoe.org Dear Maintainer, Upstream has released version 1.3.3. Importing it seems straightforward. I have done it locally. The 01_sni.patch can be dropped as the fix seems to be integrated in upstream now. Please find attached the list of patches that I used to import upstream version, as well as fix a lot of lintian warnings. You can pick the ones you like, ideally all of them to improve the quality of the package. Best regards, Romain. From e6a27464e7f46d00e6a3a2edffe7b831730c4ece Mon Sep 17 00:00:00 2001 From: Romain Porte Date: Sun, 20 Dec 2020 17:01:04 +0100 Subject: [PATCH 01/12] New upstream release --- debian/changelog | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index b34b1e6..0adec65 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,5 +1,6 @@ -isync (1.3.0-3) UNRELEASED; urgency=medium +isync (1.3.3-0.1) UNRELEASED; urgency=medium + * New upstream release * d/watch: Use https protocol -- Ondřej Nový Mon, 01 Oct 2018 09:35:31 +0200 -- 2.29.2 From dffc30593c9cc05a1a2a66d9b06318a19d417469 Mon Sep 17 00:00:00 2001 From: Romain Porte Date: Sun, 20 Dec 2020 17:04:45 +0100 Subject: [PATCH 02/12] remove now unused sni patch --- debian/patches/01_sni.patch | 38 - debian/patches/series | 1 - 2 files changed, 39 deletions(-) delete mode 100644 debian/patches/01_sni.patch delete mode 100644 debian/patches/series diff --git a/debian/patches/01_sni.patch b/debian/patches/01_sni.patch deleted file mode 100644 index 41af47f..000 --- a/debian/patches/01_sni.patch +++ /dev/null @@ -1,38 +0,0 @@ -From 1086cdb8fd77a224d56033bde0825a286ba30ee2 Mon Sep 17 00:00:00 2001 -From: Vincent Bernat -Date: Wed, 22 Aug 2018 19:20:35 +0200 -Subject: [PATCH] use SNI when connecting with SSL - -imap.gmail.com doesn't accept connections without SNI anymore. Without -this extension, it returns a self-signed certificate and mbsync is -unable to complete: - -$ openssl s_client -connect imap.gmail.com:993 -noservername -CONNECTED(0005) -depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid -verify error:num=18:self signed certificate -verify return:1 -depth=0 OU = "No SNI provided; please fix your client.", CN = invalid2.invalid -verify return:1 ---- -Certificate chain - 0 s:OU = "No SNI provided; please fix your client.", CN = invalid2.invalid - i:OU = "No SNI provided; please fix your client.", CN = invalid2.invalid - -This commit configure the SSL connection to transmit the hostname -through SNI. This has been tested with both GMail (which requires SNI) -and Fastmail (which doesn't require SNI). - src/socket.c | 1 + - 1 file changed, 1 insertion(+) - a/src/socket.c -+++ b/src/socket.c -@@ -270,6 +270,7 @@ - - init_wakeup( >ssl_fake, ssl_fake_cb, conn ); - conn->ssl = SSL_new( ((server_conf_t *)conn->conf)->SSLContext ); -+ SSL_set_tlsext_host_name( conn->ssl, conn->conf->host ); - SSL_set_fd( conn->ssl, conn->fd ); - SSL_set_mode( conn->ssl, SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER ); - socket_expect_read( conn, 1 ); diff --git a/debian/patches/series b/debian/patches/series deleted file mode 100644 index 21181ba..000 --- a/debian/patches/series +++ /dev/null @@ -1 +0,0 @@ -01_sni.patch -- 2.29.2 From f2347f04f30ea343dafe0338876093ab61c88763 Mon Sep 17 00:00:00 2001 From: Romain Porte Date: Sun, 20 Dec 2020 17:08:51 +0100 Subject: [PATCH 03/12] d/changelog: close outdated version bug --- debian/changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 0adec65..132c4e7 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,6 @@ isync (1.3.3-0.1) UNRELEASED; urgency=medium - * New upstream release + * New upstream release (Closes: #963834) * d/watch: Use https protocol -- Ondřej Nový Mon, 01 Oct 2018 09:35:31 +0200 -- 2.29.2 From 5a8447157ba02dab2a446ac3b08350967f87ab34 Mon Sep 17 00:00:00 2001 From: Romain Porte Date: Mon, 14 Dec 2020 03:41:06 +0100 Subject: [PATCH 04/12] d/watch: upgrade from v3 to v4 --- debian/watch | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/debian/watch b/debian/watch index f6309d1..4d63417 100644 --- a/debian/watch +++ b/debian/watch @@ -1,2 +1,5 @@ -version=3 -https://sf.net/isync/ isync-(.*)\.tar\.gz +version=4 +# qa.debian.org runs a redirector which allows a simpler form of URL +# for SourceForge based projects. The format below will automatically +# be rewritten to use the redirector. +http://sf.net/isync/isync-(\d\S+)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) -- 2.29.2 From eccf9abc4bfa5d12f00f664571afe94943412538 Mon Sep 17 00:00:00 2001 From: Romain Porte Date: Mon, 14 Dec 2020 03:20:03 +0100 Subject: [PATCH 05/12] Wrap and sort debian/* files Used command:
Bug#975687: xterm: loses text lines, even descenders from some lines
Thomas Dickey dixit: >I'm guessing that it's timing, e.g., xterm could wait a few milliseconds >to retry and then give up on that loop, in case the window events don't >arrive rapidly enough. “rapidly enough” as criterium isn’t going to help everyone. We have multi-GHz desktop bolides, few-MHz m68k/SPARC/POWER/… machines, and running X11 over various network protocols (X, VNC, RDP, NX, x2go), with varying latencies. If the solution for this issue with XCheckWindowEvent is dependent on such things, I’d argue that not using XCheckWindowEvent is the correct fix instead ☺ bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#977793: nis: reproducible builds: variable build path triggers Build ID variations
Source: nis Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Various binaries shipped in nis are build differently when the build path varies: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nis.html /usr/bin/ypcat GNU··0x0014» NT_GNU_BUILD_ID·(unique·build·ID·bitstring)» Build·ID:·dedd8715faeef72ca4c5130f43d08f8df595b39a vs. GNU 0x0014» NT_GNU_BUILD_ID·(unique·build·ID·bitstring)» Build·ID:·5dba43813c061ce956ac0741ae4bb981fc1eaa4e The attached patch fixes this by adding -ffile-prefix-map to CFLAGS. live well, vagrant From a0a9ef87562f56000e30749d535c948b48de4cd9 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 20 Dec 2020 23:30:56 + Subject: [PATCH] debian/rules: Add -ffile-prefix-map to CFLAGS. This is used to strip the build path from the resulting binaries, fixing variable Build IDs in the binaries. https://tests.reproducible-builds.org/debian/issues/build_id_differences_only_issue.html --- debian/rules | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/debian/rules b/debian/rules index abc714e..99dfcc1 100755 --- a/debian/rules +++ b/debian/rules @@ -17,14 +17,16 @@ include /usr/share/dpkg/architecture.mk BUILD_DATE=$(shell dpkg-parsechangelog --show-field Date) ifeq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) -CFLAGS = "-O2 -Wall -g" +CFLAGS = -O2 -Wall -g else -CFLAGS = "-O0 -Wall -g" +CFLAGS = -O0 -Wall -g endif #ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) #INSTALL_PROGRAM += -s #endif +# Avoid embedding build paths in binaries for reproducible builds +CFLAGS += -ffile-prefix-map=$(CURDIR)=. define checkdir test -f $(YPBIND)/README @@ -36,13 +38,13 @@ build: # Builds the binary package. dh_autoreconf -(cd $(YPTOOLS) && [ ! -f config.status ] && \ - CFLAGS=$(CFLAGS) ./configure \ + CFLAGS="$(CFLAGS)" ./configure \ --prefix=/usr --mandir=/usr/share/man \ --build=$(DEB_BUILD_GNU_TYPE) \ --host=$(DEB_HOST_GNU_TYPE) ) (cd $(YPTOOLS) && make) -(cd $(YPBIND) && [ ! -f config.status ] && \ - CFLAGS=$(CFLAGS) ./configure \ + CFLAGS="$(CFLAGS)" ./configure \ --prefix=/usr --mandir=/usr/share/man \ --sysconfdir=/etc --libexecdir=/usr/lib/yp \ --disable-dbus-nm \ @@ -51,7 +53,7 @@ build: (cd $(YPBIND) && make ) rm -f $(YPSERV)/sedscript -(cd $(YPSERV) && [ ! -f config.status ] && \ - AWK=/usr/bin/awk CFLAGS=$(CFLAGS) ./configure \ + AWK=/usr/bin/awk CFLAGS="$(CFLAGS)" ./configure \ BASH=/bin/bash \ --prefix=/usr --mandir=/usr/share/man \ --sysconfdir=/etc \ -- 2.29.2 signature.asc Description: PGP signature
Bug#975591: update-rc.d disable
On Sun, 20 Dec 2020, Ian Jackson wrote:
> Thorsten Glaser writes ("Bug#975591: update-rc.d disable"):
> > On Sun, 20 Dec 2020, Tom H wrote:
> > > It depends what's meant by "disable".
> >
> > Which part of “disable an init script” did you not understand?
>
> This is really rather rude. It seemed to me that Tom was asking
> reasonable questions.
Sorry, I was getting slightly fed up repeating the same thing as
was written both literally only a few lines atop his question *and*
in the Subject for most of the thread.
> I have come into the middle of this conversation and am missing many
> technical details (and am full of wine)
I see ;-) no worries either.
Let me summarise what has happened:
• I was wondering which was the correct way to disable an init script.
I found that
– update-rc.d remove works but does not persist across package upgrades
– update-rc.d disables the service, not the init script, by calling
the init script with 'stop' in every runlevel, which is not the same,
as it would also stop manually-started instances
• I request a reliably way to disable an initscript
(which I have use case for)
• Bob Proulx requests that the current functionality of disabling a
service not be removed, as he has use cases for that
• update-rc.d from init-system-helpers offers the interface, but…
• … insserv keeps state *only* by the presence of the K and S symlinks,
so, to correctly implement disabling an initscript, first insserv
must be extended
• I’m still pondering whether this is RC for sysvinit systems, as
fully disabling initscripts used to work (at least by manually
removing all S and K symlinks, and IIRC by update-rc.d invocations)
• Today I additionally started wondering how systemd handles this,
especially if it supports both semantics… but of mere curiosity,
not because I have use case for that
bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!
Bug#965098: migrated to guile 2.2
On Tue, 27 Oct 2020 09:39:16 -0700 Sean Whitton wrote: > Hello, > > On Mon 26 Oct 2020 at 04:58AM +01, Kai-Martin Knaak wrote: > > > Just a heads-up: > > Upstream pushed a few patches to the git repository to make the > > package compatible with guile 2.2. > > > > This removes the road block that triggered this removal request. Is > > there anything else that prevents geda-gaf from staying in the Debian > > repos? > > Well, someone needs to update the version of the package in Debian. > Can you? I am rather interested in having the non forked version of geda available in Debian. I use geda on a daily base at work. While I habitually build the application from source, my workmates certainly do not. I see that Bdale officially orphaned the package(s). So I may step up to carry the flag and maintain the geda package in Debian. What would be the first steps to do so? (I am a long time user of Debian but never had a reason to enter this arena?) ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: https://keyserver.ubuntu.com/pks/lookup?op=index=0x7B0F9882 pgpYaZXqr6fKZ.pgp Description: OpenPGP digital signature
Bug#975687: xterm: loses text lines, even descenders from some lines
On Sun, Dec 20, 2020 at 10:40:39PM +, Thorsten Glaser wrote: > Thomas Dickey dixit: > > >how far below? > > > >Just the window-decoration, or a line or so? > > About a line, give or take (for the syslog window, the last line > is the cursor, so I don’t need it, and I took a bit more than a > line there; for that test, it’s a bit less). > > >Looking at the changes for #361, there's the changes for wrap-mark, > >and copy-wait. The latter was just this: > > I did… > > begin 644 xterm_362-1.0.1.debdiff ... > … to revert that, and voilà, problem fixed. > > Perhaps some events are lost with XCheckWindowEvent or something? The descriptions for XWindowEvent and XCheckWindowEvent are very similar. I'm guessing that it's timing, e.g., xterm could wait a few milliseconds to retry and then give up on that loop, in case the window events don't arrive rapidly enough. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#975591: update-rc.d disable
Thorsten Glaser writes ("Bug#975591: update-rc.d disable"):
> On Sun, 20 Dec 2020, Tom H wrote:
> > It depends what's meant by "disable".
>
> Which part of “disable an init script” did you not understand?
This is really rather rude. It seemed to me that Tom was asking
reasonable questions. People must be allowed to have a
misapprehension without getting this kind of obnoxious reply.
> It means “do not call this init script in any runlevel”,
Tom, my apologies.
> which *ought* to be very obvious.I
I have come into the middle of this conversation and am missing many
technical details (and am full of wine) but: ISTM that a "disable"
action which stopsprevents init script from stopping an already-
running daemon is rather odd. Perhaps Tom H assumed that that
wouldn't be the case, or something.
Anyway, there is no excuse for this kind of behaviour towards xsomeone
who is trying to collaburate with us to make things work properly.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Bug#977792: nodejs: install bash-completion script
Package: nodejs Version: 12.19.0~dfsg-1 Severity: wishlist Dear Maintainer, Node.js supports generating a programmable tab-completion script for Bash by running `node --completion-bash`.[1] It would be nice if the nodejs package installed the script so that it would be used by Bash whenever the bash-completion package is installed. This could be done by: 1. Generating debian/nodejs.bash-completion containing either: a. The output of `node --completion-bash` run during build. b. `eval "$(nodejs --completion-bash)"` to run node when loaded. 2. Installing debian/nodejs.bash-completion to /usr/share/bash-completion/completions/node and /usr/share/bash-completion/completions/nodejs, preferably using dh_bash-completion from the bash-completion package (which already in Build-Depends, although not currently used). Thanks for considering, Kevin [1]: https://github.com/nodejs/node/pull/20713 -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (990, 'testing-debug'), (990, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (101, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nodejs depends on: ii libc6 2.31-5 ii libnode72 12.19.0~dfsg-1 Versions of packages nodejs recommends: ii ca-certificates 20200601 ii nodejs-doc 12.19.0~dfsg-1 Versions of packages nodejs suggests: pn npm -- no debconf information
Bug#977672: redshift: AppArmor profile blocks hooks
On Mon, 21 Dec 2020 00:02:59 +0100, Tomas Janousek wrote: > > Oh ~/.config/redshift/redshift.conf > > vs. ~/.config/redshift.conf; I'm using the latter, don't know if the > > former is supported (the manpage says > > A configuration file with the name redshift.conf can optionally be placed > > in ~/.config/ > > ). > > It is, otherwise I wouldn't notice the breakage. :-) Ha! :) > It's even documented, just not in the man page: > https://github.com/jonls/redshift/blob/490ba2aae9cfee097a88b6e2be98aeb1ce990050/README.md#how-do-i-setup-a-configuration-file I see, thanks. So yeah, then the AppArmor profile needs to care about all of ~/.config/redshift/. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#977672: redshift: AppArmor profile blocks hooks
Hi,
On Sun, Dec 20, 2020 at 10:17:19PM +0100, gregor herrmann wrote:
/etc/apparmor.d/usr.bin.redshift already has
owner @{HOME}/.config/redshift.conf r,
so reading the config file works. - Oh ~/.config/redshift/redshift.conf
vs. ~/.config/redshift.conf; I'm using the latter, don't know if the
former is supported (the manpage says
A configuration file with the name redshift.conf can optionally be placed in
~/.config/
).
It is, otherwise I wouldn't notice the breakage. :-)
It's even documented, just not in the man page:
https://github.com/jonls/redshift/blob/490ba2aae9cfee097a88b6e2be98aeb1ce990050/README.md#how-do-i-setup-a-configuration-file
--
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/
Bug#976914: git-buildpackage: FTBFS on ppc64el (arch:all-only src pkg): AssertionError: GitRepositoryError not raised
Control: tag -1 + patch
Control: retitle -1 git-buildpackage FTBFS when /etc/lsb-release does not exist
Hi,
On Wed, Dec 09, 2020 at 09:59:23AM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on ppc64el. At the same time, it did not fail on amd64.
> [...]
> > >> begin captured logging <<
> > gbp: info: Failed to read OS release file /etc/lsb-release: [Errno 2] No
> > such file or directory: '/etc/lsb-release'
> > gbp: debug: ['git', 'rev-parse', '--show-cdup']
> > - >> end captured logging << -
> > SKIP: Skipping 'tests.component', since this is not a git checkout.
> > >> begin captured logging <<
I was able to reproduce the issue on amd64, so you might want to remove
the ftbfs-ppc64 usertag? It is sufficient for /etc/lsb-release not to exist.
Please find enclosed 2 patches that solve the issue, at least in my environment.
You might want to check those on Ubuntu, but I believe it should work fine
there.
Best,
nicoo
From 21e2cf0c2fd66d2781659bc57b8246faf2a147d7 Mon Sep 17 00:00:00 2001
From: nicoo
Date: Sun, 20 Dec 2020 23:35:57 +0100
Subject: [PATCH 1/2] tests/11_test_dch_main.py: Don't expect /etc/lsb-release
on Debian
---
tests/11_test_dch_main.py | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/11_test_dch_main.py b/tests/11_test_dch_main.py
index 14cf593..f88959f 100644
--- a/tests/11_test_dch_main.py
+++ b/tests/11_test_dch_main.py
@@ -9,16 +9,16 @@ from .testutils import (DebianGitTestRepo, OsReleaseFile, skip_without_cmd,
from gbp.scripts import dch
import os
+import platform
import re
# Older dch compatibility
default_urgency = get_dch_default_urgency()
# For Ubuntu compatibility
-os_release = OsReleaseFile('/etc/lsb-release')
-
# OS release codename and snapshot of version 0.9-2~1
-if os_release['DISTRIB_ID'] == 'Ubuntu':
+if 'Ubuntu' in platform.version():
+os_release = OsReleaseFile('/etc/lsb-release')
os_codename = os_release['DISTRIB_CODENAME']
snap_header_0_9 = r'^test-package\s\(0.9-1ubuntu1~1\.gbp([0-9a-f]{6})\)\sUNRELEASED;\surgency=%s' % default_urgency
new_version_0_9 = '0.9-1ubuntu1'
--
2.29.2
From 971b0a622dcd1bc5ca5f3b4cd97470ff7799c0bc Mon Sep 17 00:00:00 2001
From: nicoo
Date: Sun, 20 Dec 2020 23:43:27 +0100
Subject: [PATCH 2/2] doctests/test_Changelog: Don't expect /etc/lsb-release
See #976914
---
tests/doctests/test_Changelog.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/doctests/test_Changelog.py b/tests/doctests/test_Changelog.py
index 1fb8a30..a1e4311 100644
--- a/tests/doctests/test_Changelog.py
+++ b/tests/doctests/test_Changelog.py
@@ -262,7 +262,7 @@ def test_add_section():
>>> import shutil
>>> import gbp.deb.changelog
>>> from ..testutils import OsReleaseFile
->>> os_release = OsReleaseFile('/etc/lsb-release')
+>>> os_release = OsReleaseFile()
>>> olddir = os.path.abspath(os.path.curdir)
>>> testdir = tempfile.mkdtemp(prefix='gbp-test-changelog-')
>>> testdebdir = os.path.join(testdir, 'debian')
@@ -309,7 +309,7 @@ def test_add_entry():
>>> import shutil
>>> import gbp.deb.changelog
>>> from ..testutils import OsReleaseFile
->>> os_release = OsReleaseFile('/etc/lsb-release')
+>>> os_release = OsReleaseFile()
>>> olddir = os.path.abspath(os.path.curdir)
>>> testdir = tempfile.mkdtemp(prefix='gbp-test-changelog-')
>>> testdebdir = os.path.join(testdir, 'debian')
--
2.29.2
signature.asc
Description: PGP signature
Bug#975591: update-rc.d disable
On Sun, 20 Dec 2020, Tom H wrote: > > There *absolutely* HAS to be some way to disable an init script > It depends what's meant by "disable". Which part of “disable an init script” did you not understand? > If it means "disable from starting at boot", then No. > If it means "disable from starting at all", then "update-rc.d No. It means “do not call this init script in any runlevel”, which *ought* to be very obvious. > It feels like a lot of work for an unusual corner case. It’s by no means an unusual corner case. Installing a package to have a dæmon binary (or really any file from it) available but not intending for the initscript to run isn’t anything special. There’s even standardised-ish ways to do so (chmod -x the dæmon binary), which however won’t be usable if users need to start it manually. (Curiously wondering whether systemd handles _this_ right…) bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in Form von Beratung, Trainings sowie Workshops in den Bereichen Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung sowie Agile Organisation. Besuchen Sie uns auf https://www.tarent.de/consulting . Wir freuen uns auf Ihren Kontakt. *
Bug#975687: xterm: loses text lines, even descenders from some lines
Thomas Dickey dixit:
>how far below?
>
>Just the window-decoration, or a line or so?
About a line, give or take (for the syslog window, the last line
is the cursor, so I don’t need it, and I took a bit more than a
line there; for that test, it’s a bit less).
>Looking at the changes for #361, there's the changes for wrap-mark,
>and copy-wait. The latter was just this:
I did…
begin 644 xterm_362-1.0.1.debdiff
M9`M3G)U('AT97)M+3,V,B]D96)I86XO8VAA;F=E;&]G('AT97)M+3,V
M,B]D96)I86XO8VAA;F=E;&]G"BTM+2!X=&5R;2TS-C(O9&5B:6%N+V-H86YG
M96QO9PDR,#(P+3$Q+3$U(#$V.C,T.C,V+C`P,#`P,#`P,"`K,#$P,`HK*RL@
M>'1E'1E3UM961I=6T**PHK("`J($YO
M;BUM86EN=&%I;F5R('5P;&]A9"X**R`@*B!497-T('!A=&-H("@C.3'1E'!O2P@5E=I;F1O=RAS8W)E96XI+"!%
M>'!O2D["BL@"7-W:71C:"`HPHK(`EC87-E($5X<&]S93H**R`)("`@($AA;F1L945X<&]S=7)E*'AW+"`F
M'1E
Bug#917401: lvm2-lockd: please add cmirrord
Please include for bullseye release if possible: cmirrord is the daemon that tracks mirror log information in a cluster. It is specific to device-mapper based mirrors (and by extension, LVM cluster mirrors). Cluster mirrors are not possible without this daemon running. -- Valentin
Bug#975687: xterm: loses text lines, even descenders from some lines
On Sun, Dec 20, 2020 at 07:47:15PM +, Thorsten Glaser wrote:
> Thomas Dickey dixit:
>
> >I see that version in testing, but don't see a problem on the screen.
> >I made a short script to cat those lines to the terminal, sleeping 0.2
> >seconds between bursts, and the result looks ok, even with a magnifier.
>
> Indeed, tricky. I experimented with this a bit.
>
> I can reproduce this if I change your script from while true
> to for x in 1 2 3 (so it does that only three times) but, and
> this is important, move the xterm so that its bottom is below
> the bottom end of the X11 screen.
how far below?
Just the window-decoration, or a line or so?
From the screenshot in your followup, I'm guessing the latter.
> If I move the syslog terminal up by a few pixels, the problem
> does not happen.
>
> If I use other terminal, font, etc. sizes, I also get display
> corruption effects which vary (see screenshot).
>
> If I switch virtual workspaces (Ctrl-Alt-[1-8←→] in evilwm)
> the effects go away as well.
...repainting uses a different path.
> Maybe you can reproduce it with this info?
I'll try that. (Of course if it depends on video hardware, etc., that
won't succeed).
Looking at the changes for #361, there's the changes for wrap-mark,
and copy-wait. The latter was just this:
REV:1.859 util.c 2020/10/14 00:45:31 tom
tags:xterm-361a, xterm-361, xterm-360e
replace a call to XWindowEvent (which will block if there's no exposure
events) in CopyWait with a call to XCheckWindowEvent (which lets me bail
out on no more exposure events). That seems to fix a hang reported by
Dave Kemper when iconifying/deiconifying while blasting lots of characters
to an active icon. The XWindowEvent call dates back to 1991.
--- util.c 2020/10/01 08:11:43 1.858
+++ util.c 2020/10/14 00:45:31 1.859
@@ -1,4 +1,4 @@
-/* $XTermId: util.c,v 1.857 2020/09/29 08:05:41 tom Exp $ */
+/* $XTermId: util.c,v 1.858 2020/10/01 08:11:43 tom Exp $ */
/*
* Copyright 1999-2019,2020 by Thomas E. Dickey
@@ -2082,8 +2082,10 @@
return;
#endif
-for (;;) {
- XWindowEvent(screen->display, VWindow(screen), ExposureMask, );
+while (XCheckWindowEvent(screen->display,
+VWindow(screen),
+ExposureMask,
+)) {
switch (reply.type) {
case Expose:
HandleExposure(xw, );
as part of this:
https://github.com/ThomasDickey/xterm-snapshots/commit/d98fb8ac7854e9b7906e7d1e65cf446ba6c78432#diff-e21ac3db1fb1f4c2521d0911da5ca3414412766a9aecad6c4c0cfad5d67b5165R2085
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Bug#977791: ecaccess: Wrong homepage + new version
Package: ecaccess Version: 4.0.1-1 Severity: normal I have see that the project homepage do not respond anymore: https://www.ecmwf.int/services/ecaccess I think that the homepage is: https://confluence.ecmwf.int/display/ECAC/ECaccess+Home I think that there is a new version 4.0.2 Ciao Davide
Bug#977790: ITP: far2l -- Linux port of FAR v2
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: far2l Version : 2.2+git20201201 Upstream Author : Eugene Roshal, Far Group * URL : https://github.com/elfmz/far2l https://www.farmanager.com/ * License : GPL-2+ Description : Linux port of FAR v2 This is a clone of FAR manager for Windows, similar, but more powerful than Norton Commander/Midnight Commander. . Plug-ins that are currently working: - NetRocks (SFTP/SCP/FTP/FTPS/SMB/NFS/WebDAV) - colorer - multiarc - tmppanel - align - autowrap - drawline - editcase - SimpleIndent
Bug#977789: easyloggingpp: Wrong homepage
Package: easyloggingpp Version: 9.96.7+dfsg-1 Severity: normal I have see that the project homepage do not respond anymore: https://muflihun.github.io/easyloggingpp/ I think that the homepage is: https://github.com/amrayn/easyloggingpp Ciao Davide
Bug#977788: tcptraceroute: typo "furst_ttl" in help message
Package: traceroute Version: 1:2.1.0-2+b1 Severity: minor File: /usr/sbin/tcptraceroute.db X-Debbugs-Cc: j...@joshtriplett.org The usage message for tcptraceroute prints: Usage: /usr/sbin/tcptraceroute [-hvnFSAE] [-i dev] [-f furst_ttl] [-l length] [-q nqueries] [-t tos] [-m max_ttl] [-p src_port] [-s src_addr] [-w wait_time] host [dest_port] [length] s/furst/first/ -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages traceroute depends on: ii libc6 2.31-6 traceroute recommends no packages. traceroute suggests no packages. -- no debconf information
Bug#969329: systemd-cron: Special user nobody configured, this is not safe!
Hi, I don't know how to properly fix this. Using "root:root" seems worse. A P.R. against upstream repo is welcomed. Alexandre Le lun. 31 août 2020 à 16:54, Martin-Éric Racine a écrit : > > Package: systemd-cron > Version: 1.5.14-2 > Severity: important > > Since a recent upgrade, systemd complains loudly via dmesg: > > [ 45.787544] systemd[1]: /lib/systemd/system/cron-failure@.service:11: > Special user nobody configured, this is not safe! > [ 45.864175] systemd[1]: /lib/systemd/system/cron-failure@.service:11: > Special user nobody configured, this is not safe!
Bug#977787: RM: libcroco -- RoQA; Unmaintained upstream, open security bugs, no reverse deps
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: s...@debian.org Please remove libcroco. It's unmaintained upstream (967026) and there are no reverse deps (except two vendored copies, which makes sense here as they use libcroco with trusted CSS input). Cheers, Moritz
Bug#977672: redshift: AppArmor profile blocks hooks
On Sun, 20 Dec 2020 22:06:19 +0100, Tomas Janousek wrote:
> On Fri, Dec 18, 2020 at 04:03:11PM +0100, gregor herrmann wrote:
> > Seems like there should be something about
> > @{HOME}/.config/redshift/hooks
> > in /etc/apparmor.d/usr.bin.redshift
>
> Not just hooks, ~/.config/redshift/redshift.conf as well. Probably best to
> allow all of ~/.config/redshift/ I guess?
/etc/apparmor.d/usr.bin.redshift already has
owner @{HOME}/.config/redshift.conf r,
so reading the config file works. - Oh ~/.config/redshift/redshift.conf
vs. ~/.config/redshift.conf; I'm using the latter, don't know if the
former is supported (the manpage says
A configuration file with the name redshift.conf can optionally be placed in
~/.config/
).
Cheers,
gregor
--
.''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
`. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
`- NP: Melissa Etheridge: My Lover
signature.asc
Description: Digital Signature
Bug#977786: O: pyecm -- integer factorization with the Elliptic Curve Method (ECM)
Package: wnpp Severity: normal I intend to orphan the pyecm package. It is little-used (popcon score 19). The package description is: pyecm is a Python program to factor numbers using the Elliptic Curve Method (ECM). It is relatively fast in that it can quickly factors numbers up to 50 digits. . Because it is written in Python, pyecm is very portable. It is also fairly easy to use. Use of python-gmpy and/or python-psyco will speed it up immensely.
Bug#977672: redshift: AppArmor profile blocks hooks
Hi,
On Fri, Dec 18, 2020 at 04:03:11PM +0100, gregor herrmann wrote:
Seems like there should be something about
@{HOME}/.config/redshift/hooks
in /etc/apparmor.d/usr.bin.redshift
Not just hooks, ~/.config/redshift/redshift.conf as well. Probably best
to allow all of ~/.config/redshift/ I guess?
--
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, https://work.lisk.in/
Bug#977785: RFS: task-spooler/1.0.1+dfsg1-1 -- personal job scheduler
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "task-spooler": * Package name: task-spooler Version : 1.0.1+dfsg1-1 Upstream Author : Lluís Batlle i Rossel * URL : https://viric.name/soft/ts/ * License : GPL-2, LDP-GPL-1 * Vcs : https://salsa.debian.org/debian/task-spooler/ Section : misc It builds those binary packages: task-spooler - personal job scheduler To access further information about this package, please visit the following URL: https://mentors.debian.net/package/task-spooler/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/t/task-spooler/task-spooler_1.0.1+dfsg1-1.dsc Changes since the last upload: task-spooler (1.0.1+dfsg1-1) unstable; urgency=medium . * Change http to https in urls * New upstream version 1.0.1+dfsg1 * Drop applied patch * Refresh ts to tsp renaming patch (Closes: #905902) * Minor man page fixes * Bump Standards-Version to 4.5.1 (no changes)
Bug#977775: RFS: runit/2.1.2-39 -- system-wide service supervision
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: plore...@disroot.org Dear mentors, I am looking for a sponsor for my package "runit": this version reintroduces an empty transitional runit-systemd package, as I haven't found a better solution for #976187 * Package name: runit Version : 2.1.2-39 Upstream Author : Gerrit Pape * URL : http://smarden.org/runit/ * License : BSD-3-clause * Vcs : https://salsa.debian.org/debian/runit Section : admin It builds those binary packages: runit-init - system-wide service supervision (as init system) getty-run - runscripts to supervise getty processes runit-systemd - transitional package for runit-systemd users runit-run - service supervision (systemd and sysv integration) runit - system-wide service supervision To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-39.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/runit/-/tree/2.1.2-39-release Changes since the last upload: runit (2.1.2-39) unstable; urgency=medium . * Enable shutdown on ctrl-alt-del keyboard request * Bump Standards Version to 4.5.1 * Reintroduce transitional runit-systemd package (Closes: #976187) * Add a news file for runit-init Regards, -- Lorenzo Puliti
Bug#977781: [Pkg-javascript-devel] Bug#977781: Bug#977781: yarnpkg: fails to download modules
On Mon, Dec 21, 2020 at 1:46 am, Pirate Praveen wrote: We need to create ~/.yarnrc.yml to create node_modules directory. $ cat ~/.yarnrc.yml nodeLinker: "node-modules" $ yarnpkg install \➤ YN: ┌ Resolution step ➤ YN: └ Completed ➤ YN: ┌ Fetch step ➤ YN: └ Completed ➤ YN: ┌ Link step ➤ YN: └ Completed ➤ YN: Done in 0s 203ms pravi@mahishi:/tmp/project1$ ls node_modules package.json README.md yarn.lock pravi@mahishi:/tmp/project1$ ls node_modules/ d3-color pravi@mahishi:/tmp/project1$ ls node_modules/d3-color/ dist LICENSE package.json README.md src In the worst case scenario if we cannot get this working, we can document how to setup yarn 2 using the package instead of dropping this from bullseye. We may have to update description and move to contrib in that case. We can at least built this in bullseye, which is an improvement from the earlier state where we had to use snapshot.debian.org to build and bootstrap.
Bug#977784: magicfilter: reproducible builds: embeds different paths when built on a usrmerge system
Source: magicfilter Version: 1.2-65 Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: usrmerge X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Various files in /etc/magicfilter contain different paths to bzip2 and gzip when build on a usrmerge system: https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/magicfilter.html ./etc/magicfilter/tek4696-filter 0·BZh·pipe·/bin/bzip2·-cdq vs. 0·BZh·pipe·/usr/bin/bzip2·-cdq The attached patch fixes this in debian/rules by passing GZIP and BZIP2 to configure. live well, vagrant From 833e77e9ad1d269969094c07e72f119b434a8a91 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 20 Dec 2020 20:00:40 + Subject: [PATCH 7/8] debian/rules: Pass GZIP and BZIP2 to configure. The paths to "gzip" and "bzip2" are embedded in various files in /etc/magicfilter. They may be located in /bin or /usr/bin if the system is configured as a usrmerge system. Use the most compatible compatible location in /bin. https://tests.reproducible-builds.org/debian/issues/paths_vary_due_to_usrmerge_issue.html --- debian/rules | 2 ++ 1 file changed, 2 insertions(+) diff --git a/debian/rules b/debian/rules index c8c81c3..c52c5f1 100755 --- a/debian/rules +++ b/debian/rules @@ -30,6 +30,8 @@ build: rm -f config.cache ./configure --prefix=/usr \ + GZIP=/bin/gzip \ + BZIP2=/bin/bzip2 \ --infodir=/usr/share/info \ --mandir=/usr/share/man \ --bindir=/usr/sbin -- 2.20.1 signature.asc Description: PGP signature
Bug#977781: [Pkg-javascript-devel] Bug#977781: yarnpkg: fails to download modules
On Mon, Dec 21, 2020 at 1:37 am, Pirate Praveen
wrote:
On Mon, 21 Dec 2020 00:39:35 +0530 Pirate Praveen
wrote:
> Since yarnpkg add command did not return an error, the autpkgtest
was
> succeeding even though it did not add any modules to node_modules
> directory.
Though this is sufficient to install yarn 2 (berry).
$ yarnpkg set version berry
Resolving berry to a url...
Downloading
https://github.com/yarnpkg/berry/raw/master/packages/berry-cli/bin/berry.js..
Saving it into /tmp/project1/.yarn/releases/yarn-berry.cjs...
Updating /tmp/project1/.yarnrc.yml...
Done!
$ yarnpkg init
{
name: 'project1'
}
pravi@mahishi:/tmp/project1$ ls
package.json README.md yarn.lock
pravi@mahishi:/tmp/project1$ yarnpkg add d3-color
➤ YN: ┌ Resolution step
➤ YN: └ Completed
➤ YN: ┌ Fetch step
➤ YN0013: │ d3-color@npm:2.0.0 can't be found in the cache and
will be fetched from
➤ YN: └ Completed in 0s 735ms
➤ YN: ┌ Link step
➤ YN: └ Completed
➤ YN: Done in 0s 797ms
$ ls .yarn/cache/
d3-color-npm-2.0.0-e7f04a5d87-637e111598.zip
gitignore
We need to create ~/.yarnrc.yml to create node_modules directory.
$ cat ~/.yarnrc.yml
nodeLinker: "node-modules"
$ yarnpkg install
\➤ YN: ┌ Resolution step
➤ YN: └ Completed
➤ YN: ┌ Fetch step
➤ YN: └ Completed
➤ YN: ┌ Link step
➤ YN: └ Completed
➤ YN: Done in 0s 203ms
pravi@mahishi:/tmp/project1$ ls
node_modules package.json README.md yarn.lock
pravi@mahishi:/tmp/project1$ ls node_modules/
d3-color
pravi@mahishi:/tmp/project1$ ls node_modules/d3-color/
dist LICENSE package.json README.md src
Bug#977781: yarnpkg: fails to download modules
On Mon, 21 Dec 2020 00:39:35 +0530 Pirate Praveen
wrote:
> Since yarnpkg add command did not return an error, the autpkgtest was
> succeeding even though it did not add any modules to node_modules
> directory.
Though this is sufficient to install yarn 2 (berry).
$ yarnpkg set version berry
Resolving berry to a url...
Downloading
https://github.com/yarnpkg/berry/raw/master/packages/berry-cli/bin/berry.js..
Saving it into /tmp/project1/.yarn/releases/yarn-berry.cjs...
Updating /tmp/project1/.yarnrc.yml...
Done!
$ yarnpkg init
{
name: 'project1'
}
pravi@mahishi:/tmp/project1$ ls
package.json README.md yarn.lock
pravi@mahishi:/tmp/project1$ yarnpkg add d3-color
➤ YN: ┌ Resolution step
➤ YN: └ Completed
➤ YN: ┌ Fetch step
➤ YN0013: │ d3-color@npm:2.0.0 can't be found in the cache and will
be fetched from
➤ YN: └ Completed in 0s 735ms
➤ YN: ┌ Link step
➤ YN: └ Completed
➤ YN: Done in 0s 797ms
$ ls .yarn/cache/
d3-color-npm-2.0.0-e7f04a5d87-637e111598.zip
gitignore
Bug#975662: RFS: pyrandom2/1.0.1-2.1 [NMU] [RC] -- backport of Python 2.7's random module
Adrian Bunk kirjoitti 20.12.2020 klo 18.26: > On Tue, Nov 24, 2020 at 10:27:27PM +0200, Juhani Numminen wrote: >> ... >> Changes since the last upload: >> >> pyrandom2 (1.0.1-2.1) unstable; urgency=medium >> . >>* Non-maintainer upload. >>* Add python3.9.patch fixing tests with py3.9 (Closes: #973085). >> ... > > Thanks, uploaded. Thank you Adrian! -- Juhani
Bug#975687: xterm: loses text lines, even descenders from some lines
On Sun, 20 Dec 2020, Thorsten Glaser wrote: > corruption effects which vary (see screenshot). Oops, attached.
Bug#975687: xterm: loses text lines, even descenders from some lines
Thomas Dickey dixit: >I see that version in testing, but don't see a problem on the screen. >I made a short script to cat those lines to the terminal, sleeping 0.2 >seconds between bursts, and the result looks ok, even with a magnifier. Indeed, tricky. I experimented with this a bit. I can reproduce this if I change your script from while true to for x in 1 2 3 (so it does that only three times) but, and this is important, move the xterm so that its bottom is below the bottom end of the X11 screen. If I move the syslog terminal up by a few pixels, the problem does not happen. If I use other terminal, font, etc. sizes, I also get display corruption effects which vary (see screenshot). If I switch virtual workspaces (Ctrl-Alt-[1-8←→] in evilwm) the effects go away as well. Maybe you can reproduce it with this info? Thanks, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#977783: magicfilter: reproducible builds: buildid changes with different build path
Source: magicfilter Version: 1.2-65 Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: buildpath X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org The file /usr/sbin/magicfilter has a different buildid when the build path changes: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/magicfilter.html GNU 0x0014» NT_GNU_BUILD_ID·(unique·build·ID·bitstring)» Build·ID:·c89260c14a143b70d63d924b4712c4b35c03a23c vs. GNU 0x0014» NT_GNU_BUILD_ID·(unique·build·ID·bitstring)» Build·ID:·487f927ccc177675cac6867f716c97792fc359c4 The attached patch fixes this in debian/rules by passing -ffile-prefix-map via CFLAGS. live well, vagrant From 668483cdcf842b4b0f36c0f4b58a98db6baec202 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Sun, 20 Dec 2020 19:32:03 + Subject: [PATCH 3/4] debian/rules: Use -ffile-prefix-map in CFLAGS to ensure reproducible builds. https://tests.reproducible-builds.org/debian/issues/unstable/gcc_captures_build_path_issue.html --- debian/rules | 3 +++ 1 file changed, 3 insertions(+) diff --git a/debian/rules b/debian/rules index 12bce98..572fedc 100755 --- a/debian/rules +++ b/debian/rules @@ -18,6 +18,9 @@ else CFLAGS += -Os endif +# Set -ffile-prefix-map for reproducible builds regardless of build path +CFLAGS += -ffile-prefix-map=$(CURDIR)=. + build: ln -sf /usr/share/misc/config.sub . ln -sf /usr/share/misc/config.guess . -- 2.20.1 signature.asc Description: PGP signature
Bug#967027: cinnamon: uses libcroco which is unmaintained upstream
Hi Simon, hi Fabio, > cinnamon >= 4.8.0 uses a bundled copy of libcroco. The last remaining thing > https://salsa.debian.org/cinnamon-team/cinnamon/-/merge_requests/12 > cinnamon-settings-daemon 4.8.2-2 fails to build on s390x, which is > https://salsa.debian.org/cinnamon-team/cinnamon-settings-daemon/-/merge_requests/3 > https://salsa.debian.org/cinnamon-team/cinnamon-settings-daemon/-/merge_requests/4 Thanks Simon for the MR and checking on the build status, much appreciated! > @Norbert: can you upload new cinnamon-settings-daemon please? (needed Thanks Fabio for preparing/merging. I am doing test builds now and will upload both cinnamon and cinnamon-settings-daemon after the builds have completed. All the best Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#977779: geary FTBFS on mipsel: test suite failure
Control: reassign -1 src:webkit2gtk 2.28.1-1 Control: affects -1 src:geary src:liferea src:evolution src:epiphany-browser On Sun, Dec 20, 2020 at 07:17:13PM +0100, Paul Gevers wrote: > Source: geary > Version: 3.38.1-1 > Severity: serious > Justification: FTBFS > Tags: ftbfs > > Dear maintainer, > > The latest version of geary fails to build on mipsel [1]. The test suite > fails. This is not specific to geary and not specific to this version of geary, the search is already ongoing for the regression that makes webkit2gtk and some rdeps FTBFS on some buildds on mipsel. > Paul cu Adrian
Bug#977781: yarnpkg: fails to download modules
Package: yarnpkg Version: 1.22.10+~cs18.39.16-1 Severity: serious Since yarnpkg add command did not return an error, the autpkgtest was succeeding even though it did not add any modules to node_modules directory. I have fixed the faulty autopkgtest which now exposes the failure.
Bug#973342: libdbi-perl 1.642-1+deb10u2 flagged for acceptance
package release.debian.org tags 973342 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: libdbi-perl Version: 1.642-1+deb10u2 Explanation: security fix [CVE-2014-10402]
Bug#977780: connman: wifi stopped working with net.connman.Error.NoCarrier
Package: connman Version: 1.36-2+b1 Severity: important Hello and thanks for maintaining this package in Debian! I've just installed it, in order to give it a try. It seemed to work like a charm, with connman-gtk GUI: I was able to connect with the Ethernet LAN, disconnect from it, connect with the Wireless LAN, disconnect from it, and all looked right. I rebooted and all looked OK again. Then, after one more reboot, I suddenly became unable to connect to the Wireless LAN, getting the following error in a dialog window: Failed to toggle connection state. GDBus.Error:net.connman.Error.NoCarrier: No carrier I really cannot understand what's going on. It seems to me that the WiFi network card is still visible: $ /sbin/ifconfig [...] wlan0: flags=-28669 mtu 1500 ether 20:68:9d:72:70:cc 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 Where did I go wrong? Please help me! Thanks for your time. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages connman depends on: ii dbus 1.12.20-1 ii iptables 1.8.6-1 ii libc6 2.31-5 ii libdbus-1-3 1.12.20-1 ii libglib2.0-0 2.66.3-2 ii libgnutls30 3.6.15-4 ii libreadline8 8.1-1 ii libxtables12 1.8.6-1 ii lsb-base 11.1.0 Versions of packages connman recommends: pn bluez pn ofono ii wpasupplicant 2:2.9.0-16 Versions of packages connman suggests: pn connman-vpn -- no debconf information
Bug#976423: pngcheck 2.3.0-7+deb10u1 flagged for acceptance
package release.debian.org tags 976423 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: pngcheck Version: 2.3.0-7+deb10u1 Explanation: fix buffer overflow [CVE-2020-27818]
Bug#976392: node-y18n 3.2.1-2+deb10u1 flagged for acceptance
package release.debian.org tags 976392 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: node-y18n Version: 3.2.1-2+deb10u1 Explanation: fix prototype pollution issue [CVE-2020-7774]
Bug#973706: lttng-modules 2.10.8-1+deb10u1 flagged for acceptance
package release.debian.org tags 973706 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: lttng-modules Version: 2.10.8-1+deb10u1 Explanation: fix build on kernel versions >= 4.19.0-10
Bug#970745: pdns 4.1.6-3+deb10u1 flagged for acceptance
package release.debian.org tags 970745 = buster pending thanks Hi, The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian buster. Thanks for your contribution! Upload details == Package: pdns Version: 4.1.6-3+deb10u1 Explanation: security fixes [CVE-2019-10203 CVE-2020-17482]
Bug#977701: gitlab: Missing assets, breaking some functionalities
On Sat, 19 Dec 2020 21:10:09 +0530 Pirate Praveen wrote: > Some dependencies of node-css-loader need node-postcss 8 where as > node-css-loader itself need an update to use node-postcss 8. So it will > take a while to untangle this mess. Unfortunately updating css-loader and postcss did not fix this issue :(
Bug#976386: transition: octave
Hi Paul, Le dimanche 20 décembre 2020 à 19:24 +0100, Paul Gevers a écrit : > On 20-12-2020 19:15, Sébastien Villemot wrote: > > I’m not familiar with britney’s output, but my impression is that the > > problem is related to src:plplot. The version in testing currently > > builds a binary package named octave-plplot, which has been dropped in > > the version currently in unstable (because it was not possible to build > > it against octave 6). > > > > Maybe britney needs to be given some hint to force the transition. > > plplot is part of the gnat-10 transition, which means the transitions > now got entangled. I'm not following close enough to know what that > means now. My understanding is that the gnat-10 transition is not a blocking factor, since gnat-10 is already in testing (as part of src:gcc-10). But maybe I got it wrong. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#976386: transition: octave
Hi Sébastien, On 20-12-2020 19:15, Sébastien Villemot wrote: > I’m not familiar with britney’s output, but my impression is that the > problem is related to src:plplot. The version in testing currently > builds a binary package named octave-plplot, which has been dropped in > the version currently in unstable (because it was not possible to build > it against octave 6). > > Maybe britney needs to be given some hint to force the transition. plplot is part of the gnat-10 transition, which means the transitions now got entangled. I'm not following close enough to know what that means now. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#977779: geary FTBFS on mipsel: test suite failure
Source: geary Version: 3.38.1-1 Severity: serious Justification: FTBFS Tags: ftbfs Dear maintainer, The latest version of geary fails to build on mipsel [1]. The test suite fails. Paul [1] https://buildd.debian.org/status/package.php?p=geary OpenPGP_signature Description: OpenPGP digital signature
Bug#976386: transition: octave
Le mercredi 09 décembre 2020 à 17:06 +0100, Sébastien Villemot a écrit : > Le mardi 08 décembre 2020 à 11:31 +0100, Sebastian Ramacher a écrit : > > On 2020-12-04 13:32:04 +0100, Sébastien Villemot wrote: > > > Please schedule a transition for octave 6, which currently sits in > > > experimental. > > Please go ahead. > > Thanks. The new version of octave has been uploaded to unstable and is > now built and installed on all release archs. It’s been several days since the transition has (apparently) been ready to migrate to testing, still it did not. I’m not familiar with britney’s output, but my impression is that the problem is related to src:plplot. The version in testing currently builds a binary package named octave-plplot, which has been dropped in the version currently in unstable (because it was not possible to build it against octave 6). Maybe britney needs to be given some hint to force the transition. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#880556: parse upstream metadata files like package.json or .gemspec files
On samedi 12 décembre 2020 19:32:54 CET you wrote: > Have you had a chance to have a look at it? Done. The last version of libconfig-model-dpkg-perl can parse Config.toml file. Please check if this fits your requirements. All the best Dod
Bug#977778: Quit early when given Unknown pattern types
Package: aptitude Version: 0.8.13-2+b1 Severity: wishlist This should bomb out right away, with "E: Unknown pattern type: h", instead of doing all that work first: # aptitude search ~h [ 0%] Reading package lists [100%] Reading package lists [ 0%] Building dependency tree [100%] Building dependency tree [ 0%] Reading state information [ 11%] Reading state information [ 0%] Reading extended state information [ 0%] Initializing package states [ 0%] Building tag database [100%] Building tag database E: Unknown pattern type: h (Made with # script /tmp/m ... # tr \\r \\n < /tmp/m | col |sed /^$/d )
Bug#873184: please drop transitional package netcat
Hi Holger and anyone watching, * Holger Levsen [201220 17:56]: > Please drop transitional package netcat for Buster, as it has been released > with (at least) Wheezy, Jessie and Stretch.h. For bullseye, netcat now depends on netcat-openbsd. I intend to drop netcat in bullseye+1 (=bookworm). Chris
Bug#974011: xmille: Incorrect license/copyright for xmille
On Sunday, December 20, 2020 9:44:46 A.M. CST Adrian Bunk wrote: > On Mon, Dec 07, 2020 at 09:12:23AM -0800, Keith Packard wrote: > > Adrian Bunk writes: > > > Keith, do you remember the copyright history of this code? > > > > I may have copied the underlying mille sources *before* copyrights were > > added to each file; I started work on the X10 version of xmille around > > 1985 or 1986. I guess I could have mistakenly removed them? Thanks for > > discovering this error; I can fix these "upstream" and publish a new > > version? > > I am just a user who would like to see this package also in bullseye. > > A new upstream version would be good, but it is not obvious to me > whether you or Steve M. Robbins or anyone else is considered upstream > or should become upstream (again). Upstream is definitely NOT me ! :-) signature.asc Description: This is a digitally signed message part.
Bug#976886: movim: Blocking transition of php-illuminate-database
Control: tags -1 patch
Control: severity -1 serious
Dear maintainers,
Here's my proposed patch for php-illuminate-database 6 compatibility.
I'll pursue a NMU soon if there are no objections.
I'm bumping the severity of this bug to serious. That seems to be the
adviced severity according to the transition workflow [1].
[1] https://wiki.debian.org/Teams/ReleaseTeam/Transitions
Regards,
Robin
From 9880ccb83e0c46120c7f5467b328519e2a8e7d22 Mon Sep 17 00:00:00 2001
From: Robin Gustafsson
Date: Sun, 20 Dec 2020 14:08:36 +0100
Subject: [PATCH] Use php-illuminate-database 6
---
debian/autoload.php | 2 +-
debian/patches/composer-versions.diff | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/debian/autoload.php b/debian/autoload.php
index 3401dff..7f04fc3 100644
--- a/debian/autoload.php
+++ b/debian/autoload.php
@@ -2,7 +2,7 @@
require_once('Composer/Autoload/ClassLoader.php');
include_once('/usr/share/php/HTMLPurifier.composer.php');
-include_once('/usr/share/php/Illuminate/Support/helpers.php');
+include_once('/usr/share/php/Illuminate/Database/autoload.php');
include_once('/usr/share/php/GuzzleHttp/Psr7/functions_include.php');
include_once('/usr/share/php/React/Promise/functions_include.php');
include_once('/usr/share/php/React/Promise/Stream/functions_include.php');
diff --git a/debian/patches/composer-versions.diff b/debian/patches/composer-versions.diff
index cbf3930..c54531c 100644
--- a/debian/patches/composer-versions.diff
+++ b/debian/patches/composer-versions.diff
@@ -25,9 +25,8 @@ Subject: Amend composer dependencies to use Debian versions
"defuse/php-encryption": "^2.2.1",
-"robmorgan/phinx": "^0.11.4",
--"illuminate/database": "^6.0",
+"robmorgan/phinx": "^0.9",
-+"illuminate/database": "^5.8",
+ "illuminate/database": "^6.0",
"doctrine/dbal": "^2.10",
"cboden/ratchet": "^0.4.2",
--
2.20.1
Bug#977777: ITP: kodi-inputstream-rtmp -- Kodi input stream addon for RTMP
Package: wnpp Severity: wishlist Owner: Vasyl Gello X-Debbugs-Cc: debian-de...@lists.debian.org, mat...@debian.org, rbal...@debian.org * Package name: kodi-inputstream-rtmp Version : 3.4.0 Upstream Author : Ross Nicholson * URL : https://github.com/xbmc/inputstream.rtmp * License : GPL-2+ Programming Lang: C++ Description : Kodi input stream addon for RTMP This package is the RTMP Inputstream addon for Kodi. The Real Time Messaging Protocol (RTMP) is a proprietary network protocol developed by Adobe Inc. to transmit audio, video and other data over the Internet from a media server to a flash player. In particular, it is needed by Kodi PVR addon 'kodi-pvr-i[tvsimple'
Bug#932267: pdns-recursor: PDNS Recursor by default does not support IPv6
* Chris Hofstaedtler [201220 17:32]: > * Mark Schouten [190717 10:09]: > > 2: set local-address to 127.0.0.1, [::1] to enable listening on ::1 This has become the default in current versions. Chris
Bug#977776: ITP: matrix-construct -- homeserver for the Matrix protocol
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard X-Debbugs-Cc: debian-de...@lists.debian.org, Matrix Packaging Team -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: matrix-construct Version : 0.3.22 Upstream Author : Jason Volk * URL : https://github.com/matrix-construct/construct * License : ISC Programming Lang: C++ Description : homeserver for the Matrix protocol Construct is a fast and highly scalable Matrix homeserver. . Matrix is an open, federated communications protocol. This package will be maintained in the Matrix team. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/fimsACgkQLHwxRsGg ASESSg/8CtKSW3FhKBLAwHSzkDoSMmbjC3+uraH/BMWtU51IcermBKww7WGpH+GB XXVOSUHK3Pcb5eb5OqF8uzj3TV9kgG8rMd62Vol5jl87Cq12SbliDihGicX/cCPz gCQ4oeWX/KCenJhmhvl6OQlFBRxDwKowXc1p7Z/KzfYYHN0pSML50fdhE4ZagdLO hIOO7fF9n2i/WVNfsd1hxHJO+dR7ESBXqZTUPgTdqW0VQGOVTiMNi6CDGDiHy831 wGF0ECNiTQ27Xmi1ULi2XwjwxSfjmBFHv5Lpi5UGeHUQr8FK/3FTyAUb5Z9T+wqV RSl+lTZfWXtaiDj9T60wLSrcqg0WtLxHJA/FQwhPOR6HPDQ7N32WnY1U4QYCNwzV mxQFdZk6rW6RkbBkjEeQCTOKeEgfrcYIOJvmOXz+s6kkhgsU6v8S2muynYlLeJb8 jjQJ0aTupn8vKgVTLal04z3IU01xjNITg1fcdxNXOWzotsAi8de/KmcYYor3hCcW JVZmteofuErIc+u/aSHBtM8oRp71GahcrNpPRgk6kVLNYGCt9Nv7W+sFhb0J6p6j Av1zlfqVEks2Ii+4dKHfPlETHkYXBEhp69Bi3LFiQS4Jng+vZLnpb8i6FcpomtCy OL9cInmLw34hRbjcZ/fZ5zkbQrtW6iKgRoLSV0kAV6RpxIezrmk= =mJJK -END PGP SIGNATURE-
Bug#962675: can cdbfasta be marked Multi-Arch: foreign?
Ping. Can we close this bug? Kind regards, Andreas. On Sat, Jun 13, 2020 at 12:46:28PM +0200, Andreas Tille wrote: > On Thu, Jun 11, 2020 at 10:45:13PM +0200, Andreas Tille wrote: > > > microbiomeutil fails to cross build from source, because it fails > > > running cdbfasta with an "Exec format error". > > I've just uploaded cdbfasta_1.00+git20181005.014498c+dfsg-1. > You did not specified the exact error of microbiomeutil, but if > you would specify the very command line we could add this to > autopkgtest of the package (in case this might help). > > Please check again since from my naive point of view the package > should not cause any issues. > > Kind regards > > Andreas. > > -- > http://fam-tille.de > > ___ > Debian-med-packaging mailing list > debian-med-packag...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging -- http://fam-tille.de
Bug#922860: Bug#946924: Patch to remove any need for libhts-private-dev
Hi John, I admit I think we have implemented the points you were interested in. Do you agree that we can close this bug or am I missing something? Kind regards Andreas. -- http://fam-tille.de
Bug#957037: biboumi: ftbfs with GCC-10
Quoting Michel Le Bihan (2020-12-20 17:15:29) > Le dimanche 20 décembre 2020 à 16:50 +0100, Jonas Smedegaard a écrit : > > Quoting Michel Le Bihan (2020-12-20 16:06:27) > > > A quick summary of the differences between both repos: > > > > Thanks, that is no doubt helpful! > > > > [ beware: commenting without actually having looked at the code! ] > Please look at it when you will have time. Most likely no: Instead, please wait for Vasudev to look at it. > > Now that you joined the team maintaining the package, it is not an > > NMU. > > > Should I change that? Somebody would have to add me to debian/control, > but I don't want to rebase my fork on that commit for that change. My point was more general about when that annotation was needed. I'll leave the details of handling this concrete changeset to Vasudev. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#957037: biboumi: ftbfs with GCC-10
[ replying to bugreport - please keep conversation public ] Quoting Michel Le Bihan (2020-12-20 16:57:36) > Yes. I wasn't able to find doc on that on my own. tarpman and wRAR > from #debian-mentors helped me with that and pointed me to > file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.upstream- > git.html#gbp.import.upstream.git.tarball Thanks for (sort of) confirming that such usage comment might be of help. I will continue my practice of adding it to packages I maintain. > I actually used: > ``` > git remote add upstream https://lab.louiz.org/louiz/biboumi.git > git fetch upstream > gbp import-orig --pristine-tar --upstream-vcs-tag=9.0 > https://lab.louiz.org/louiz/biboumi/-/archive/9.0/biboumi-9.0.tar.bz2 > ``` Thanks for sharing. Your commands lead to same result in the git shared among maintainers, so not bad. My command is shorter (option --pristine-tar is already defined in config file) and smarter (option --uscan resolved upstream tarball URL from the watch file hint): gbp import-orig --upstream-vcs-tag=9.0 --uscan Also, beware that naming the _remote_ "upstream" is easily confused with _branch_ name "upstream" (or the recommended branch name "upstream/latest" not yet used in biboumi package - see https://dep-team.pages.debian.net/deps/dep14/ ). I name it "upstream-git" to disambiguate. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#977774: lshw: Bump lshw to B.02.19 version
Package: lshw Version: 02.18.85-0.5 Severity: normal X-Debbugs-Cc: eric.desroch...@canonical.com Dear Maintainer, lshw B.02.19 has been released last March: https://ezix.org/project/wiki/HardwareLiSter#Changes This version include the following: - Detection of NVMe disks - Detection of SD/MMC and SDIO devices - Bug fixes (segmentation faults, crashes,) - Code cleanup - Updated data files The most notable change is the NVME support. This is a feature users want to see landing in distros. Other references to support the request: https://launchpad.net/bugs/1826737 https://bugzilla.redhat.com/show_bug.cgi?id=1695343
Bug#977726: debbugs: Decode non-ascii "Done:" field in HTML output
reassign 977726 dak retitle 977726 Done: psuedoheader should not be mime encoded tag 977726 patch thanks On Sat, 19 Dec 2020, Rafael Laboissière wrote: > The header "Done:" in the web pages for the individual bugs are > wrongly displayed when the name of the person who closed the bug > contains non-ASCII characters. This is the case of my name, as we can > see in Bug#976382 [1]: This is because my fix for #950132 in dak was wrong, and used the mime-encoded Maintainer field instead of the unencoded maintainer field. The attached patch addresses this issue. -- Don Armstrong https://www.donarmstrong.com I really wanted to talk to her. I just couldn't find an algorithm that fit. -- Peter Watts _Blindsight_ p294 From ae4b846e8ac95f0bf51c4aa300de40336ef9f657 Mon Sep 17 00:00:00 2001 From: Don Armstrong Date: Sun, 20 Dec 2020 08:04:59 -0800 Subject: [PATCH] The Done: field in the bug-close e-mails should not be mime-encoded This alters commit 53b2e48a05cf to use __MAINTAINER__ which is not mime-encoded instead of __MAINTAINER_FROM__. Closes #977726 --- templates/process-unchecked.bug-close | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/templates/process-unchecked.bug-close b/templates/process-unchecked.bug-close index 58a024ea..ceea21ab 100644 --- a/templates/process-unchecked.bug-close +++ b/templates/process-unchecked.bug-close @@ -11,7 +11,7 @@ Subject: Bug#__BUG_NUMBER__: fixed in __SOURCE__ __VERSION__ Source: __SOURCE__ Source-Version: __VERSION__ -Done: __MAINTAINER_FROM__ +Done: __MAINTAINER__ We believe that the bug you reported is fixed in the latest version of __SOURCE__, which is due to be installed in the __DISTRO__ FTP archive. -- 2.29.2
Bug#957037: biboumi: ftbfs with GCC-10
Le dimanche 20 décembre 2020 à 16:50 +0100, Jonas Smedegaard a écrit : > Quoting Michel Le Bihan (2020-12-20 16:06:27) > > A quick summary of the differences between both repos: > > Thanks, that is no doubt helpful! > > [ beware: commenting without actually having looked at the code! ] Please look at it when you will have time. > > > 2. Aluaces package might be missing man pages. Upstream is now > > using > > Sphinx instead of Pandoc. I added a patch to build man and updated > > control. They put doc/*.rst in examples and I put it in doc. > > > I also moved the new example config to `/etc/biboumi/biboumi.cfg` > > since most packages install example config directly in their final > > location in `/etc`. > > If "sample" config files are working out of the box then good - > otherwise not. > > > > 3. I updated copyright hints. > > Only update copyright_hints if you update copyright file as needed - > otherwise better that you do *not* update copyright_hints: The hints > file being out of sync is a way to recognize that copyright file is > pending a closer examination. > New doc location, tests added and some source files. In my opinion that does not require an update to the copyright file, but I ack the changes. > > > 4. My release is marked NMU. > > Now that you joined the team maintaining the package, it is not an > NMU. > Should I change that? Somebody would have to add me to debian/control, but I don't want to rebase my fork on that commit for that change. > > - Jonas >
Bug#977209: marked as done (transition: proftpd-dfsg)
On Sun, Dec 13, 2020 at 11:24:02PM +, Debian Bug Tracking System wrote: Thanks for scheduling. I just noticed that there was no abi change between proftpd-dfsg 1.3.7a & proftpd-dfsg 1.3.7a+dfsg. I just thought there was one as [1] reported that our module packages were not installable short time ago. Closing. Note that 1.3.7a+dfsg is identical to 1.3.7a for the source code, it only removed pieces of documentation, so there was no reason to change ABI version. -- Francesco P. Lovergine
Bug#956251: xscreensaver-demo do not handle correctly domain part of usernames
FYI, my first patch above was applied in upstream 5.45 and will appear in 5.45-1 in unstable soon. Please let us know if it works fine with your SSSD. Tormod
Bug#957037: biboumi: ftbfs with GCC-10
Quoting Michel Le Bihan (2020-12-20 16:06:27) > A quick summary of the differences between both repos: Thanks, that is no doubt helpful! [ beware: commenting without actually having looked at the code! ] > 2. Aluaces package might be missing man pages. Upstream is now using > Sphinx instead of Pandoc. I added a patch to build man and updated > control. They put doc/*.rst in examples and I put it in doc. > I also moved the new example config to `/etc/biboumi/biboumi.cfg` > since most packages install example config directly in their final > location in `/etc`. If "sample" config files are working out of the box then good - otherwise not. > 3. I updated copyright hints. Only update copyright_hints if you update copyright file as needed - otherwise better that you do *not* update copyright_hints: The hints file being out of sync is a way to recognize that copyright file is pending a closer examination. > 4. My release is marked NMU. Now that you joined the team maintaining the package, it is not an NMU. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#974011: xmille: Incorrect license/copyright for xmille
On Mon, Dec 07, 2020 at 09:12:23AM -0800, Keith Packard wrote: > Adrian Bunk writes: > > > > Keith, do you remember the copyright history of this code? > > I may have copied the underlying mille sources *before* copyrights were > added to each file; I started work on the X10 version of xmille around > 1985 or 1986. I guess I could have mistakenly removed them? Thanks for > discovering this error; I can fix these "upstream" and publish a new > version? I am just a user who would like to see this package also in bullseye. A new upstream version would be good, but it is not obvious to me whether you or Steve M. Robbins or anyone else is considered upstream or should become upstream (again). > -keith cu Adrian
Bug#957037: biboumi: ftbfs with GCC-10
Quoting Michel Le Bihan (2020-12-20 12:06:44) > It took me some time to understand how source of this package is > imported in the Salsa repo, I didn't look (still too busy elsewhere, please wait for Vadudev), just wanted to share what I have begun adding to packages that I maintain: https://salsa.debian.org/pkg-voip-team/baresip/-/commit/fee2f7f Would such usage comment have been a help in your struggle, if it had been in the biboumi package (and you had stumbled upon it, obviously)? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#977773: ITP: kodi-inputstream-ffmpegdirect -- FFmpegDirect inputstream binary addon for Kodi
Package: wnpp Severity: wishlist Owner: Vasyl Gello X-Debbugs-Cc: debian-de...@lists.debian.org, mat...@debian.org, rbal...@debian.org * Package name: kodi-inputstream-ffmpegdirect Version : 1.18.2 Upstream Author : Ross Nicholson * URL : https://github.com/xbmc/inputstream.ffmpegdirect * License : GPL-2+ Programming Lang: C++ Description : FFmpegDirect inputstream binary addon for Kodi This package is FFmpegDirect inputstream addon for Kodi. t Supports streams opened by FFmpeg's libavformat or Kodi's cURL such as plain TS, HLS and DASH (non-DRM) as well as many others. There is support for Archive/Catchup services where there is a replay window and can timeshift across that span. It also provides timeshift for live streams where rewind/pause and fast-forward would not have been available.
Bug#957037: biboumi: ftbfs with GCC-10
A quick summary of the differences between both repos: 1. Source is imported differently. I tried to import source the same way it was done previously. 2. Aluaces package might be missing man pages. Upstream is now using Sphinx instead of Pandoc. I added a patch to build man and updated control. They put doc/*.rst in examples and I put it in doc. I also moved the new example config to `/etc/biboumi/biboumi.cfg` since most packages install example config directly in their final location in `/etc`. 3. I updated copyright hints. 4. My release is marked NMU. Michel Le Bihan Le dimanche 20 décembre 2020 à 15:30 +0100, Jonas Smedegaard a écrit : > Quoting Vasudev Kamath (2020-12-15 09:35:35) > > > > Hi Alberto, > > > > > I have checked that current upstream (9.0) builds flawlessly, and > > > made my release available at > > > https://salsa.debian.org/aluaces-guest/biboumi . > > > > That is great. > > > > > Can I be sponsored so we can upload to at least experimental? > > > > Sure, please raise a merge request against biboumi and I will try > > to > > review your work and sponsor the upload for you. I would be happy > > if > > you can join us in maintaining biboumi. Both me and Jonas are bit > > busy > > and not getting enough time for maintaining biboumi properly. > > You are following along on this bugreport, right? > > I think it would be helpful if you could give a rough estimate on > when > you expect to find time to review the package update. > > I don't mean to rush it, just suggest to be transparent about the > delay > - I can imagine that Alberto and Michel must be excited to see > progress > on their contributions. > > I must admit that I am a bit confused - seems we now have two > bugfixes > for this issue - first from Alberto and later from Michel who also > wants > to join as co-maintainer - hope you can resolve that, Vasudev :-) > > > - Jonas >
Bug#975591: update-rc.d disable
>> The only way supported in update-rc.d to disable a service is >> update-rc.d disable > > … but not this. > > “update-rc.d disable” does *NOT* disable a service. Instead, it > sets it to “stopped in all runlevels”, which is evidently *not* > the same. > > I don’t care if “update-rc.d disable” gets changed or a new API > gets added, but this has to be fixed. > > There *absolutely* HAS to be some way to disable an init script > completely *without* insserv automatically re-enabling it on the > next package upgrade/install. It depends what's meant by "disable". If it means "disable from starting at boot", then "update-rc.d disable" does what it's meant to do. If it means "disable from starting at all", then "update-rc.d disable" doesn't do what it's meant to do. Given that "update-rc.d disable" changes all of the rc?.d links to "K*", it means the former. There could be a new verb, "mask", whereby "update-rc.d mask" would prefix the rc?.d scripts with an "M" and # update-rc.d disable # service start # telinit 3 would ignore "/etc/rc3.d/M??daemon" and wouldn't stop "". It feels like a lot of work for an unusual corner case.
