Bug#568834: Bug#882872: First stab at functionality for copying files
On Fri, May 10, 2024 at 10:52:07AM -0400, Benj. Mako Hill wrote: > Greetings! > > > > Your patch looks good to me and works as promised, thanks! Before > > forwarding > > it to upstream, we need an appropriate update of vidir documentation. Are > > you > > interested in preparing that? (If not, I can do it.) > > Sorry I lost track of this. Are we still waiting on documentation? If > so, I'm happy to do this so that this can land. yes, it would be great to have it as complete as possible, before contacting upstream. But please be warned that upstream ardly accepts patches that introduce new features [1]. Kind reards, Nicolas [1]: https://joeyh.name/blog/entry/Volunteer_Responsibility_Amnesty_Day/ -- epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#1069811: python-asyncssh: Please disable cryptography warnings during import
Package: python3-asyncssh
Version: 2.10.1-2
Severity: minor
Dear Maintainer,
please backport upstream commit 40da3934ef7b041 ("Hide cryptography
37.0.0 deprecation warnings").
Importing asyncssh on a current trixie system results in warnings
$ python3 -c 'import asyncssh'
/usr/lib/python3/dist-packages/asyncssh/crypto/cipher.py:29:
CryptographyDeprecationWarning: Blowfish has been deprecated and will be
removed in a future release
from cryptography.hazmat.primitives.ciphers.algorithms import Blowfish,
CAST5
/usr/lib/python3/dist-packages/asyncssh/crypto/cipher.py:29:
CryptographyDeprecationWarning: CAST5 has been deprecated and will be removed
in a future release
from cryptography.hazmat.primitives.ciphers.algorithms import Blowfish,
CAST5
/usr/lib/python3/dist-packages/asyncssh/crypto/cipher.py:30:
CryptographyDeprecationWarning: SEED has been deprecated and will be removed in
a future release
from cryptography.hazmat.primitives.ciphers.algorithms import SEED,
TripleDES
Upstream has disabled the warnings in a newer version explicitly. Can you
please add/backport the patch to the Debian package?
For convenience I am going to prepare a merge-request on salsa.
Thanks and kind regards,
Nicolas
-- System Information:
Debian Release: trixie/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500,
'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.15-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to
C.UTF-8), LANGUAGE=C
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-asyncssh depends on:
ii python33.11.8-1
ii python3-cryptography 42.0.5-2
ii python3-typing-extensions 4.4.0-1
Versions of packages python3-asyncssh recommends:
ii python-asyncssh-doc 2.10.1-2
ii python3-bcrypt 3.2.2-1
python3-asyncssh suggests no packages.
-- no debconf information
Bug#1052606: python3-pyroute2: pyroute2.__version__ is "unknown"
Hi, I prepared a merge-request for fixing it (and adding a test to check against bug revival): https://salsa.debian.org/openstack-team/third-party/pyroute2/-/merge_requests/1 Might someone take a look at it? Shall I set someone specific as reviewer on the MR? Kind regards, Nicolas
Bug#1063991: RFS: pyroute2/0.7.7-2.1 [NMU] -- Python3 Netlink library - full package
oh, I'm sorry, I forgot to Cc the pyroute2 uploaders in the initial RFS mail. On Thu 15 Feb 2024 11:56:09 GMT, Nicolas Schier wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "pyroute2": > > * Package name : pyroute2 >Version : 0.7.7-2.1 >Upstream contact : Peter V. Saveliev > * URL : https://github.com/svinota/pyroute2 > * License : GPL-3+-and-Apache-2.0, BSD-2-clause, Expat, GPL-3+ > * Vcs : https://salsa.debian.org/openstack/third-party/pyroute2 >Section : python > > The source builds the following binary packages: > > python-pyroute2-doc - netlink and Linux network configuration library > (documentation) > python3-pyroute2 - Python3 Netlink library - full package > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/pyroute2/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/p/pyroute2/pyroute2_0.7.7-2.1.dsc > > Changes since the last upload: > > pyroute2 (0.7.7-2.1) unstable; urgency=medium > . >* Non-maintainer upload. >* Add test against unknown version >* Auto-gen pyroute2's version number during build (Closes: #1052606) > > Actually, pyroute2 is team-maintained (openstack), but its Vcs is > currently marked as private (cp. #1052605). > > Regards, > -- > Nicolas Schier -- Nicolas Schier epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#1063991: RFS: pyroute2/0.7.7-2.1 [NMU] -- Python3 Netlink library - full package
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pyroute2": * Package name : pyroute2 Version : 0.7.7-2.1 Upstream contact : Peter V. Saveliev * URL : https://github.com/svinota/pyroute2 * License : GPL-3+-and-Apache-2.0, BSD-2-clause, Expat, GPL-3+ * Vcs : https://salsa.debian.org/openstack/third-party/pyroute2 Section : python The source builds the following binary packages: python-pyroute2-doc - netlink and Linux network configuration library (documentation) python3-pyroute2 - Python3 Netlink library - full package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pyroute2/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/pyroute2/pyroute2_0.7.7-2.1.dsc Changes since the last upload: pyroute2 (0.7.7-2.1) unstable; urgency=medium . * Non-maintainer upload. * Add test against unknown version * Auto-gen pyroute2's version number during build (Closes: #1052606) Actually, pyroute2 is team-maintained (openstack), but its Vcs is currently marked as private (cp. #1052605). Regards, -- Nicolas Schier signature.asc Description: PGP signature
Bug#1060055: RFS: glab/1.36.0-1 -- commandline interface for gitlab instances
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "glab": * Package name : glab Version : 1.36.0-1 Upstream contact : [fill in name and email of upstream] * URL : https://gitlab.com/gitlab-org/cli * License : Expat, BSD-3-Clause * Vcs : https://salsa.debian.org/go-team/packages/glab/ Section : vcs The source builds the following binary packages: glab - commandline interface for gitlab instances To access further information about this package, please visit the following URL: https://mentors.debian.net/package/glab/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/glab/glab_1.36.0-1.dsc Changes since the last upload: glab (1.36.0-1) unstable; urgency=medium . * New upstream version 1.36.0 * debian/patches: Update groff-error workaround patch * debian/control: Update Build-Depends * glab-ci-delete.1: Prevent troff error (patch) glab requires a newer version of golang-github-xanzy-go-gitlab (>= 0.93, << 0.95), which is also uploaded to mentors and looking forward for review and sponsoring [1]. Regards, Nicolas Schier [1]: https://mentors.debian.net/package/golang-github-xanzy-go-gitlab/ signature.asc Description: PGP signature
Bug#1060054: RFS: golang-github-xanzy-go-gitlab/0.94.0-1 [Team] -- Simple and uniform GitLab API for Go
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "golang-github-xanzy-go-gitlab": * Package name : golang-github-xanzy-go-gitlab Version : 0.94.0-1 Upstream contact : Sander van Harmelen * URL : https://github.com/xanzy/go-gitlab * License : Apache-2.0 * Vcs : https://salsa.debian.org/go-team/packages/golang-github-xanzy-go-gitlab Section : golang The source builds the following binary packages: golang-github-xanzy-go-gitlab-dev - Simple and uniform GitLab API for Go To access further information about this package, please visit the following URL: https://mentors.debian.net/package/golang-github-xanzy-go-gitlab/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-xanzy-go-gitlab/golang-github-xanzy-go-gitlab_0.94.0-1.dsc Changes since the last upload: golang-github-xanzy-go-gitlab (0.94.0-1) unstable; urgency=medium . * Team upload. * New upstream version 0.94.0 * Update patch force_tests_32bit.patch salsa repo is updated (but UNRELEASED -> unstable change is missing). golang-github-xanzy-go-gitlab (>=0.93, <<0.95) is the last missing dependency for glab-1.36 (also uploaded to mentors and looking forward for review and sponsoring). Regards, -- Nicolas Schier signature.asc Description: PGP signature
Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects
On Sat 30 Dec 2023 13:32:44 GMT, Jérémy Lal wrote: > Hi, > > is there any advance on > https://salsa.debian.org/go-team/packages/golang-k8s-apimachinery.git > ? > > I could help with it. thanks. It seems to me that you took over already :) My latest version is at https://salsa.debian.org/nsc/golang-k8s-apimachinery/ but your latest push to the official salsa repo looks better. Since the successful ITP of golang-github-google-gnostic-models, only an updated version of golang-github-kubernetes-gengo should be missing. I had some build problem with it last week and paused working on it between the years. Please go on as far as you like, I will not be able to work on this before 2024-01-04. Kind regards, Nicolas signature.asc Description: PGP signature
Bug#1012720: RFS: golang-github-google-gnostic-models/0.6.8-1 [ITP] -- Protocol buffer models for gnostic
Hi Nilesh, On Thu, Dec 21, 2023 at 11:10:27PM +0530, Nilesh Patra wrote: > On Wed, Dec 20, 2023 at 08:35:38AM +0100, Nicolas Schier wrote: > > Hi, > > > > I've packaged golang-github-google-gnostic-models, and I need a sponsor > > to get it uploaded. The package is a requirement for > > golang-k8s-apimachinery > > (cp. #1012720). > > Few comments: > > * You do not need a separate hand-crafted .install files to install extra > things you need. > Please use DH_GOLANG_INSTALL_EXTRA in d/rules for that. > * The d/copyright should probably mention "Google LLC" instead of "Google > Inc." since that's > what is mentioned in all the source code files. > * Standards version can be updated to 4.6.2 > * README.md as docs can be dropped. In principle no-one would install a lib > package and read the > README. The lib packages in golang are mainly needed for target consumable > binary packages. > > LMK once you address them! thanks a lot for your review! I fixed all four points (and updated the debian/watch version) so lintian is now completely satisfied. The corresponding fixup commit is pushed to https://salsa.debian.org/go-team/packages/golang-github-google-gnostic-models.git and the prepared source package is uploaded to mentors: dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-google-gnostic-models/golang-github-google-gnostic-models_0.6.8-1.dsc Kind regards, Nicolas (TIL: I should always push 'UNRELEASED' to the git repos as long as the package is not completely reviewed and accepted.) signature.asc Description: PGP signature
Bug#1012720: golang-k8s-apimachinery: Please remove protected references from salsa repo
On Thu, Dec 21, 2023 at 11:01:23PM +0530 Nilesh Patra wrote: > On Wed, Dec 20, 2023 at 09:49:48AM +0100, Nicolas Schier wrote: > > On Wed, Dec 20, 2023 at 09:44:31AM +0100 Nicolas Schier wrote: > > ah, I forgot to mention that 'uscan' does choose the "correct" upstream > > version > > tag automatically: > > [...] > > > Can someone please remove the protected branch 'upstream' as well as the > > > upstream tag 'upstream/1.25.0_alpha0'? > > > > > > (Or remove the whole repo to allow re-creating it?) > > Do you still want the repo to be pruned or remove the upstream branch? yes, please. > > > [1]: > > > https://salsa.debian.org/go-team/packages/golang-k8s-apimachinery.git > > Best, > Nilesh signature.asc Description: PGP signature
Bug#1012720: golang-k8s-apimachinery: Please remove protected references from salsa repo
On Wed, Dec 20, 2023 at 09:44:31AM +0100 Nicolas Schier wrote: > Date: Wed, 20 Dec 2023 09:44:31 +0100 > From: Nicolas Schier > To: debian...@lists.debian.org > Cc: 1012...@bugs.debian.org, n.sch...@avm.de > Subject: golang-k8s-apimachinery: Please remove protected references from > salsa repo > Message-ID: > Organization: AVM GmbH > > Hi, > > while attempting to take-over ITP #1012720 for golang-k8s-apimachinery, I am > struggling with the current repository state at salsa [1]. The current state > was auto-generated by dh-make-golang but has (at least) these flaws: > > * upstream branch contains non-upstream commit, preventing fast-forward on > the upstream branch > > * dh-make-golang did not choose the correct upstream version tag: in [1] we > have 1.x but we need it to be 0.x. Upstream provides kind of dual-tags > for > both version schemes. ah, I forgot to mention that 'uscan' does choose the "correct" upstream version tag automatically: $ uscan --report-status uscan info: uscan (version 2.21.3+deb11u1) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in . uscan info: package="golang-k8s-apimachinery" version="0.30.0~alpha0-1" (as seen in debian/changelog) uscan info: package="golang-k8s-apimachinery" version="0.30.0~alpha0" (no epoch/revision) uscan info: ./debian/changelog sets package="golang-k8s-apimachinery" version="0.30.0~alpha0" uscan info: Process watch file at: debian/watch package = golang-k8s-apimachinery version = 0.30.0~alpha0 pkg_dir = . uscan info: opts: filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%golang-k8s-apimachinery-$1.tar.gz%,uversionmangle=s/(\d)[_\.\-\+]?(RC|rc|pre|dev|beta|alpha)[.]?(\d*)$/$1~$2$3/ uscan info: line: https://github.com/kubernetes/apimachinery/tags .*/v?(\d\S*)\.tar\.gz debian uscan info: Parsing filenamemangle=s%(?:.*?)?v?(\d[\d.]*)\.tar\.gz%golang-k8s-apimachinery-$1.tar.gz% uscan info: Parsing uversionmangle=s/(\d)[_\.\-\+]?(RC|rc|pre|dev|beta|alpha)[.]?(\d*)$/$1~$2$3/ uscan info: line: https://github.com/kubernetes/apimachinery/tags .*/v?(\d\S*)\.tar\.gz debian uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.30.0~alpha0 uscan info: Last orig.tar.* tarball version (dversionmangled): 0.30.0~alpha0 uscan info: Requesting URL: https://github.com/kubernetes/apimachinery/tags uscan info: Matching pattern: (?:(?:https://github.com)?\/kubernetes\/apimachinery\/)?.*/v?(\d\S*)\.tar\.gz uscan info: Found the following matching hrefs on the web page (newest first): https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.30.0-alpha.0.tar.gz (0.30.0~alpha0) index=0.30.0~alpha0-1 https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.30.0-alpha.0.tar.gz (0.30.0~alpha0) index=0.30.0~alpha0-1 https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.29.0.tar.gz (0.29.0) index=0.29.0-1 https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.29.0.tar.gz (0.29.0) index=0.29.0-1 https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.29.0-rc.2.tar.gz (0.29.0~rc2) index=0.29.0~rc2-1 https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.29.0-rc.2.tar.gz (0.29.0~rc2) index=0.29.0~rc2-1 https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.29.0-rc.1.tar.gz (0.29.0~rc1) index=0.29.0~rc1-1 https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.29.0-rc.1.tar.gz (0.29.0~rc1) index=0.29.0~rc1-1 https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.29.0-rc.0.tar.gz (0.29.0~rc0) index=0.29.0~rc0-1 https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.29.0-rc.0.tar.gz (0.29.0~rc0) index=0.29.0~rc0-1 uscan info: Looking at $base = https://github.com/kubernetes/apimachinery/tags with $filepattern = .*/v?(\d\S*)\.tar\.gz found $newfile = https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.30.0-alpha.0.tar.gz $newversion = 0.30.0~alpha0 $lastversion = 0.30.0~alpha0 uscan info: Matching target for downloadurlmangle: https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.30.0-alpha.0.tar.gz uscan info: Upstream URL(+tag) to download is identified as https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.30.0-alpha.0.tar.gz uscan info: Matching target for filenamemangle: https://github.com/kubernetes/apimachinery/archive/refs/tags/v0.30.0-alpha.0.tar.gz uscan info: Filename (filenamemangled) for downloaded file: golang-k8s-apimachinery-0.tar.gz uscan info: Newest version of golang-k8s-apimachinery on remote site is 0.30.0~alpha0, local version is 0.
Bug#1012720: golang-k8s-apimachinery: Please remove protected references from salsa repo
Hi, while attempting to take-over ITP #1012720 for golang-k8s-apimachinery, I am struggling with the current repository state at salsa [1]. The current state was auto-generated by dh-make-golang but has (at least) these flaws: * upstream branch contains non-upstream commit, preventing fast-forward on the upstream branch * dh-make-golang did not choose the correct upstream version tag: in [1] we have 1.x but we need it to be 0.x. Upstream provides kind of dual-tags for both version schemes. Can someone please remove the protected branch 'upstream' as well as the upstream tag 'upstream/1.25.0_alpha0'? (Or remove the whole repo to allow re-creating it?) Kind regards, Nicolas [1]: https://salsa.debian.org/go-team/packages/golang-k8s-apimachinery.git signature.asc Description: PGP signature
Bug#1012720: RFS: golang-github-google-gnostic-models/0.6.8-1 [ITP] -- Protocol buffer models for gnostic
Hi, I've packaged golang-github-google-gnostic-models, and I need a sponsor to get it uploaded. The package is a requirement for golang-k8s-apimachinery (cp. #1012720). Salsa: https://salsa.debian.org/go-team/packages/golang-github-google-gnostic-models.git Changelog: golang-github-google-gnostic-models (0.6.8-1) unstable; urgency=medium . * Initial release (Closes: #1053000) Mentors: https://mentors.debian.net/package/golang-github-google-gnostic-models/ dget -x https://mentors.debian.net/debian/pool/main/g/golang-github-google-gnostic-models/golang-github-google-gnostic-models_0.6.8-1.dsc The package builds with sbuild and passes lintian. Kind regards, Nicolas signature.asc Description: PGP signature
Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects
Control: owner -1 ! Hi Bartek, On Mon, Dec 18, 2023 at 02:02:55PM +0100 Bartosz Fenski wrote: > So is someone working on that ITP currently? > Seems it's one of many missing dependencies for k9s tool which I'm working > on. yes, the actual packaging of golang-k8s-apimachinery does not seem to make problems (I am going to push my current today or tomorrow for that can have a look at it). But there are still unresolved prerequirement, e.g.: golang-github-google-gnostic-models (#1053000) and a newer version of golang-k8s-kube-openapi-dev Currently, I am fighting against the latter as version 0.0~git20231113.778a556-1 does not compile (for me). But my time resources are limited. If you want to help, please don't hesitate to support or take-over whatever you want. As of today I'd guess, I would need until mid-January to get all of this done, if all goes well. (Actually, I just wanted to update the glab package...) Kind regards, Nicolas
Bug#1053000: ITP: golang-github-google-gnostic-models -- Protobuf models and libraries for gnostic-supported API formats
Hi Arthur, are you still working on packaging golang-github-google-gnostic-models? For packaging the newer versions of glab, we need several new golang packages and one of them is golang-github-google-gnostic-models. For my local tests, I failed using the default 'dh-make-golang' but had to compose a manually adjusted debian/ folder. Might you want to review or test my current state? https://salsa.debian.org/nsc/golang-github-google-gnostic-models If you are out of time (or whatever else): may I hijack your ITP? Kind regards, Nicolas signature.asc Description: PGP signature
Bug#1012720: ITP: golang-k8s-apimachinery -- Handle Kubernetes-like API objects
Hi Domenico, do you still plan to finish the packaging of golang-k8s-apimachinery shortly? In order to update glab package to v1.35.0 the package is needed; may we offer help or would it be ok for you if someone else takes-over your ITP? Kind regards, Nicolas On Sun, Jun 12, 2022 at 09:51:03PM +0200, Domenico Andreoli wrote: > Package: wnpp > Severity: wishlist > Owner: Domenico Andreoli > > * Package name: golang-k8s-apimachinery > Version : 1.25.0~alpha0-1 > Upstream Author : Kubernetes > * URL : https://github.com/kubernetes/apimachinery > * License : Apache-2.0 > Programming Lang: Go > Description : Handle Kubernetes-like API objects. > > This library is a shared dependency for servers and clients to work with > Kubernetes API infrastructure without direct type dependencies. Its > first consumers are k8s.io/kubernetes, k8s.io/client-go, and > k8s.io/apiserver. signature.asc Description: PGP signature
Bug#848578: [PATCH 1/2] ts: Enable perl locale input/output conversion (Closes: #848578)
Enable perl locale support to ensure that I/O is treated with the
encoding indicated by the locale, be it UTF-8 or something else.
Link: https://perldoc.perl.org/perllocale#Unicode-and-UTF-8
Patch-by: Dr. Thomas Orgis
Signed-off-by: Nicolas Schier
---
ts | 1 +
1 file changed, 1 insertion(+)
diff --git a/ts b/ts
index af23cf7..71b0fbc 100755
--- a/ts
+++ b/ts
@@ -53,6 +53,7 @@ use warnings;
use strict;
use POSIX q{strftime};
no warnings 'utf8';
+use open q{:locale};
$|=1;
--
2.42.0
Bug#1041291: [PATCH 2/2] ts: Do not accept extra args and always read from stdin (Closes: #1041291)
Stop accepting more args than the optional format string and explicitly
read only from stdin.
In the linked Debian bug report, a detailed description about irregular
behaviour of ts with special extra args is available.
Reported-by: Zefram
Co-developed-by: Zefram
Link: https://bugs.debian.org/1041291#5
Signed-off-by: Nicolas Schier
---
ts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ts b/ts
index 71b0fbc..982c164 100755
--- a/ts
+++ b/ts
@@ -67,7 +67,7 @@ GetOptions(
"i" => \$inc,
"s" => \$sincestart,
"m" => \$mono
-) || die "usage: ts [-r] [-i | -s] [-m] [format]\n";
+) && @ARGV <= 1 or die "usage: ts [-r] [-i | -s] [-m] [format]\n";
if ($rel) {
eval q{
@@ -111,7 +111,7 @@ else {
}
-while (<>) {
+while () {
if (! $rel) {
if ($hires) {
my $f=$format;
--
2.42.0
Bug#1052606: python3-pyroute2: pyroute2.__version__ is "unknown"
Package: python3-pyroute2 Version: 0.7.7-1 Severity: minor Dear Maintainer, python3 -c 'from pyroute2 import __version__; print(__version)' returns "unknown" instead of the pyroute2 version number. We need to determine the actual pyroute2 version to determine how to handle some aspects of its API. When I add diff --git a/debian/rules b/debian/rules index dd0e300..f94599c 100755 --- a/debian/rules +++ b/debian/rules @@ -13,6 +13,7 @@ override_dh_auto_clean: rm -rf build .stestr *.egg-info .pybuild find . -iname '*.pyc' -delete for i in $$(find . -type d -iname __pycache__) ; do rm -rf $$i ; done + rm -f pyroute2/config/version.py override_dh_auto_test: ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS))) @@ -25,6 +26,7 @@ endif override_dh_auto_build: echo $$OSLO_PACKAGE_VERSION > VERSION + $(MAKE) VERSION dh_auto_build override_dh_installchangelogs: pyroute2.__version__ contains the expected version number. Thanks for packaging pyroute2!! Kind regards, Nicolas -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-pyroute2 depends on: ii python3 [python3-supported-min] 3.11.4-5+b1 ii python3-psutil 5.9.4-1+b1 python3-pyroute2 recommends no packages. python3-pyroute2 suggests no packages. -- no debconf information
Bug#1052605: pyroute2: Vcs-Git refers to non-public repository
Source: pyroute2 Severity: wishlist Dear Maintainer, can you please consider to open the pyroute2 Debian git repository for public read-only access? The pyroute2 source package's Vcs-Git URL refers to stable (0.7.2-2): https://salsa.debian.org/third-party/pyroute2.git testing, unstable (0.7.3-4), experimental (0.7.7-1): https://salsa.debian.org/openstack/third-party/pyroute2.git But both repositories are not publicly accessible. (Actually neither the 'third-party' nor 'openstack' projects are visible for unauthorized access.) For collaboration it would be nice, if read-only access could be provided. Kind regards, Nicolas
Bug#981559: purple-rocketchat: NMU for new upstream version and introducing epoch
Dear Debian XMPP Maintainers, TL;DR: I'd like to help out updating purple-rocketchat and would appreciate your feedback on NMUing purple-rocketchat and introducing an epoch. While preparing what might become the base of a merge-request [1] for a new version of purple-rocketchat, I came across a problem with the versioning: 1. Previously, upstream used mercurial (bitbucket.org) for SCM w/o release tags. Thus, we had the '~hg%Y%m%d.%(hash)' part in previous Debian versions. A few years ago, upstream moved to git [2], so we should change '~hg' to '~git', but orthographically '~git' is considered to be older than '~hg'. 2. Even though there was no single release tag 0.1, we have used '0.1' as base upstream version number. Using a debian/watch file with uscan's git-HEAD scheme (e.g. as in [3]), results in auto-generated base version number '0.0', thus, these are always considered to be older than the previous '0.1' versions. So, with updating to the new upstream repo and using uscan watch file, we get this version change: from 0.1~hg20200403.800ef89-1 (as currently in stable,testing,unstable) to 0.0~git20220925.a8a887c-X (cp. [1]) AFAIK, this requires the introduction of an epoch, after consulting debian-devel. Do you agree, or do you have other opinions? Is it ok, if I try to update purple-rocketchat via NMU (sponsoring needed)? Kind regards, Nicolas [1]: https://salsa.debian.org/nsc/purple-rocketchat [2]: https://github.com/EionRobb/purple-rocketchat [3]: https://salsa.debian.org/nsc/purple-rocketchat/-/blob/debian/latest/debian/watch
Bug#385069: moreutils: Please add "dirempty" command
Tags: wontfix I consider re-posting of out-dated URLs is spam. Joey (upstream author) made his point already years ago, I think it's time to close this bug. signature.asc Description: PGP signature
Bug#1041291: ts with extra args behaves badly
On Mon 17 Jul 2023 01:10:17 GMT, Zefram wrote:
> Package: moreutils
> Version: 0.65-1
> Severity: normal
>
> ts(1) is documented to take a `format' argument on its command line,
> and no other non-option arguments. In fact, if given more arguments then
> it won't complain about a usage error, but then won't read its standard
> input, and will do more or less bizarre things with the extra arguments.
> On the mild end of the spectrum, sometimes it will use an argument as
> a filename, and take input from that file (which is pointless for a
> regular file):
>
> $ echo a > t0
> $ ts %F t0
> 2023-07-17 a
> $
>
> It gets weirder if an argument contains certain characters that are not
> usually used in filenames:
>
> $ ls -l
> total 4
> -rw-rw-r-- 1 zefram zefram 2 Jul 17 00:45 t0
> $ ts %F '>t1'
> $ ls -l
> total 4
> -rw-rw-r-- 1 zefram zefram 2 Jul 17 00:45 t0
> -rw-rw-r-- 1 zefram zefram 0 Jul 17 00:49 t1
> $ echo c > 't2 '
> $ ts %F 't2 '
> Can't open t2 : No such file or directory at /usr/bin/ts line 113.
> $ ts %F '|echo wibble'
> wibble
> $
>
> The details of this behaviour arise because, after failing to check
> for extraneous arguments, the program uses the <> Perl operator,
> which magically implements a variety of interpretations of command line
> arguments. The range of behaviour includes writing to arbitrary files
> and running arbitrary commands, which are very undesirable behaviours
> for ts(1). However, the seriousness of the problem is limited by the
> fact that this behaviour only arises if the program is invoked with
> extraneous arguments, contrary to its documentation.
>
> It might be considered desirable for ts(1) to read input from files
> named on the command line. (Though pointless for regular files.)
> If that is the case then it would not be wrong for the program to
> accept the additional arguments. But in that case it would still be
> wrong for it to use the <> Perl operator, which is not suitable for the
> implementation of a read-from-list-of-files kind of command, because
> of the variety of behaviour described above. It would also make this
> a more serious bug, because the dangerous behaviour such as writing to
> files could be invoked by attempts to read from files. It would also be
> a documentation bug that the possibility of naming files on the command
> line was not mentioned in the man page or usage message.
thanks for the very detailed bug description and reasoning, I really
appreciate it! As the documentation does not mention anything about
reading input from files, I think, reading STDIN explicitly is probably
the best.
Would this patch be sufficiently safe?
diff --git a/ts b/ts
index af23cf7..b39a395 100755
--- a/ts
+++ b/ts
@@ -112,3 +112,3 @@ else {
-while (<>) {
+while () {
if (! $rel) {
If it is, I would like to include your reasoning into a patch for
upstream, ok?
Kind regards,
Nicolas
--
epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f
-- frykten for herren er opphav til kunnskap --
signature.asc
Description: PGP signature
Bug#969482: ITP: glab -- An open-source GitLab command line tool
FTR: Unit193 uploaded an initial version yesterday, it is pending in the new queue. Kind regards, Nicolas
Bug#568834: Bug#882872: First stab at functionality for copying files
On Wed 14 Jun 2023 at 09:30:12PM +0200 Nicolas Schier wrote: > Hi Mako, > > On Fri 09 Jun 2023 12:01:52 GMT, Benj. Mako Hill wrote: > > Greetings! > > > > This is just a followup to say that I've been using the patch for > > about two years now and have not noticed any trouble. I use the > > copying files functionality in vidir nearly every day! > > thanks for your patch and bringing the missing feature back to my mind. > I _will_ give you feedback on it within the next two weeks. Your patch looks good to me and works as promised, thanks! Before forwarding it to upstream, we need an appropriate update of vidir documentation. Are you interested in preparing that? (If not, I can do it.) Kind regards, Nicolas -- epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap --
Bug#882872: First stab at functionality for copying files
Hi Mako, On Fri 09 Jun 2023 12:01:52 GMT, Benj. Mako Hill wrote: > Greetings! > > This is just a followup to say that I've been using the patch for > about two years now and have not noticed any trouble. I use the > copying files functionality in vidir nearly every day! thanks for your patch and bringing the missing feature back to my mind. I _will_ give you feedback on it within the next two weeks. > If someone wants to take a more active role in maintaince and needs a > hand, let me know. I am quite irresolutely how to go on with moreutils in Debian: upstream is responsive but it usually takes months until Joey finds time to handle moreutils patches (and that reduces the fun to try uptreaming patches on my side), and Joey is waiting for someone to adopt the upstream maintainence. In general, I'd like to have Debian's moreutils package strongly aligned to the upstream version, but my doubts raise whether this is really a sensible policy. Do you have some thoughts about that? Kind regards, Nicolas signature.asc Description: PGP signature
Bug#969482: Update golang-github-xanzy-go-gitlab from 0.73 to 0.85
Dear go-packaging-team, for packaging the 'glab' CLI tool [1] we need golang-github-xanzy-go-gitlab >= 0.83. For my local packaging test I prepared an update to 0.85 and created corresponding merge-requests: * Branch upstream: Import new upstream version 0.85.0 https://salsa.debian.org/go-team/packages/golang-github-xanzy-go-gitlab/-/merge_requests/3 * Branch debian/sid: Update to new upstream version 0.85.0 https://salsa.debian.org/go-team/packages/golang-github-xanzy-go-gitlab/-/merge_requests/4 (As the actual update was as easy as `gbp import-orig --uscan && dch ...` a review might take more effort than redoing it.) Can I help somehow to get the package update with least effort for you? (E.g. NMU-Upload to debian-mentors? But I have _no_ programming experience with 'go'.) Thanks for all your steady work! Kind regards, Nicolas [1]: ITP: glab -- An open-source GitLab command line tool (#969482) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969482 -- epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#969482: ITP: glab -- An open-source GitLab command line tool
On Tue, Jan 24, 2023 at 12:23:19PM -0500 Antoine Beaupré wrote: > On 2020-09-03 16:21:32, TODO wrote: > > Package: wnpp > > Severity: wishlist > > Owner: TODO > > > > * Package name: glab > > Version : 1.10.0-1 > > Upstream Author : Clement Sam > > * URL : https://github.com/profclems/glab > > Hi Clement Sam! > > You filed this ITP (Intent To Package) back in 2020, do you still intend > on publishing your work in Debian? > > I see there was a packaging discussion here: > > https://gitlab.com/gitlab-org/cli/-/issues/205 > > ... but it was closed in favor of using makedeb.org, which we typically > do not favor in debian.org itself. :) > > As things stand now, you are the owner of this bug and others might be > respectfully waiting for you to complete the work instead of jumping in > and bringing glab in Debian per se. If you do not intend to continue > this work, let us know and someone else might step up. :) > [...] > > so we don't actually know if we need to package more deps here... > > Anyways, let us know where things are so we can move forward > here. Thanks! While trying to prepackage glab (v1.30) at work (dh-make-golang + [1]), I had to update golang-github-xanzy-go-gitlab-dev from its current version in testing/unstable (0.73.1-2) to 0.84.0. Other dependency package updates were not necessary. Antoine, does it makes sense that I step in and prepare a non-maintainer upload (sponsoring would be needed), or does the golang-team take care of that? Iff Clement Sam is no more responding: is there a gentle, official way that someone may take over the ITP? Kind regards, Nicolas
Bug#848578: [PATCH] ts: Enable UTF-8 binary mode for input and output processing (Closes: #848578)
On Thu 02 Mar 2023 10:39:45 GMT, Dr. Thomas Orgis wrote:
> I also sent this already directly to Joey, but later found this bug
> report. My take is this:
>
> --- /usr/bin/ts 2019-02-20 22:03:31.0 +0100
> +++ ./ts 2023-03-01 21:06:41.177886024 +0100
> @@ -53,6 +53,7 @@
> use strict;
> use POSIX q{strftime};
> no warnings 'utf8';
> +use open q{:locale};
>
> $|=1;
>
>
> This should ensure that the I/O is treated with the encoding indicated
> by the locale, be it UTF-8 or something else.
Thanks a lot! I hope, Joey will pick this up, soon.
Kind regards,
Nicolas
--
epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f
-- frykten for herren er opphav til kunnskap --
signature.asc
Description: PGP signature
Bug#1030104: b4: Please add debian/watch file
Package: b4 Version: 0.9.0-1 Severity: wishlist Dear Héctor, can you please add a debian/watch file to allow use of uscan and friends? I am attaching a patch that works for me and adds debian/watch and upstream author's gpg key. Thanks and kind regards, Nicolas -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/6 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages b4 depends on: ii python33.11.1-1 ii python3-dkim 1.0.5-2 ii python3-dnspython 2.2.1-2 ii python3-patatt 0.6.2-1 ii python3-requests 2.28.1+dfsg-1 b4 recommends no packages. b4 suggests no packages. -- no debconf information diff --git a/debian/upstream/signing-key.asc b/debian/upstream/signing-key.asc new file mode 100644 index 000..d49e509 --- /dev/null +++ b/debian/upstream/signing-key.asc @@ -0,0 +1,289 @@ +-BEGIN PGP PUBLIC KEY BLOCK- + +mQINBE64XOsBEAC2CVgfiUwDHSqYPFtWxAEwHMoVDRQL5+Oz5NrvJsGRusoGMi4v +wnToaNgD4ETPaaXHUAJdyy19BY+TCIZxDd+LR1zmMfzNxgePFjIZ6x4XIUMMyH6u +jDnDkKJW/RBv262P0CRM9UXHUqyS6z3ijHowReo1FcYOp/isN9piPrKzTNLNoHM2 +re1V5kI8p8rwTuuQD/0xMPs4eqMBlIr7/1E2ePVryHYs5pPGkHIKbC9BN83iV2La +YhDXqn3E9XhA1G5+nPYFNRrTSEcykoRwDhCuEA51wu2+jj0L09OO4MbzBkSZKASe +LndRVyI6t0x8ovYXcb7A4u0jiH7gVjcNcJ5NfwFUqaOQOxSluahhI497SJULbKIP +Pu3cv4/O/3Urn3fQsa689xbbUkSPhfGKG73FYnAuC5vxzBSkOB7iFRBhA37NfN5V +OhCbWfXipdBDxSYunac6FjArBG1tfaF8BflkQmKLiBuiH5zwkgju5kOzrko5iISL +0CM4zUTAUWbg1QnPvRjPzoT6tlsCOBY6jZK921Ft+uVjHg424/CVZ9A+kA33+Dfq +otnzNK4CLNnLT4OEPM6ETxLnA6PyldUjSTUekZ75/Rp+aJHt5v7Q2mqOcB/5ZA6A ++vaBgZAMfCZbU+D1FeXD8NNEQcRDWdqe0S/ZgXdU+IyqyQ3Ie4vqGGYpkQARAQAB +tDZLb25zdGFudGluIFJ5YWJpdHNldiAoRmVkb3JhKSA8aWNvbkBmZWRvcmFwcm9q +ZWN0Lm9yZz6JAk8EEwECACIFAk7NMp8CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4B +AheAACEJEOY+3KkyndB+FiEE3g5m4y8f3QkCZmuW5j7cqTKd0H4SwQ//QME+IJpw +94FjqBZVzrsG3kpduwmSidKvq2L6mVceGp7iYbtDSoGXu52DHjNilQVV65I8natx +DM6ZUWktZ0OSSk9WpIRKrAEAD1uBV9gNi2BI3CfeVG5POhoknvjaqmf5Y3CDcrdZ +jdd3kaCz7GktK0sUjXwzPtwOE4HmQz0caDHIPEDyMazP7m8aUOnwYeUmsbyMHyf8 +tqbOO9A2U5ljJYIXsb5EBf3Kgvf10dnPflKpwNT090jhvbf2KEw97TXFCegKMrG+ +EhwBDHBTct6dHU0O6P8E8PuTqD848pjWxauWT6UwtHyYhhGVZiy0w2z7O0iy4iC2 +Nt57AzwfnwIX5bXbgiJvivTtgDKfy6a2svcqKMiUxTKY6a5CtcYAuJV2WrIfy7uS +vggeu1LQCb2/kQ3Idaz8TEddPsS+AuxGvRP5ooMk6BWDQR1HvBP4WBJO/RCVB8Yv +6nZFNOtsWhu2Wv2a5wHAQuic81aKM6ANNr/Aj2ia7bs1WOOxI/7MuGGNjvdJI4Ux +PtzAfKZGAYyjx/EV2QkHjEJ9wTcpPvJpX5pp9g0iTFK09gVO9BltToG8cEBM5uD9 +li1PJLUzh8k6R8kZhSoFXCEH4HwiOj/aKh/Aaidc23A71noG33AEvFaKF5BjUrL9 +QhclwyxgL9aAiFjH4OWbwTFqjJz0w90KUti0LktvbnN0YW50aW4gUnlhYml0c2V2 +IDxoYmljQHBhcmFub2lkYmVhdmVycy5jYT6JAk4EEwEIADgWIQTeDmbjLx/dCQJm +a5bmPtypMp3QfgUCWunVAAIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRDm +PtypMp3QfsNSEACSFwiOYiUkr19AD9ybk8FNSDlwVzK8DpWpbaVhQrNzHerJYeIA ++m67k2GIWzo0ZibjCgz88aO1mkN67tvTNB37UMUCoYYuwwH4v+yqdxd97eXdpqaI +pivBnOA+ZFxhUJihrrjY7O4azqJfBlHbPESIEKaZWfuBiLTS18zqbdzuImJCEEK1 +aanXk98UL+Dho5aA86BJN7JDIE8l1siOsGtrKrKbQOqHC3cwpheT0lO1InZv02AT +Pk53iT7L2DgaSsZ4Fg05oDF8VFiJJFPln9pzXnE51iHH6tXtu/Os4K0ngQg98sYX +8tQFGloMCX+L+KIG4/LwUNhBiU/Yvp0JzZ1uEVUY2P7qLgnnaxa9guPaG7lve84u +pTsoXyTzrEQw+TgxJ+ATOUfU6ze7igjHD22/LW4N2Y2jF7+8+igqwHe4S0YFE6Kz +vLhBVSCGPU1HPdDV2Cq1nOv6K/lvzU36KyKMeAOagGZFXEAUiwu7fur/u8GM+A0T +96C5RT6W0+/oI61Orm9Y/vzAMPFWpqJ39PtsZz/D/SPJPKlPOlIq98wKL2dy0Y3c +Vb9ARC/MnWCv2HvQlFQ5rcnfOFeyItv8l2ZazmMct0M6AVR/kI4Q0IbkJGyFkYgv +S04wm4T6+xyWwGTVBpzg3eJqZ/yq7wzl0r1leUUaT/5Rild2rBTKx+LKl7QmS29u +c3RhbnRpbiBSeWFiaXRzZXYgPGljb25AbXJpY29uLmNvbT6JAk4EEwEIADgWIQTe +DmbjLx/dCQJma5bmPtypMp3QfgUCWunU2gIbAwULCQgHAgYVCgkICwIEFgIDAQIe +AQIXgAAKCRDmPtypMp3QfsFwEACUcFAleVyqsMuCFC61n/mOeapk6TsNCop9sfP6 +4a2bhYM31DRkZHco8xrUB0dZ6OHozzIzIK/v0SzurS3n7gHKfuktbSTvAbJMPubM +8iXJyaKL/+DGHt6qJynD3tHtSSR4c9aFrlnrn3Gefa3eQrgdNcieQcMCXOdePDHZ +yWKQ4gfe6zxb63SbMv3Ms25hcmOf+HA1S8fM9bKrHEvebm23+2WOrQR/d5OPRXnW +Dz9yz+++eWQfdG+FUfxUz7ulOG+C8jxzGjrAWgsvrAq48625GUrvuU2u5BJD2P1I +WvEpQtFm3XnWvqP0hy5oT2i4hHvPxumY6XuZsBvEQygGajj94xZS5Gn0kqGV5XV/ +I1Z4kY00Ig0KHEG+LL1O+eu2ntfaqS2CZSlwbnfluqdgNNKs6lYsolvpqSCAXVVV +27pkWo/To3E2RFvU7v33468KijBEHAjWlacmC6Ixs7PRmHiNGWK5Ewn0suzmPBy8 +lFtKBhT0JUyK12vkfrSFHs485TDk3uDQiyYh8lMkSuQIlBN9wfFMyPZTlfInNc7A +umczplkl6I5qz5rfaxz1uWg9zI7deYAEoOJnaJG74stAXPx+iih2PbOpviXcr/AS +L33Xg7A6ZF9Q3mmHPLym4q472VOaNj0AjLIUZC76oQdEXJz7Is3A/YSdgEIomBvr +CGU3R7Q1S29uc3RhbnRpbiBSeWFiaXRzZXYgPGtvbnN0YW50aW5AbGludXhmb3Vu +ZGF0aW9uLm9yZz6JAlIEEwECACUCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheA +BQJTjeH0AhkBACEJEOY+3KkyndB+FiEE3g5m4y8f3QkCZmuW5j7cqTKd0H50bA//
Bug#848578: [PATCH] ts: Enable UTF-8 binary mode for input and output processing (Closes: #848578)
Dear Joey,
On Fri 07 Oct 2022 20:14:29 GMT, Nicolas Schier wrote:
> Enable UTF-8 compatible processing of input and output to correctly
> output e.g.
> timestamps containing non-latin letters (cp. [1]).
>
> [1]: https://bugs.debian.org/848578
>
> Signed-off-by: Nicolas Schier
> ---
> ts | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/ts b/ts
> index af23cf7..fbd5b1a 100755
> --- a/ts
> +++ b/ts
> @@ -54,6 +54,11 @@ use strict;
> use POSIX q{strftime};
> no warnings 'utf8';
>
> +# Ensure that text read or printed are converted from/to UTF-8.
> +binmode STDIN, ':utf8';
> +binmode STDOUT, ':utf8';
> +binmode STDERR, ':utf8';
> +
> $|=1;
>
> my $rel=0;
> --
> 2.30.2
Are there chances that you still apply such patches? After your call
for adoption: Is there some new maintainer for moreutils already
available?
Kind regards,
Nicolas
--
epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f
-- frykten for herren er opphav til kunnskap --
signature.asc
Description: PGP signature
Bug#848578: [PATCH] ts: Enable UTF-8 binary mode for input and output processing (Closes: #848578)
Enable UTF-8 compatible processing of input and output to correctly output e.g.
timestamps containing non-latin letters (cp. [1]).
[1]: https://bugs.debian.org/848578
Signed-off-by: Nicolas Schier
---
ts | 5 +
1 file changed, 5 insertions(+)
diff --git a/ts b/ts
index af23cf7..fbd5b1a 100755
--- a/ts
+++ b/ts
@@ -54,6 +54,11 @@ use strict;
use POSIX q{strftime};
no warnings 'utf8';
+# Ensure that text read or printed are converted from/to UTF-8.
+binmode STDIN, ':utf8';
+binmode STDOUT, ':utf8';
+binmode STDERR, ':utf8';
+
$|=1;
my $rel=0;
--
2.30.2
--
epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f
-- frykten for herren er opphav til kunnskap --
signature.asc
Description: PGP signature
Bug#1021307: irssi-plugin-rocketchat: Please add README.md to irssi-plugin-rocketchat
Package: irssi-plugin-rocketchat Version: 0.6.0-1 Severity: wishlist Dear Rhonda, can you please add README.md to the binary package? It was quite helpful for me for the initial irssi setup. Thanks and kind regards, Nicolas
Bug#1021306: irssi-plugin-rocketchat: Please add libwebsockets-evlib-glib (or comparable?) as dependency
Package: irssi-plugin-rocketchat Version: 0.6.0-1 Severity: normal Dear Rhonda, on my system, I had to install libwebsockets-evlib-glib; otherwise I saw only 11:30 LWS: 4.1.6-, loglevel 1031 11:30 11:30 NET CLI SRV H1 H2 WS IPV6-on 11:30 11:30 lws_create_context: unable to load evlib plugin evlib_glib 11:30 11:30 ::: Unable to connect server chat.avm.de port 443 lws init failed when attempting to connect to the configured rocketchat network. Installing libwebsockets-evlib-glib (4.1.6-3) from testing/unstable leads to messages like: 11:31 LWS: 4.1.6-, loglevel 1031 11:31 11:31 NET CLI SRV H1 H2 WS IPV6-on 11:31 11:31/usr/lib/aarch64-linux-gnu/libwebsockets-evlib_glib.so 11:31 11:31 Unhandled lws callback reason: 19 11:31 Unhandled lws callback reason: 58 11:31 Unhandled lws callback reason: 58 11:31 Unhandled lws callback reason: 58 11:31 Unhandled lws callback reason: 44 11:31 ::: Connection to chat.myrocketchat.domain established and usable rocketchat connection. Thanks for packaging irssi-plugin-rocketchat! Kind regards, Nicolas -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.17.0-rc2+ (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.UTF-8), LANGUAGE=C.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages irssi-plugin-rocketchat depends on: ii libc62.34-7 ii libglib2.0-0 2.72.3-1+b1 ii libjansson4 2.14-2 ii libwebsockets17 4.1.6-3 irssi-plugin-rocketchat recommends no packages. irssi-plugin-rocketchat suggests no packages. -- no debconf information
Bug#848578: Also running into this problem
Thanks for the details, finally I can reproduce this now. When adding
three unicode related lines into 'ts' it _seems_ to me to be fixed, but
my perl experience is quite degraded and I'd like to get some feedback
from volunteer testers before forwarding the patch to upstream.
Francois, might you be able to patch your ts with the attached patch
and re-check? As August has gone, I used
echo test | faketime "2022-08-01" ./ts
for testing with your specified locale settings.
Kind regards,
Nicolas
On Sat, 6 Aug 2022 10:37:22 -0700 Francois Marier wrote:
> I can also reproduce this problem with `ts` while `date` works fine:
>
> $ date | ts
> ao� 06 10:33:36 sam 06 aoû 2022 10:33:36 PDT
>
> $ date
> sam 06 aoû 2022 10:35:39 PDT
>
> $ echo test | ts
> ao� 06 10:36:04 test
>
> This is what my locale is set to:
>
> $ locale
> LANG=fr_CA.utf8
> LANGUAGE=
> LC_CTYPE="fr_CA.utf8"
> LC_NUMERIC="fr_CA.utf8"
> LC_TIME="fr_CA.utf8"
> LC_COLLATE="fr_CA.utf8"
> LC_MONETARY="fr_CA.utf8"
> LC_MESSAGES="fr_CA.utf8"
> LC_PAPER="fr_CA.utf8"
> LC_NAME="fr_CA.utf8"
> LC_ADDRESS="fr_CA.utf8"
> LC_TELEPHONE="fr_CA.utf8"
> LC_MEASUREMENT="fr_CA.utf8"
> LC_IDENTIFICATION="fr_CA.utf8"
> LC_ALL=
>
> $ cat /etc/locale.gen | grep -v '^#'
> en_CA.UTF-8 UTF-8
> en_NZ.UTF-8 UTF-8
> fr_CA.UTF-8 UTF-8
>
> Let me know if there's anything else I can provide to help reproduce the
> problem.
>
> Francois
>
> --
> https://fmarier.org/
--
epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f
-- frykten for herren er opphav til kunnskap --
diff --git a/ts b/ts
index af23cf7..fbd5b1a 100755
--- a/ts
+++ b/ts
@@ -54,6 +54,11 @@ use strict;
use POSIX q{strftime};
no warnings 'utf8';
+# Ensure that text read or printed are converted from/to UTF-8.
+binmode STDIN, ':utf8';
+binmode STDOUT, ':utf8';
+binmode STDERR, ':utf8';
+
$|=1;
my $rel=0;
Bug#1014382: dradio currently not usable
Package: dradio Version: 3.8-2+b3 Severity: important Dear Maintainer, dradio is currently barely usable. A simple call of dradio after a fresh installation results in a segmentation fault, no matter if dradio-config has been called before. Re-compiled and run inside of gdb: $ gdb dradio GNU gdb (Debian 11.2-1) 11.2 ... (gdb) run Starting program: /tmp/dradio-3.8/src/dradio [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x007ff7ea5cf0 in new_menu_sp () from /usr/lib/aarch64-linux-gnu/libmenuw.so.6 (gdb) bt #0 0x007ff7ea5cf0 in new_menu_sp () from /usr/lib/aarch64-linux-gnu/libmenuw.so.6 #1 0x00555e70 in menu_create () at gui.c:242 #2 0x005534ec in main (argc=1, argv=0x7fed98) at dradio.c:101 (gdb) Kind regards, Nicolas -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.17.0-rc2+ (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.UTF-8), LANGUAGE=C Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dradio depends on: ii libc62.33-7 ii libcurl3-gnutls 7.83.1-1 ii libexpat12.4.8-1 ii libncursesw6 6.3+20220423-2 ii libtinfo66.3+20220423-2 ii mplayer 2:1.4+ds1-3+b1 ii tidy 2:5.6.0-11 ii xsltproc 1.1.34-4 dradio recommends no packages. dradio suggests no packages. -- no debconf information
Bug#1008631: RFS: git-revise/0.7.0-1 -- handy git tool for doing efficient in-memory commit rebases
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "git-revise": * Package name: git-revise Version : 0.7.0-1 Upstream Author : Nika Layzell * URL : https://mystor.github.io/git-revise.html * License : MIT * Vcs : https://salsa.debian.org/debian/git-revise Section : vcs The source builds the following binary packages: git-revise - handy git tool for doing efficient in-memory commit rebases & fixups To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git-revise/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git-revise/git-revise_0.7.0-1.dsc Changes since the last upload: git-revise (0.7.0-1) unstable; urgency=medium . * Fix package section to "vcs" (Closes: #1002543); thanks to Jonas Smedegaard * debian/gbp.conf: Add basic git-buildpackage configuration * New upstream version 0.7.0 * Remove obsolete patches * d/tests/control: Add test dependencies gpg, gpg-agent Kind regards, Nicolas signature.asc Description: PGP signature
Bug#1005219: minidlna: Floods logfile with 'minidlna.c:166: error: accept(http): Too many open files'
Package: minidlna Version: 1.3.0+dfsg-2 Severity: important Dear Maintainer, When I let minidlna run for some weeks, it eventually starts flooding its logfile with endlessly repeated minidlna.c:166: error: accept(http): Too many open files until the filesystem is full. (Which is a quite annoying behaviour to me.) Kind regards, Nicolas -- System Information: Debian Release: 11.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-4-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.UTF-8), LANGUAGE=nb:nn:se:dk:de:C Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages minidlna depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii libavformat587:4.3.3-0+deb11u1 ii libavutil56 7:4.3.3-0+deb11u1 ii libc62.31-13+deb11u2 ii libexif120.6.22-3 ii libflac8 1.3.3-2 ii libid3tag0 0.15.1b-14 ii libjpeg62-turbo 1:2.0.6-4 ii libogg0 1.3.4-0.1 ii libsqlite3-0 3.34.1-3 ii libvorbis0a 1.3.7-1 ii lsb-base 11.1.0 minidlna recommends no packages. minidlna suggests no packages. -- Configuration Files: /etc/minidlna.conf changed: media_dir=A,/home/mpd/music media_dir=A,/home/mpd/playlists merge_media_dirs=no log_dir=/var/log/minidlna network_interface=eth0 port=8200 album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg album_art_names=AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg album_art_names=Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg wide_links=yes -- no debconf information
Bug#1002543: git-revise: please use package section vcs (not devel)
tags 1002543 + pending confirmed Hi Jonas, > I notice that package git-revise is in package section "devel". ... > Please change package section to vcs - ... thanks for your bug report! I can't reconstruct why I chose package section "devel" initially, thus I will follow your suggestion and change it to "vcs" [1]. Upload will be prepared soon. Kind regards and godt nytår! Nicolas [1]: https://salsa.debian.org/nsc/git-revise/-/commit/b9494c66f89f8bef0421930a29af6529c59840e7 -- epost|xmpp: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap --
Bug#993860: public-inbox-imapd: missing dependency libparse-recdescent-perl
Package: public-inbox Version: 1.6.0-1 Severity: normal X-Debbugs-Cc: nico...@fjasle.eu Hi Uwe, thanks for packaging public-inbox! When I attempted to start public-inbox-imapd, it failed: $ public-inbox-imapd Can't locate Parse/RecDescent.pm in @INC (you may need to install the Parse::RecDescent module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/share/perl5/PublicInbox/IMAPsearchqp.pm line 10. BEGIN failed--compilation aborted at /usr/share/perl5/PublicInbox/IMAPsearchqp.pm line 10. Compilation failed in require at /usr/share/perl5/PublicInbox/IMAP.pm line 43. BEGIN failed--compilation aborted at /usr/share/perl5/PublicInbox/IMAP.pm line 43. Compilation failed in require at /usr/lib/x86_64-linux-gnu/perl-base/base.pm line 135. ...propagated at /usr/lib/x86_64-linux-gnu/perl-base/base.pm line 157. BEGIN failed--compilation aborted at /usr/share/perl5/PublicInbox/IMAPdeflate.pm line 10. Compilation failed in require at /usr/bin/public-inbox-imapd line 8. BEGIN failed--compilation aborted at /usr/bin/public-inbox-imapd line 8. Installing libparse-recdescent-perl was enough on my system to solve the issue. Perhaps you might want to add it as dependency? Kind regards, Nicolas -- System Information: Debian Release: bullseye/sid APT prefers stable APT policy: (990, 'stable'), (500, 'oldstable-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.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 public-inbox depends on: ii git1:2.30.2-1 ii libdbd-sqlite3-perl1.66-1+b1 ii libemail-mime-perl 1.949-1 ii libnet-server-perl 2.009-2 ii libplack-perl 1.0048-1 ii libsearch-xapian-perl 1.2.25.4-1 ii perl 5.32.1-4 ii xapian-tools 1.4.18-3 public-inbox recommends no packages. public-inbox suggests no packages. -- no debconf information
Bug#990117: mbsync: Recursive symlink in maildir path causes abort
Package: isync Version: 1.3.0-2.1 Severity: normal Dear Maintainer, if a maildir path contains a recursive symlink, mbsync does not detect recursion but aborts with Fatal: buffer too small. Please report a bug. A run inside gdb reveals: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7788f55b in __GI_abort () at abort.c:79 #2 0x55562656 in oob () at util.c:334 #3 0x5556287a in nfsnprintf (buf=buf@entry=0x7fffd684 ".uidvalidit", blen=blen@entry=12, fmt=fmt@entry=0x55576118 "%s") at util.c:345 #4 0x5556e112 in maildir_list_recurse (ctx=ctx@entry=0x555810e0, isBox=isBox@entry=33, inbox=inbox@entry=0x55580a90 "/home/nicolas/Maildir", inboxLen=inboxLen@entry=21, basePath=basePath@entry=0x0, basePathLen=basePathLen@entry=0, path=0x7fffd590 "/home/nicolas/Mail/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/I"..., pathLen=244, name=0x7fffd690 "Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/Inbox/notes/Sonstige"..., nameLen=225, flags=) at drv_maildir.c:413 ... A recursive symlink (here: Inbox -> ".") might be considered bad practise. But perhaps a recursion detection is more user-friendly? Kind regards, Nicolas -- System Information: Debian Release: 11.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-6-arm64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages isync depends on: ii libc6 2.31-11 ii libdb5.35.3.28+dfsg1-0.8 ii libsasl2-2 2.1.27+dfsg-2.1 ii libssl1.1 1.1.1k-1 ii zlib1g 1:1.2.11.dfsg-2 isync recommends no packages. Versions of packages isync suggests: ii mutt 2.0.5-4 -- no debconf information
Bug#989143: initramfs-tools: doesn’t actually compress with zstd
Control: tags -1 + moreinfo Hi Christoph, > Just noted by coincidence, that even though I have set: > COMPRESS=zstd > and zstd is installed and even runs (seen in e.g. top utility) when running > update-initramfs -u > the files are in the end nevertheless plain cpio: > file /boot/initrd.img-5.10.0-7-amd64 > /boot/initrd.img-5.10.0-7-amd64: ASCII cpio archive (SVR4 with no CRC) I can see the same behaviour on my amd64 machine, but on my arm64 system 'file' identifies the initramfs images as zstd archives: /boot/initrd.img-5.10.0-6-arm64: Zstandard compressed data (v0.8+), Dictionary ID: None According to the last lines of /usr/sbin/mkinitramfs, there seems to be a non-compressed cpio at the top of your amd64's initrd.img which is followed by the zstd-compressed one. To validate my argumentation, please set 'COMPRESS=gzip' in '/etc/initramfs-tools/initramfs.conf', run 'update-initramfs -u' again and compare the sizes of the (probably) zstd-compressed one with the gzip-compressed one. On my amd64 machine, it looks like this: $ file initrd-*/* initrd-gzip-compressed/initrd.img-5.10.0-6-amd64: ASCII cpio archive (SVR4 with no CRC) initrd-zstd-compressed/initrd.img-5.10.0-6-amd64: ASCII cpio archive (SVR4 with no CRC) $ ls -hs initrd-*/* 36M initrd-gzip-compressed/initrd.img-5.10.0-6-amd64 28M initrd-zstd-compressed/initrd.img-5.10.0-6-amd64 . Kind regards, Nicolas PS: Does anyone know, how to extract the second (aka compressed) cpio archive from the combined initrd.img?
Bug#836211: dpkg: Cannot upgrade some packages on overlayfs: Invalid cross-device link
Hi,
On Sun 02 May 2021 09:06:49 GMT, Salvatore Bonaccorso wrote:
> Hi,
>
> On Mon, Sep 04, 2017 at 03:01:26PM +0200, Raphael Hertzog wrote:
> > Control: reopen -1
> > Control: notfixed -1 4.10.0-1~exp1
> > Control: found -1 4.12.6-1
> >
> > On Fri, 25 Aug 2017, Raphael Hertzog wrote:
> > > I verified today that the issue is gone with Linux 4.12 and apparently
> > > the appropriate patches have been merged for Linux 4.10 already (merged by
> > > linus in commit ff0f962ca3c38239b299a70e7eea27abfbb979c3).
> >
> > I don't know how I did my check last time, but I was wrong. The changes
> > merged above fixed issues about tools being confused with the unexpected
> > st_dev values on files but they did not fix the fact that overlayfs
> > might return EXDEV when renaming a directory that is part of the lower
> > layer.
> >
> > So I'm opening the bug again.
>
> Doing some maintenance on open kernel bugs. Is this by now still an
> issue with recent kernels? If not can we close this bug? Part of the
> isuses at leas were fixed in 4.10.0-1~exp1, but what about the
> remaining or followup issue mentioned by Raphael?
>
> Regards,
> Salvatore
the EXDEV return value is still reproducible:
$ mkdir -p /tmp/ovl/{lower/dir,upper,work,mount}
$ sudo mount -t overlay -o
lowerdir=/tmp/ovl/lower,upperdir=/tmp/ovl/upper,workdir=/tmp/ovl/work none
/tmp/ovl/mount
$ strace -e trace=rename,renameat,renameat2 mv /tmp/ovl/mount/dir
/tmp/ovl/mount/newname
renameat2(AT_FDCWD, "/tmp/ovl/mount/dir", AT_FDCWD,
"/tmp/ovl/mount/newname", RENAME_NOREPLACE) = -1 EXDEV (Invalid cross-device
link)
+++ exited with 0 +++
and in dpkg sources I cannot find any special handling for EXDEV. From
my point of view, the bug is still not fixed.
Kind regards,
Nicolas
signature.asc
Description: PGP signature
Bug#961638: proposal: stocat - probabilistic cat
Dear Joey, Stefano suggested the inclusion of his 'stocat' (see below) tool into moreutils. I think the simple script is a great idea and I would like to see it in the moreutils collection. What do you think? Might you consider to adopt it? Kind regards, Nicolas On Wed, Mar 10, 2021 at 02:38:55PM +0100, Stefano Zacchiroli wrote: > On Tue, May 26, 2020 at 11:39:42PM +0200, Stefano Zacchiroli wrote: > > I'm hereby proposing the inclusion of the attached "stocat" utility to > > moreutils. It's like cat, but output lines with a given probability, > > defaulting to 10%. It's very useful for random sampling (and *much* > > more efficient at that than using "shuf" which is unwieldy on very > > large inputs) and, while it can be implemented instead with awk/perl > > oneliners, those oneliners aren't very mnemonic and are error prone. > > Heya, as I haven't heard back about this, but others have asked me about > how to best use stocat, I've now released it as an independent tool > here: > > https://gitlab.com/zacchiro/stocat > > I'm happy to reconsider if/when it gets integrated into moreutils. > > Cheers > -- > Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o > Computer Science Professor . CTO Software Heritage . . . . . o . . . o o > Former Debian Project Leader & OSI Board Director . . . o o o . . . o . > « the first rule of tautology club is the first rule of tautology club » -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#969223: Can't rm directory on overlayfs in userns
On Wed 03 Mar 2021 22:50:44 GMT Shengjing Zhu wrote: > On Wed, Mar 03, 2021 at 11:30:20AM +0100, Nicolas Schier wrote: > > On Wed 03 Mar 2021 17:33:16 GMT Shengjing Zhu write: > > > > > > On Wed, Mar 3, 2021 at 3:40 PM Nicolas Schier wrote: > > > > > [2]: > > > > > https://lore.kernel.org/linux-unionfs/CAJfpegsiuf8ib5cvVrr=zhz+xu7bmmtt2eyapseudmpcrbu...@mail.gmail.com/T/#t > > > > > > > > The overlay fs patchset [2] has been merged and with v5.10.13 (tested > > > > on linux-image-5.10.0-3-arm64) the issue is no more reproducible for > > > > me. Might you want to re-check on your site? > > > > > > > > > > If I understand correctly, the upstream patch is merged into the v5.11 > > > tree. > > > > Sorry. Yes, you're right. > > > > > And I still can reproduce the error on the Debian v5.10 kernel. > > > > That confuses me quite a bit. I did it once again on an ext4 mount > > (still the 5.10.0-3-arm64 kernel): > > > > nsc@lillesand:/tmp$ cat > > /sys/module/overlay/parameters/permit_mounts_in_userns > > Y > > nsc@lillesand:/tmp$ mkdir -p test/lower/a test/merged test/upper test/work > > nsc@lillesand:/tmp$ uname -a | tee test/lower/a/a > > Linux lillesand 5.10.0-3-arm64 #1 SMP Debian 5.10.13-1 (2021-02-06) > > aarch64 GNU/Linux > > nsc@lillesand:/tmp$ unshare -m -U -r > > root@lillesand:/tmp# mount -t overlay -o > > rw,lowerdir=/tmp/test/lower,upperdir=/tmp/test/upper,workdir=/tmp/test/work > > overlay /tmp/test/merged > > root@lillesand:/tmp# rm -rf test/merged/a > > root@lillesand:/tmp# find test -ls > > 1597776 4 drwxr-xr-x 6 root root 4096 mars 3 08:24 > > test > > 1973978 4 drwxr-xr-x 2 root root 4096 mars 3 08:27 > > test/upper > > 2099881 0 c- 1 root root 0, 0 mars 3 08:27 > > test/upper/a > > 1973978 4 drwxr-xr-x 1 root root 4096 mars 3 08:27 > > test/merged > > 1714388 4 drwxr-xr-x 3 root root 4096 mars 3 08:24 > > test/lower > > 1714389 4 drwxr-xr-x 2 root root 4096 mars 3 08:27 > > test/lower/a > > 1714393 4 -rw-r--r-- 1 root root 86 mars 3 10:48 > > test/lower/a/a > > 1973979 4 drwxr-xr-x 3 root root 4096 mars 3 10:48 > > test/work > > 2099880 4 d- 2 root root 4096 mars 3 10:48 > > test/work/work > > root@lillesand:/tmp# > > > zsj@debian:~$ cat /sys/module/overlay/parameters/permit_mounts_in_userns > Y > zsj@debian:~/t$ mkdir -p test/lower/a test/merged test/upper test/work > zsj@debian:~/t$ uname -a | tee test/lower/a/a > Linux debian 5.10.0-3-amd64 #1 SMP Debian 5.10.13-1 (2021-02-06) x86_64 > GNU/Linux > zsj@debian:~/t$ unshare -m -U -r > root@debian:~/t# mount -t overlay -o > rw,lowerdir=./test/lower,upperdir=./test/upper,workdir=./test/work overlay > ./test/merged/ > root@debian:~/t# rm -rf ./test/merged/a > rm: cannot remove './test/merged/a': Input/output error > root@debian:~/t# find test -ls > 7350352 4 drwxr-xr-x 6 root root 4096 Mar 3 22:44 test > 7351341 4 drwxr-xr-x 3 root root 4096 Mar 3 22:44 > test/lower > 7353492 4 drwxr-xr-x 2 root root 4096 Mar 3 22:44 > test/lower/a > 7356441 4 -rw-r--r-- 1 root root 82 Mar 3 22:44 > test/lower/a/a > 7356069 4 drwxr-xr-x 3 root root 4096 Mar 3 22:45 > test/work > 7358324 4 d- 2 root root 4096 Mar 3 22:45 > test/work/work > 7358564 0 c- 2 root root 0, 0 Mar 3 22:45 > test/work/work/#4 > 7354400 4 drwxr-xr-x 3 root root 4096 Mar 3 22:44 > test/upper > 7358563 4 drwxr-xr-x 2 root root 4096 Mar 3 22:45 > test/upper/a > 7358564 0 c- 2 root root 0, 0 Mar 3 22:45 > test/upper/a/a > 7354400 4 drwxr-xr-x 1 root root 4096 Mar 3 22:44 > test/merged > 7353492 4 drwxr-xr-x 1 root root 4096 Mar 3 22:45 > test/merged/a > > > Do you see any kernel log message from overlay fs? Might it depend on > > the underlying filesystem? Can you create a white-out char dev node > > manually? > > > > [1215353.859717] Setting dangerous option permit_mounts_in_userns - tainting > kernel > [1215353.859841] overlayfs: overlayfs: Allowing overlay mounts in user > n
Bug#969223: Can't rm directory on overlayfs in userns
On Wed 03 Mar 2021 17:33:16 GMT Shengjing Zhu write: > > On Wed, Mar 3, 2021 at 3:40 PM Nicolas Schier wrote: > > > [2]: > > > https://lore.kernel.org/linux-unionfs/CAJfpegsiuf8ib5cvVrr=zhz+xu7bmmtt2eyapseudmpcrbu...@mail.gmail.com/T/#t > > > > The overlay fs patchset [2] has been merged and with v5.10.13 (tested > > on linux-image-5.10.0-3-arm64) the issue is no more reproducible for > > me. Might you want to re-check on your site? > > > > If I understand correctly, the upstream patch is merged into the v5.11 tree. Sorry. Yes, you're right. > And I still can reproduce the error on the Debian v5.10 kernel. That confuses me quite a bit. I did it once again on an ext4 mount (still the 5.10.0-3-arm64 kernel): nsc@lillesand:/tmp$ cat /sys/module/overlay/parameters/permit_mounts_in_userns Y nsc@lillesand:/tmp$ mkdir -p test/lower/a test/merged test/upper test/work nsc@lillesand:/tmp$ uname -a | tee test/lower/a/a Linux lillesand 5.10.0-3-arm64 #1 SMP Debian 5.10.13-1 (2021-02-06) aarch64 GNU/Linux nsc@lillesand:/tmp$ unshare -m -U -r root@lillesand:/tmp# mount -t overlay -o rw,lowerdir=/tmp/test/lower,upperdir=/tmp/test/upper,workdir=/tmp/test/work overlay /tmp/test/merged root@lillesand:/tmp# rm -rf test/merged/a root@lillesand:/tmp# find test -ls 1597776 4 drwxr-xr-x 6 root root 4096 mars 3 08:24 test 1973978 4 drwxr-xr-x 2 root root 4096 mars 3 08:27 test/upper 2099881 0 c- 1 root root 0, 0 mars 3 08:27 test/upper/a 1973978 4 drwxr-xr-x 1 root root 4096 mars 3 08:27 test/merged 1714388 4 drwxr-xr-x 3 root root 4096 mars 3 08:24 test/lower 1714389 4 drwxr-xr-x 2 root root 4096 mars 3 08:27 test/lower/a 1714393 4 -rw-r--r-- 1 root root 86 mars 3 10:48 test/lower/a/a 1973979 4 drwxr-xr-x 3 root root 4096 mars 3 10:48 test/work 2099880 4 d- 2 root root 4096 mars 3 10:48 test/work/work root@lillesand:/tmp# Do you see any kernel log message from overlay fs? Might it depend on the underlying filesystem? Can you create a white-out char dev node manually? > And another thing is that the upstream patch introduces a new mount > option, userxattr, instead of module parameter. The 'permit_mounts_in_userns' module parameter becomes superfluous with v5.11 as overlay fs mounts will then always be enabled in userspace namespace. Kind regards, Nicolas -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#969223: Can't rm directory on overlayfs in userns
On Fri, Dec 11, 2020 09:10 AM Nicolas Schier wrote:
>
> On Tue, Sep 17, 2020 at 2:57 AM Shengjing Zhu wrote:
> >
> > On Thu, Sep 17, 2020 at 2:52 AM Nicolas Schier wrote:
> > >
> > > > I think I just mess up when debugging. It seems it never works.
> > > >
> > > > Maybe we should revert permit_mounts_in_userns? as it doesn't seem to
> > > > work. Buster is also affected.
> > >
> > > Please, don't be too fast when thinking about a revert. Several of my
> > > colleagues (Debian users) cling to the feature since they need it for
> > > using the company's LXC containers; if permit_mounts_in_userns is
> > > removed again, they might be forced to switch to non-Debian kernels or
> > > to live-patch the kernel with fragile stuff like [1], cp. #913880.
> >
> > I mean if you can't even remove a directory with files, it's too broken to
> > use.
> > So your colleagues find the userns overlay works?
> > Or you mean we should take Ubuntu's patch to fix the issue?
>
> sorry for the long delay. My colleagues are using unpriviledged LXC
> with overlay fs for building purposes only, thus, read-only access is
> sufficient and works. (But yes, the incomplete write-support leads to
> annoyance.)
>
> Currently, there is a patch on linux-unionfs that allows using user
> xattrs for overlay fs meta data [1]. If the related patchset [2] is
> going to be merged, the Debian patch will become obsolete; otherwise we
> could think about picking up the patch from [1].
>
> As far as I have seen, the Ubuntu patch allows unpriviledged users to
> modify 'trusted.overlay.*' xattrs, which probably has security
> implications. ("Probably" as just had a superficial look at it.)
>
> I would prefer to keep a watch on [2] and dicuss further, if it has
> been merged or rejected.
>
> Kind regards,
> Nicolas
>
>
>
> [1]: [PATCH v2 06/10] ovl: user xattr
>
> https://lore.kernel.org/linux-unionfs/20201207163255.564116-7-mszer...@redhat.com/
>
> [2]:
> https://lore.kernel.org/linux-unionfs/CAJfpegsiuf8ib5cvVrr=zhz+xu7bmmtt2eyapseudmpcrbu...@mail.gmail.com/T/#t
The overlay fs patchset [2] has been merged and with v5.10.13 (tested
on linux-image-5.10.0-3-arm64) the issue is no more reproducible for
me. Might you want to re-check on your site?
Kind regards,
Nicolas
--
epost: nico...@fjasle.eu irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f
-- frykten for herren er opphav til kunnskap --
signature.asc
Description: PGP signature
Bug#981559: purple-rocketchat: Please package the new upstream version (from the new github repo)
Package: purple-rocketchat Version: 0.1~hg20200403.800ef89-1 Severity: normal Dear Maintainer, there is a new upstream version (still without a tag) of purple-rocketchat available, which does prevents quite a number of crashes with current rocketchat versions and fixes visibility issues. Can you please package the new upstream version? Thanks and kind regards, Nicolas PS: Upstream repository has moved to https://github.com/EionRobb/purple-rocketchat.git
Bug#969223: Can't rm directory on overlayfs in userns
On Tue, Sep 17, 2020 at 2:57 AM Shengjing Zhu wrote:
>
> On Thu, Sep 17, 2020 at 2:52 AM Nicolas Schier wrote:
> >
> > > I think I just mess up when debugging. It seems it never works.
> > >
> > > Maybe we should revert permit_mounts_in_userns? as it doesn't seem to
> > > work. Buster is also affected.
> >
> > Please, don't be too fast when thinking about a revert. Several of my
> > colleagues (Debian users) cling to the feature since they need it for
> > using the company's LXC containers; if permit_mounts_in_userns is
> > removed again, they might be forced to switch to non-Debian kernels or
> > to live-patch the kernel with fragile stuff like [1], cp. #913880.
>
> I mean if you can't even remove a directory with files, it's too broken to
> use.
> So your colleagues find the userns overlay works?
> Or you mean we should take Ubuntu's patch to fix the issue?
sorry for the long delay. My colleagues are using unpriviledged LXC
with overlay fs for building purposes only, thus, read-only access is
sufficient and works. (But yes, the incomplete write-support leads to
annoyance.)
Currently, there is a patch on linux-unionfs that allows using user
xattrs for overlay fs meta data [1]. If the related patchset [2] is
going to be merged, the Debian patch will become obsolete; otherwise we
could think about picking up the patch from [1].
As far as I have seen, the Ubuntu patch allows unpriviledged users to
modify 'trusted.overlay.*' xattrs, which probably has security
implications. ("Probably" as just had a superficial look at it.)
I would prefer to keep a watch on [2] and dicuss further, if it has
been merged or rejected.
Kind regards,
Nicolas
[1]: [PATCH v2 06/10] ovl: user xattr
https://lore.kernel.org/linux-unionfs/20201207163255.564116-7-mszer...@redhat.com/
[2]:
https://lore.kernel.org/linux-unionfs/CAJfpegsiuf8ib5cvVrr=zhz+xu7bmmtt2eyapseudmpcrbu...@mail.gmail.com/T/#t
signature.asc
Description: PGP signature
Bug#976777: RFS: git-revise/0.6.0-2 [RC] -- handy git tool for doing efficient in-memory commit rebases
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "git-revise": * Package name: git-revise Version : 0.6.0-2 Upstream Author : Nika Layzell * URL : https://mystor.github.io/git-revise.html * License : MIT * Vcs : https://salsa.debian.org/debian/git-revise Section : devel It builds those binary packages: git-revise - handy git tool for doing efficient in-memory commit rebases & fixups To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git-revise/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git-revise/git-revise_0.6.0-2.dsc Changes since the last upload: git-revise (0.6.0-2) unstable; urgency=medium . * debian/tests: switch from tox to pytest (Closes: #975415) Regards, Nicolas -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap --
Bug#975415: git-revise: autopkgtest failure on armhf & ppc64el showing the package downloads code from internet
Source: git-revise Tags: pending Thanks for the verbose explanation! I uploaded a new version of git-revise that uses pytest to run the tests (and no more tox with its automatically downloaded dependencies). As soon as I have found a sponsor, this RC bug should be fixed. Kind regards, Nicolas signature.asc Description: PGP signature
Bug#386755: [PATCH 1/2] ifdata: fail when -ph is given but no hwaddr is available (Closes: #386755)
Exit ifdata with an error code if '-ph' (print hardware address) is
given but no hardware address is available for the given network device.
Previously, ifdata printed the invalid hardware address
00:00:00:00:00:00 in such cases and exited as if this was the real
hardware address.
Signed-off-by: Nicolas Schier
---
ifdata.c | 7 +++
ifdata.docbook | 5 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/ifdata.c b/ifdata.c
index 99f30e9..6e0bd0b 100644
--- a/ifdata.c
+++ b/ifdata.c
@@ -195,6 +195,13 @@ void if_hwaddr(const char *iface) {
return;
hwaddr = (unsigned char *)r.ifr_hwaddr.sa_data;
+
+ if (!hwaddr[0] && !hwaddr[1] && !hwaddr[2] &&
+ !hwaddr[3] && !hwaddr[4] && !hwaddr[5]) {
+ fprintf(stderr, "Error: %s: no hardware address\n", iface);
+ exit(1);
+ }
+
printf("%02X:%02X:%02X:%02X:%02X:%02X",
hwaddr[0], hwaddr[1], hwaddr[2], hwaddr[3], hwaddr[4],
hwaddr[5]);
}
diff --git a/ifdata.docbook b/ifdata.docbook
index 47f4143..d2b3e10 100644
--- a/ifdata.docbook
+++ b/ifdata.docbook
@@ -155,7 +155,10 @@ with this program; if not, write to the Free Software
Foundation, Inc.,
-ph
Prints the hardware address of the
- interface.
+interface. Exit with a failure exit
code
+if there is not hardware address for
the
+given network interface.
+
--
2.25.0
Bug#969223: Can't rm directory on overlayfs in userns
> I think I just mess up when debugging. It seems it never works. > > Maybe we should revert permit_mounts_in_userns? as it doesn't seem to > work. Buster is also affected. Please, don't be too fast when thinking about a revert. Several of my colleagues (Debian users) cling to the feature since they need it for using the company's LXC containers; if permit_mounts_in_userns is removed again, they might be forced to switch to non-Debian kernels or to live-patch the kernel with fragile stuff like [1], cp. #913880. [1]: https://rocketgit.com/user/nicolas/overlay-userns-dkms -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap --
Bug#969223: Can't rm directory on overlayfs in userns
On Wed, Sep 02, 2020 at 11:52:41AM +0800, Shengjing Zhu wrote: > On Sat, Aug 29, 2020 at 10:13 PM Shengjing Zhu wrote: > > > > Source: linux > > Version: 5.7.10-1 > > Severity: normal > > > > Hi, > > > > After enabling overlayfs for userns, I find it doesn't work as expected. > > > > $ cat /sys/module/overlay/parameters/permit_mounts_in_userns > > Y > > > > zsj@debian:~/test$ pwd > > /home/zsj/test > > zsj@debian:~/test$ tree > > . > > ├── lower > > │ └── a > > │ └── a > > ├── merged > > ├── upper > > └── work > > > > zsj@debian:~/test$ unshare -m -U -r > > root@debian:~/test# mount -t overlay -o > > rw,lowerdir=/home/zsj/test/lower,upperdir=/home/zsj/test/upper,workdir=/home/zsj/test/work > > overlay /home/zsj/test/merged > > root@debian:~/test# rm -rf merged/a > > rm: cannot remove 'merged/a': Input/output error > > Hi, overlayfs uses filesystem xattrs to mark "whiteouts" and redirects of directories, which are only accessable for root (CAP_SYS_ADMIN), thus, not when overlay is mounted in a user namespace, cp. e.g. [1,2]. Ubuntu kernel "solves" this by skipping the "trusted."-xattr check, thus allowing setting and removal of 'trusted.overlay.*' xattrs from within user namespaces; but those are still visible in all other namespaces. A following overlayfs mount done by the real root user will use these modified xattrs. To me it would seem to be more adequate if overlayfs would use 'overlay.*' instead of 'trusted.overlay.*', if it is mounted in an unpriviledged user namespace. But this would make overlay mounts done by root incompatible with those done in a user namespace. Maybe you find #836211 to be related to this. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/xattr.c?h=linux-5.7.y#n113 [2]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/xattr.c?h=linux-5.7.y#n1049 [3]: https://kernel.ubuntu.com/git/ubuntu/ubuntu-focal.git/commit/?id=111cd1a9840ce187e28b49fe4e77b9b5e84386b1 > If I upgrade a debian10 VM to testing, it seems to work. > However if I boot a new debian testing VM, it seems not to work. > Both VMs are downloaded from http://cdimage.debian.org/cdimage/cloud/ > What can be the difference here? I'm lost on debugging this.. This confuses me. Are you sure, you used the same kernel version on both VMs when mounting overlayfs in userns? Kind regards, Nicolas -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap --
Bug#964862: RFS: git-revise/0.6.0-1 -- handy git tool for doing efficient in-memory commit rebases & fixups
Hei, På fr. 28. aug. 2020 kl. 22.54 + skrev Nicolas Schier: > On Fri, Aug 28, 2020 at 01:28:00PM +0300, Adrian Bunk wrote: > > Control: tags -1 moreinfo > > > > On Sat, Jul 11, 2020 at 02:02:43PM +0200, Nicolas Schier wrote: > > >... > > > Changes since the last upload: > > >... > > >* Enable autopkgtest by using upstream tests (Closes: #944957) > > > > This likely worked when you posted the sponsorship request, > > but new pylint makes it fail: > > > > ... > > lint run-test: commands[0] | pylint gitrevise > > * Module gitrevise.merge > > gitrevise/merge.py:207:12: W0707: Consider explicitly re-raising using the > > 'from' keyword (raise-missing-from) > > gitrevise/merge.py:225:12: W0707: Consider explicitly re-raising using the > > 'from' keyword (raise-missing-from) > > * Module gitrevise.utils > > gitrevise/utils.py:73:8: W0707: Consider explicitly re-raising using the > > 'from' keyword (raise-missing-from) > > gitrevise/utils.py:89:12: W0707: Consider explicitly re-raising using the > > 'from' keyword (raise-missing-from) > > > > -- > > Your code has been rated at 9.96/10 (previous run: 9.96/10, +0.00) > > > > ERROR: InvocationError for command > > /tmp/autopkgtest.SDfHIM/tree/.tox/lint/bin/pylint gitrevise (exited with > > code 4) > > ... > finally, I uploaded a new version. Since I did not get any feedback from upstream, yet, I am going open an issue for upstream. Adrian, can you please have a look at the freshly uploaded version? Thanks and kind regards, Nicolas -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#964862: git-revice/0.6.0: pylint warning prevent Debian packaging
Hi Nika,
pylint complains since version 2.6 about some 'raise' keywords in
git-revise that are not re-raising the original exceptions. These
issues currently prevent the release of the Debian package for
git-revise/0.6.0:
> ...
> lint run-test: commands[0] | pylint gitrevise
> * Module gitrevise.merge
> gitrevise/merge.py:207:12: W0707: Consider explicitly re-raising using the
> 'from' keyword (raise-missing-from)
> gitrevise/merge.py:225:12: W0707: Consider explicitly re-raising using the
> 'from' keyword (raise-missing-from)
> * Module gitrevise.utils
> gitrevise/utils.py:73:8: W0707: Consider explicitly re-raising using the
> 'from' keyword (raise-missing-from)
> gitrevise/utils.py:89:12: W0707: Consider explicitly re-raising using the
> 'from' keyword (raise-missing-from)
>
> --
> Your code has been rated at 9.96/10 (previous run: 9.96/10, +0.00)
>
> ERROR: InvocationError for command
> /tmp/autopkgtest.SDfHIM/tree/.tox/lint/bin/pylint gitrevise (exited with code
> 4)
> ...
>
Can you please review the patch (attached or [1]) and possible consider
adoption? Shall I open a github issue/pull-request for that?
Looking forward for your feedback.
Kind regards,
Nicolas
[1] https://github.com/fjasle/git-revise -b satisfy-pylint26-raise-missing-from
--
epost: nico...@fjasle.eu irc://oftc.net/nsc
↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f
-- frykten for herren er opphav til kunnskap --
From 09ff90ded38e20a6d99ca86263332eb2a0515800 Mon Sep 17 00:00:00 2001
From: Nicolas Schier
Date: Thu, 3 Sep 2020 11:25:28 +0200
Subject: [PATCH] Satisfy pylint raise-missing-from warnings
Add 'from' to re-raise exceptions. Since version 2.6, pylint complains
about four raise-missing-from issues:
gitrevise/merge.py:207:12: W0707: Consider explicitly re-raising using the 'from' keyword (raise-missing-from)
gitrevise/merge.py:225:12: W0707: Consider explicitly re-raising using the 'from' keyword (raise-missing-from)
gitrevise/utils.py:73:8: W0707: Consider explicitly re-raising using the 'from' keyword (raise-missing-from)
gitrevise/utils.py:89:12: W0707: Consider explicitly re-raising using the 'from' keyword (raise-missing-from)
Simply adding the 'from' satisfies pylint.
Signed-off-by: Nicolas Schier
---
gitrevise/merge.py | 4 ++--
gitrevise/utils.py | 8 +---
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/gitrevise/merge.py b/gitrevise/merge.py
index 9e0348d..30ff1c1 100644
--- a/gitrevise/merge.py
+++ b/gitrevise/merge.py
@@ -204,7 +204,7 @@ def merge_blobs(
print(f"Conflict applying '{labels[2]}'")
print(f" Path: '{path}'")
if input(" Edit conflicted file? (Y/n) ").lower() == "n":
-raise MergeConflict("user aborted")
+raise MergeConflict("user aborted") from err
# Open the editor on the conflicted file. We ensure the relative path
# matches the path of the original file for a better editor experience.
@@ -222,6 +222,6 @@ def merge_blobs(
# Was the merge successful?
if input(" Merge successful? (y/N) ").lower() != "y":
-raise MergeConflict("user aborted")
+raise MergeConflict("user aborted") from err
return Blob(current.repo, merged)
diff --git a/gitrevise/utils.py b/gitrevise/utils.py
index 1395f6e..b3155e8 100644
--- a/gitrevise/utils.py
+++ b/gitrevise/utils.py
@@ -70,7 +70,7 @@ def edit_file_with_editor(editor: str, path: Path) -> bytes:
cmd = ["sh", "-c", f'{editor} "$@"', editor, path.name]
run(cmd, check=True, cwd=path.parent)
except CalledProcessError as err:
-raise EditorError(f"Editor exited with status {err}")
+raise EditorError(f"Editor exited with status {err}") from err
return path.read_bytes()
@@ -85,8 +85,10 @@ def get_commentchar(repo: Repository, text: bytes) -> bytes:
pass
try:
return chars[:1]
-except IndexError:
-raise EditorError("Unable to automatically select a comment character")
+except IndexError as err:
+raise EditorError(
+"Unable to automatically select a comment character"
+) from err
if commentchar == b"":
raise EditorError("core.commentChar must not be empty")
return commentchar
--
2.28.0
signature.asc
Description: PGP signature
Bug#964862: RFS: git-revise/0.6.0-1 -- handy git tool for doing efficient in-memory commit rebases & fixups
On Fri, Aug 28, 2020 at 01:28:00PM +0300, Adrian Bunk wrote: > Control: tags -1 moreinfo > > On Sat, Jul 11, 2020 at 02:02:43PM +0200, Nicolas Schier wrote: > >... > > Changes since the last upload: > >... > >* Enable autopkgtest by using upstream tests (Closes: #944957) > > This likely worked when you posted the sponsorship request, > but new pylint makes it fail: > > ... > lint run-test: commands[0] | pylint gitrevise > * Module gitrevise.merge > gitrevise/merge.py:207:12: W0707: Consider explicitly re-raising using the > 'from' keyword (raise-missing-from) > gitrevise/merge.py:225:12: W0707: Consider explicitly re-raising using the > 'from' keyword (raise-missing-from) > * Module gitrevise.utils > gitrevise/utils.py:73:8: W0707: Consider explicitly re-raising using the > 'from' keyword (raise-missing-from) > gitrevise/utils.py:89:12: W0707: Consider explicitly re-raising using the > 'from' keyword (raise-missing-from) > > -- > Your code has been rated at 9.96/10 (previous run: 9.96/10, +0.00) > > ERROR: InvocationError for command > /tmp/autopkgtest.SDfHIM/tree/.tox/lint/bin/pylint gitrevise (exited with code > 4) > ... thanks for the pointer! I am going to look at it and re-upload in a few days. Kind regards, Nicolas -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap --
Bug#964864: RFS: git-revise/0.6.0-1 -- handy git tool for doing efficient in-memory commit rebases
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "git-revise" * Package name: git-revise Version : 0.6.0-1 Upstream Author : Nika Layzell * URL : https://mystor.github.io/git-revise.html * License : MIT * Vcs : https://salsa.debian.org/debian/git-revise Section : devel It builds those binary packages: git-revise - handy git tool for doing efficient in-memory commit rebases & fixups To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git-revise Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git-revise/git-revise_0.6.0-1.dsc Changes since the last upload: * New upstream version v0.6.0 * Remove superfluous FSH compliance patch (Closes: #944962) * Bump standards to 4.5.0 (no changes required) * Enable autopkgtest by using upstream tests (Closes: #944957) Regards,
Bug#964862: RFS: git-revise/0.6.0-1 -- handy git tool for doing efficient in-memory commit rebases & fixups
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "git-revise" * Package name: git-revise Version : 0.6.0-1 Upstream Author : Nika Layzell * URL : https://mystor.github.io/git-revise.html * License : MIT * Vcs : https://salsa.debian.org/debian/git-revise (release commit + tag is not yet pushed) Section : devel It builds those binary packages: git-revise - handy git tool for doing efficient in-memory commit rebases & fixups To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git-revise Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git-revise/git-revise_0.6.0-1.dsc Changes since the last upload: * New upstream version v0.6.0 * Remove superfluous FSH compliance patch (Closes: #944962) * Bump standards to 4.5.0 (no changes required) * Enable autopkgtest by using upstream tests (Closes: #944957) Kind regards, Nicolas -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#960384: qutebrowser fails to start with critical qt message: Could not initialize GLX
Hi Axel, > > qutebrowser does not start on my arm64 machine (pinebook, a64) (but > > it does well, on my amd64 machine). > > Interesting. I just tried it on Debian Sid armhf and it works there as > well. Do you know if earlier versions of qutebrowser worked on your Pinebook? I tried several version during the last months, but none of them had worked. > I'll probably try to setup an arm64 Raspberry Pi to check if I can > reproduce it. Then I might give some more guidance. On my Rasperry Pi (w/ xpra as xserver) I get the same error message. Thanks in advande and kind regards, Nicolas > Maybe Florian (upstream) has some suggestions and maybe arm64 > experiences, too. > > Regards, Axel > -- > ,''`. | Axel Beckert , https://people.debian.org/~abe/ > : :' : | Debian Developer, ftp.ch.debian.org Admin > `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 > `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#960384: qutebrowser fails to start with critical qt message: Could not initialize GLX
Package: qutebrowser Version: 1.11.1.post1-1 Severity: normal Dear Maintainer, qutebrowser does not start on my arm64 machine (pinebook, a64) (but it does well, on my amd64 machine). Starting it (with `-l debug`) results in these messages: ~ $ qutebrowser -l debug DEBUGinit earlyinit:init_log:275 Log initialized. DEBUGinit app:run:83 Initializing directories... DEBUGinit standarddir:init:336 Base directory: None DEBUGmisc standarddir:_writable_location:263 writable location for ConfigLocation: /home/nicolas/.config DEBUGmisc standarddir:_writable_location:263 writable location for AppLocalDataLocation: /home/nicolas/.local/share DEBUGmisc standarddir:_writable_location:263 writable location for CacheLocation: /home/nicolas/.cache DEBUGmisc standarddir:_writable_location:263 writable location for DownloadLocation: /home/nicolas/Downloads DEBUGmisc standarddir:_writable_location:263 writable location for RuntimeLocation: /run/user/1000 DEBUGinit app:run:87 Initializing config... DEBUGinit app:run:90 Initializing application... DEBUGinit app:__init__:478 Qt arguments: ['/usr/bin/qutebrowser', '--reduced-referrer-granularity'], based on Namespace(backend=None, basedir=None, color=True, command=[], config_py=None, debug=False, debug_flags=[], enable_webengine_inspector=False, force_color=False, json_args=None, json_logging=False, logfilter=None, loglevel='debug', loglines=2000, no_err_windows=False, nowindow=False, override_restore=False, qt_arg=None, qt_flag=None, session=None, target=None, temp_basedir=False, temp_basedir_restarted=None, temp_settings=[], url=[], version=False) WARNING qt-qt.glx Unknown module:none:0 qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) WARNING qt-qt.glx Unknown module:none:0 qglx_findConfig: Failed to finding matching FBConfig for QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize -1, redBufferSize 1, greenBufferSize 1, blueBufferSize 1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior QSurfaceFormat::SingleBuffer, swapInterval 1, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) CRITICAL qt Unknown module:none:0 Could not initialize GLX Fatal Python error: Aborted Current thread 0xb6997010 (most recent call first): File "/usr/lib/python3/dist-packages/qutebrowser/app.py", line 479 in __init__ File "/usr/lib/python3/dist-packages/qutebrowser/app.py", line 92 in run File "/usr/lib/python3/dist-packages/qutebrowser/qutebrowser.py", line 201 in main File "/usr/bin/qutebrowser", line 11 in Avbrutt (SIGABRT) As far as I know, Xorg xserver is using a simple framebuffer device. Do I have to specify, what kind of framebuffer (?) I am using? Do you need anything else for further debugging? Kind regards, Nicolas -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.6.0-1-arm64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.UTF-8), LANGUAGE=nb:nn:se:dk:de:C (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qutebrowser depends on: ii libqt5core5a 5.12.5+dfsg-10 ii libqt5sql5-sqlite5.12.5+dfsg-10 ii python3 3.8.2-3 ii python3-attr 19.3.0-4 ii python3-jinja2 2.11.1-1 ii python3-pkg-resources46.1.3-1 ii python3-pygments 2.3.1+dfsg-3 ii python3-pypeg2 2.15.2-2 ii python3-pyqt55.14.2+dfsg-1+b1 ii python3-pyqt5.qtopengl 5.14.2+dfsg-1+b1 ii python3-pyqt5.qtquick5.14.2+dfsg-1+b1 ii python3-pyqt5.qtsql 5.14.2+dfsg-1+b1 ii python3-ruamel.yaml 0.15.89-3+b2 ii python3-sip 4.19.22+dfsg-1+b1 ii python3-yaml 5.3.1-2 ii qutebrowser-qtwebengine 1.11.1.post1-1 ii qutebrowser-qtwebkit 1.11.1.post1-1 qutebrowser recommends no packages. Versions of packages qutebrowser suggests: pn libjs-pdf ii nodejs10.20.1~dfsg-1 pn python3-colorlog -- no debconf information
Bug#956241: wireguard-dkms: dkms should not attempt to build wireguard-dkms for (Debian) Linux >= 5.5.0-1
Package: wireguard-dkms Version: 1.0.20200330-1 Severity: normal Dear Maintainer, after installing the current Debian Linux 5.5.0-1 package, wireguard-dkms fails to build. Further, the Linux package has wireguard already included as a module. For me it helped to update the 'BUILD_EXCLUSIVE_KERNEL' dkms directive to no more include version 5.5 (thus, only 3.10 up to 5.4). Kind regards, Nicolas -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 5.5.0-1-arm64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.UTF-8), LANGUAGE=nb:nn:se:dk:de:C (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireguard-dkms depends on: ii dkms 2.8.1-5 ii perl 5.30.0-9 Versions of packages wireguard-dkms recommends: ii wireguard1.0.20200319-1 ii wireguard-tools 1.0.20200319-1 wireguard-dkms suggests no packages. -- no debconf information -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- DKMS make.log for wireguard-1.0.20200330 for kernel 5.5.0-1-arm64 (aarch64) on. 08. april 20:41:15 +0200 2020 make: Verzeichnis „/usr/src/linux-headers-5.5.0-1-arm64“ wird betreten AR /var/lib/dkms/wireguard/1.0.20200330/build/built-in.a CC [M] /var/lib/dkms/wireguard/1.0.20200330/build/main.o CC [M] /var/lib/dkms/wireguard/1.0.20200330/build/noise.o CC [M] /var/lib/dkms/wireguard/1.0.20200330/build/device.o CC [M] /var/lib/dkms/wireguard/1.0.20200330/build/peer.o In file included from : /var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:959:20: error: static declaration of ‘icmp_ndo_send’ follows non-static declaration 959 | static inline void icmp_ndo_send(struct sk_buff *skb_in, int type, int code, __be32 info) |^ In file included from : /var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:959:20: error: static declaration of ‘icmp_ndo_send’ follows non-static declaration 959 | static inline void icmp_ndo_send(struct sk_buff *skb_in, int type, int code, __be32 info) |^ In file included from : /var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:959:20: error: static declaration of ‘icmp_ndo_send’ follows non-static declaration 959 | static inline void icmp_ndo_send(struct sk_buff *skb_in, int type, int code, __be32 info) |^ In file included from /var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:954, from : /usr/src/linux-headers-5.5.0-1-common/include/net/icmp.h:47:6: note: previous declaration of ‘icmp_ndo_send’ was here 47 | void icmp_ndo_send(struct sk_buff *skb_in, int type, int code, __be32 info); | ^ In file included from /var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:954, from : /usr/src/linux-headers-5.5.0-1-common/include/net/icmp.h:47:6: note: previous declaration of ‘icmp_ndo_send’ was here 47 | void icmp_ndo_send(struct sk_buff *skb_in, int type, int code, __be32 info); | ^ In file included from /var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:954, from : /usr/src/linux-headers-5.5.0-1-common/include/net/icmp.h:47:6: note: previous declaration of ‘icmp_ndo_send’ was here 47 | void icmp_ndo_send(struct sk_buff *skb_in, int type, int code, __be32 info); | ^ In file included from : /var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:988:20: error: static declaration of ‘icmpv6_ndo_send’ follows non-static declaration 988 | static inline void icmpv6_ndo_send(struct sk_buff *skb_in, u8 type, u8 code, __u32 info) |^~~ In file included from : /var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:988:20: error: static declaration of ‘icmpv6_ndo_send’ follows non-static declaration 988 | static inline void icmpv6_ndo_send(struct sk_buff *skb_in, u8 type, u8 code, __u32 info) |^~~ In file included from : /var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:988:20: error: static declaration of ‘icmpv6_ndo_send’ follows non-static declaration 988 | static inline void icmpv6_ndo_send(struct sk_buff *skb_in, u8 type, u8 code, __u32 info) |^~~ In file included from /var/lib/dkms/wireguard/1.0.20200330/build/compat/compat.h:952, from : /usr/src/linux-headers-5.5.0-1-common/include/linux/icmpv6.h:26:6: note:
Bug#951345: RFS: git-revise/0.5.1-1 -- handy git tool for doing efficient in-memory commit rebases & fixups
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "git-revise" * Package name: git-revise Version : 0.5.1-1 Upstream Author : Nika Layzell * URL : https://mystor.github.io/git-revise.html * License : MIT * Vcs : https://salsa.debian.org/debian/git-revise Section : devel It builds those binary packages: git-revise - handy git tool for doing efficient in-memory commit rebases & fixups To access further information about this package, please visit the following URL: https://mentors.debian.net/package/git-revise Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/git-revise/git-revise_0.5.1-1.dsc Changes since the last upload: * New upstream version 0.5.1 Kind regards, Nicolas
Bug#881098: This is already fixed
Control: fixed -1 0.62-1 On Thu, Feb 06, 2020 at 10:46:57AM -0800, Dima Kogan wrote: > Upstream fixed this in 0.62: > > https://joeyh.name/code/moreutils/news/version_0.62/ > > Nicolas or Matthew: please close this report if you concur. Dima, thanks for your investiation! -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap --
Bug#920118: [PATCH 0/2] moreutils: sponge: (not) attempt to preserve ownership
Control: tag -1 - wontfix Hi Joey, > I don't like complicating the man page with discussion of this. The > man page concisely and correctly documents the actual behavior. > > Varying the behavior based on whether the user is root seems to just be > asking for trouble. > > It does not emulate tee either; a non-root user who can write to a file > they don't own can tee to it and its owner will be preserved; tee simply > opens the file and writes over it. thanks for having a look at it. Your reply matching my initial thoughts about this issue. Kind regards and have a blessed pre-christmas time Nicolas signature.asc Description: PGP signature
Bug#920118: [PATCH 2/2] sponge: preserve ownership if possible (Closes: #920118)
Preserve or restore the ownership of the target output file, if
possible. This converges the behaviour of sponge a little bit more to
the one of 'tee' and shell redirections.
Bug-Debian: https://bugs.debian.org/920118
Signed-off-by: Nicolas Schier
---
sponge.c | 7 +++
sponge.docbook | 7 +++
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/sponge.c b/sponge.c
index f852ad5..59e0a2f 100644
--- a/sponge.c
+++ b/sponge.c
@@ -379,6 +379,13 @@ int main (int argc, char **argv) {
}
copy_tmpfile(tmpfile, outfile, bufstart, bufsize);
}
+
+ /* Attempt to change ownership according to the old file, but
+* ignore errors, as most users will not have the rights to
+* change ownership. */
+ if (exists) {
+ chown(outname, statbuf.st_uid, statbuf.st_gid);
+ }
}
else {
if (tmpfile_used) {
diff --git a/sponge.docbook b/sponge.docbook
index 303d6e6..0b34561 100644
--- a/sponge.docbook
+++ b/sponge.docbook
@@ -66,10 +66,9 @@ USA
sponge preserves the
permissions of the output file
if it already exists. But in contrast to e.g.
- tee, sponge might
- not preserve or restore the original file ownership, no
- matter whether it has been called by a privileged (root)
- user.
+ tee, sponge does
only
+ preserve or restore the original file ownership, if the
current
+ user has the necessary rights.
When possible, sponge creates or
updates the
--
2.24.0
Bug#920118: [PATCH 0/2] moreutils: sponge: (not) attempt to preserve ownership
Hi Joey, in #920118 [1], users of sponge complained about sponge not preserving file ownership of the output file. They argued, that sponge should behave (more) like 'tee' and shell redirections. And they interpreted the sentence "sponge preserves the permissions of the output file if it already exists." from sponge(1) as 'sponge preserves permissions and ownership [...]'. After thinking about it several times, I am still ambiguous; thus, I am sending you two patches: 0001: an attempt to clarify the wording such that is becomes (more) clear that file ownership will not be preserved. and 0002: (might be squashed with 0001) a patch to sponge.c that introduces the attempt to restore the original file ownership opportunistically, neither handling nor even checking for errors. I am really curious about your comments, and whether you'd like to handle the complaints somehow. Looking forward for your reply. Thanks and kind regards, Nicolas [1]: https://bugs.debian.org/920118 Nicolas Schier (2): sponge: mention that ownership might not be preserved (Closes: #920118) sponge: preserve ownership if possible (Closes: #920118) sponge.c | 7 +++ sponge.docbook | 5 - 2 files changed, 11 insertions(+), 1 deletion(-) -- 2.24.0
Bug#920118: [PATCH 1/2] sponge: mention that ownership might not be preserved (Closes: #920118)
Users of sponge pointed out that the wording of sponge's man page caused confusion, as "preserves the permissions" has been interpreted as "preserves the permissions and ownership". Thus, mention that file ownership might not be preserved. Bug-Debian: https://bugs.debian.org/920118 Signed-off-by: Nicolas Schier --- sponge.docbook | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sponge.docbook b/sponge.docbook index 31bc6db..303d6e6 100644 --- a/sponge.docbook +++ b/sponge.docbook @@ -65,7 +65,11 @@ USA sponge preserves the permissions of the output file - if it already exists. + if it already exists. But in contrast to e.g. + tee, sponge might + not preserve or restore the original file ownership, no + matter whether it has been called by a privileged (root) + user. When possible, sponge creates or updates the -- 2.24.0
Bug#944962: git-revise: Forward FHS patch to upstream
Package: git-revise Version: 0.4.2-1 Severity: minor Dear Maintainer, as suggested in RFP #935329, please forward the FHS patch to upstream. -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: arm64 (aarch64) Versions of packages git-revise depends on: ii git 1:2.24.0-1 ii python3 3.7.5-3 git-revise recommends no packages. git-revise suggests no packages. -- no debconf information
Bug#944960: git-revise: Split-out docbase documentation in a separate package
Package: git-revise Version: 0.4.2-1 Severity: normal Dear Maintainer, as suggested in RFP #935329, the documentation should be build properly for docbase integration, split-out into in a separate package. -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: arm64 (aarch64) Versions of packages git-revise depends on: ii git 1:2.24.0-1 ii python3 3.7.5-3 git-revise recommends no packages. git-revise suggests no packages. -- no debconf information
Bug#944957: git-revise's test suite is not run by autopkgtest
Package: git-revise Version: 0.4.2-1 Severity: minor git-revise's test suite is not run by autopkgtest during package build. -- System Information: Debian Release: bullseye/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: arm64 (aarch64) Versions of packages git-revise depends on: ii git 1:2.24.0-1 ii python3 3.7.5-3 git-revise recommends no packages. git-revise suggests no packages. -- no debconf information
Bug#944910: i3pystatus: man page refers to non-existing info manual
Package: i3pystatus Version: 3.35+git20190107.1c972b8-2 Severity: minor Dear Maintainer, the i3pystatus(1) man page refers to `info i3pystatus`, but there is no info manual. Re-running help2man with the '--no-info' should be enough to fix it. Kind regards, Nicolas
Bug#920118: sponge: preverses permissions but not ownership
Control: retitle -1 sponge: preserves permissions but not ownership Control: severity -1 normal Control: tag -1 - wontfix On Tue, Oct 01, 2019 at 07:27:57PM +, Andy Smith wrote: > Hi, > > On Thu, Apr 18, 2019 at 10:42:54PM +0200, Nicolas Schier wrote: > > Why do you think that sponge ought to preserve the owner? Did the man > > page induce that somehow? > > I was caught out by this just now, and got as far as "bugreport > moreutils" before I found this existing bug. > > When I read "preserves permissions" in the man page, my brain just > went on auto-pilot and assumed this meant ownership as well. I think > this is encouraged along by a common use-case of sponge as a > replacement for IO redirection, which as Hamish already noted does > preserve ownership. Thanks for pointing that out. Personally, I think that the man page is actually correct, as 'permissions' does not include 'ownership' (from the technical point of view), but I understand that this may be confusing for others. > I appreciate there is room for difference of opinion here over what > behaviour is surprising or not, but I don't think it is just Hamish > and I who would get surprised. So if preserving ownership is > considered not the job of sponge then perhaps this could be called > out in the man page near where it currently says that permissions > are preserved? I think I'm going to prepare a patch, clarifying the wording of the man page. I can also ask Joey (upstream author) for commenting on the differences of expected behaviour, but I am expecting that preserving ownership will not become a feature of 'sponge'. Thanks for your reports! Kind regards, Nicolas
Bug#935329: RFP: git-revise -- handy git tool for doing efficient in-memory commit rebases & fixups
Hi Antoine, > [...] > Could you hook up the test suite in autopkgtest somehow? I prepared a debian/tests/control, but upstream's test suite does not successfully run on any of my Debian machines, neither when I run 'tox' (as suggested in docs/contributing.rst), nor if I call pytest-3 directly. I contacted upstream, but did not yet get a reply. Thus, I'd like to defer enabling the autopkgtest stuff. > The docbase stuff is usually in HTML, and to make it work you'd need to > build it with the Sphinx package, I think. It would be better to split > that out in a separate -doc package. Sounds reasonable to me. I put it on my todo list. > Why did you mark the FHS patch as not needing forward? It would seem > like a useful contribution for upstream... Changed the mark to 'no' and am planning to forward soon. > All this can be done in a future incantation though. > > The stuff on mentors still has an empty postrm script, so it looks like > it's not exactly the same state as the merge request... > > python-git-revise-doc.docs refers to two non-existent files, so that > should definitely be fixed. It would be strange to have README.source > shipped, btw. And README.Debian doesn't need to be in the -doc package. thanks! I didn't see that. The .docs file is now removed. > For the (build-)depends, you might want to split lines on commas to make > future diffs smaller. You can also build-dep on debhelper-compat to pin > an exact version, which also removes the need for the extra > debian/compat file. Thanks for the pointers, done. > Did you audit or review the upstream source? Finally, yes. I read completely through the git-revise code (but not the test suite, yet). I uploaded the new version to mentors [1] and this time the sources should be equivalent to the ones in https://salsa.debian.org/debian/git-revise -b debian/sid with the exception of the actual changelog-Release commit (that is only in https://salsa.debian.org/nsc-guest/git-revise). As soon as the package is uploaded one day, I will create these bugs: - Use upstream's test suite for autopkgtest - split-out a git-revise-doc package with HTML docs and proper docbase integration Can you please have a look at the upload, once again? Thanks and kind regards, Nicolas [1]: https://mentors.debian.net/package/git-revise -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#935329: RFP: git-revise -- handy git tool for doing efficient in-memory commit rebases & fixups
> On 2019-09-05 18:38:09, Nicolas Schier wrote: > > Dear Antoine, > > > >> > Antoine, could you create a repository in salsa's 'debian' > >> > namespace? > >> > (My salsa account is 'nsc-guest'). > >> > >> Done: https://salsa.debian.org/debian/git-revise > > > > thanks for your fast reaction! > > Right now, I do not have any permissions than to create merge requests > > for debian/git-revise. > > Really? You seem to have created one here: > > https://salsa.debian.org/debian/git-revise/merge_requests/1 > > I merged it after review. > > > I'd like to have the CI stuff enabled (with 'debian/gitlab.yml' > > instead of '.gitlab.yml'), that the usual test suites can also run on > > the new official repo. Can you please enable that (or give me the > > permissions for doing that)? > > I added you as a developer. Thanks! > >> > Would you be available as a sponsor (as soon as I have got rid of all > >> > lintian issues)? > >> > >> Sure! > > > > great! I uploaded the package to mentors: > > > > https://mentors.debian.net/package/git-revise > > > > (same state as in the Pull-Request). > > > > Could you have a look at it? > > (I am not sure, if I did the doc-base stuff correctly...) > > Could you hook up the test suite in autopkgtest somehow? > > The docbase stuff is usually in HTML, and to make it work you'd need to > build it with the Sphinx package, I think. It would be better to split > that out in a separate -doc package. > > Why did you mark the FHS patch as not needing forward? It would seem > like a useful contribution for upstream... > > All this can be done in a future incantation though. > > The stuff on mentors still has an empty postrm script, so it looks like > it's not exactly the same state as the merge request... > > python-git-revise-doc.docs refers to two non-existent files, so that > should definitely be fixed. It would be strange to have README.source > shipped, btw. And README.Debian doesn't need to be in the -doc package. > > For the (build-)depends, you might want to split lines on commas to make > future diffs smaller. You can also build-dep on debhelper-compat to pin > an exact version, which also removes the need for the extra > debian/compat file. > > Did you audit or review the upstream source? Thanks a lot for your detailed and criticial review. It seems I have been a bit too sloppily ... give me some days to handle your points. Kind regards, Nicolas -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#935329: RFP: git-revise -- handy git tool for doing efficient in-memory commit rebases & fixups
Dear Antoine, > > Antoine, could you create a repository in salsa's 'debian' > > namespace? > > (My salsa account is 'nsc-guest'). > > Done: https://salsa.debian.org/debian/git-revise thanks for your fast reaction! Right now, I do not have any permissions than to create merge requests for debian/git-revise. I'd like to have the CI stuff enabled (with 'debian/gitlab.yml' instead of '.gitlab.yml'), that the usual test suites can also run on the new official repo. Can you please enable that (or give me the permissions for doing that)? > > Would you be available as a sponsor (as soon as I have got rid of all > > lintian issues)? > > Sure! great! I uploaded the package to mentors: https://mentors.debian.net/package/git-revise (same state as in the Pull-Request). Could you have a look at it? (I am not sure, if I did the doc-base stuff correctly...) Thanks and kind regards, Nicolas -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#935329: RFP: git-revise -- handy git tool for doing efficient in-memory commit rebases & fixups
Control: retitle -1 ITP: git-revise -- handy git tool for doing efficient in-memory Control: owner -1 nico...@fjasle.eu Hei, I have started packaging git-revise [1], would like to take over the package maintainance and already got an warm ack from upstream for Debian packaging. Right now I am just targetting on providing a usable 'git-revise' package; for seperating the python library into a seperate package I would wait until a corresponding bug is filed. Antoine, could you create a repository in salsa's 'debian' namespace? (My salsa account is 'nsc-guest'). Would you be available as a sponsor (as soon as I have got rid of all lintian issues)? Thanks and kind regards, Nicolas [1]: https://salsa.debian.org/nsc-guest/git-revise -b debian/sid
Bug#932774: ircd-hybrid: Segfault in libgmp.so.10.3.2
> after upgrading a host from Stretch to Buster, ircd-hybrid fails to > start: Same for me. I could made it work again by running certtool --generate-dh-params --sec-param=medium --outfile /etc/ircd-hybrid/dhparam.pem and enabling the corresponding config line in /etc/ircd-hybrid/ircd.conf: ssl_dh_param_file = "/etc/ircd-hybrid/dhparam.pem"; . Do you have a dhparam.pem file, and enabled the config setting? Kind regards, Nicolas
Bug#930803: new program: runcached
tags -1 + moreinfo thanks Hi András, > I just wrote this script: > https://gist.github.com/akorn/51ee2fe7d36fa139723c851d87e56096 and thought > it might be a good addition to moreutils. > > It caches the stdout, stderr and exit status of arbitrary commands for a > configurable length of time, returning data from cache on subsequent > invocations if the cache is still fresh. thanks for your suggestion; I think it's quite an interesting idea! And you made me curious: which commands are you running through 'runcached'? All programs I thought of have their basic functionality based on side-effects as file system or network access. > It currently has semi-esoteric dependencies: it's written in zsh and uses > chpst from the runit package for locking. If you're willing to include the > script I can change it to use flock(1) instead, but I'm not rewriting it in > POSIX sh. Adding new scripts to the moreutils collection is usually done by forwarding to the upstream maintainer (Joey Hess ) and asking for script inclusion. But, as Joey keeps more than just one eye on cross platform compatibility, I expect non-POSIX implementations to be rejected. Do you keep your non-POSIX statement? Did you think about the license you want to stick it to? GPL2+? Kind regards, Nicolas -- epost: nico...@fjasle.eu irc://oftc.net/nsc ↳ gpg: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#920118: sponge: preverses permissions but not ownership
Control: severity -1 wishlist Control: tag -1 wontfix On Tue, Jan 22, 2019 at 09:40:20AM +1100, Hamish Moffatt wrote: > [...] > sponge preserves file permissions (as mentioned in the man page), but > not the file ownership. > > This is different from shell redirections in bash, which do preserve > ownership. yes, you're right. As 'sponge' is not a shell redirect, and it is not designed to emulate one, it behaves more like 'tee' than like a shell redirection. I do understand that preserving the owner might be a nice feature, but I think this could work well only if 'sponge' is called with superuser capabilities (or if installed with suid-bit set). Why do you think that sponge ought to preserve the owner? Did the man page induce that somehow? Kind regards, Nicolas signature.asc Description: PGP signature
Bug#927337: uzbl: Please update to a to current upstream version
Package: uzbl Version: 0.0.0~git.20120514-1.2 Severity: normal Dear Maintainer, the current Debian version of uzbl is quite old. Can you please update uzbl to a more current version? On https://github.com/uzbl/uzbl there is a tag 'v0.9.1' available, but probably the 'master' or 'next' branch could also make sense... Thanks and kind regards, Nicolas
Bug#922606: suckless-tools: not installable on kfreebsd
package: suckless-tools
severity: normal
version: 44-1
tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
suckless-tools is currently (44-2) not installable on kfreebsd, as
libcap2-bin is not available for that port. Please mark libcap2-bin as
'Recommends' for kfreebsd, as this would solve the problem; the
debian/postinst script is already capable of not-failing due to a
missing 'setcap' binary.
The attached patch works for me.
Thanks and kind regards,
Nicolas
From 1a023beef44619f32c2c78eb6e4115d257ea96b9 Mon Sep 17 00:00:00 2001
From: Nicolas Schier
Date: Mon, 18 Feb 2019 11:01:59 +0100
Subject: [PATCH] Change dependency for libcap2-bin to 'Recommends' for
kFreeBSD
Signed-off-by: Nicolas Schier
---
debian/changelog | 1 +
debian/control | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index 146e859..07a26f8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,7 @@
suckless-tools (44-2) UNRELEASED; urgency=medium
* d/changelog: Remove trailing whitespaces
+ * Change dependency for libcap2-bin to 'Recommends' for kFreeBSD
-- Ondřej Nový Mon, 01 Oct 2018 09:50:03 +0200
diff --git a/debian/control b/debian/control
index 8aa3395..6b52e16 100644
--- a/debian/control
+++ b/debian/control
@@ -20,7 +20,8 @@ Vcs-Browser: https://salsa.debian.org/debian/suckless-tools
Package: suckless-tools
Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, libcap2-bin
+Depends: ${misc:Depends}, ${shlibs:Depends}, libcap2-bin [linux-any]
+Recommends: libcap2-bin [!linux-any]
Suggests: dwm, stterm, surf
Provides: dmenu, lsw, slock, sprop, sselp, ssid, swarp, tabbed, wmname, xssstate
Description: simple commands for minimalistic window managers
--
2.5.1
signature.asc
Description: PGP signature
Bug#921777: bugwarrior: FTBFS (failing tests)
tag 921777 + patch
usertag 921777 + bsp-2019-02-de-berlin
thank you
Hei,
> I tried to build this package in buster but it failed:
> [...]
> pkg_resources.VersionConflict: (future 0.16.0
> (/usr/lib/python3/dist-packages), Requirement.parse('future!=0.16.0'))
the build dependency ('future!=0.16.0') is explicitly given in
setup.py, originating from the latest upstream import.
When removing the problematic line (cp. attached patch), it seems to
build and run the tests again. Is this line really still required?
Kind regards,
Nicolas
From 8425df9da9b02151e31b8ea1bf5da5df73b907a2 Mon Sep 17 00:00:00 2001
From: Nicolas Schier
Date: Sat, 9 Feb 2019 12:32:38 +0100
Subject: [PATCH] setup.py: Remove future!=0.16.0 dependency (Closes: #921777)
The 'future!=0.16.0' dependency prevents building the package on buster.
There seems to be no reason for this dependency (anymore)?
---
setup.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/setup.py b/setup.py
index c2ad788..5246ff1 100644
--- a/setup.py
+++ b/setup.py
@@ -38,7 +38,6 @@ setup(name='bugwarrior',
"dogpile.cache>=0.5.3",
"lockfile>=0.9.1",
"click",
- "future!=0.16.0",
],
extras_require=dict(
keyring=["keyring"],
--
2.20.1
signature.asc
Description: PGP signature
Bug#825309: Update
Hei, > I just hit this issue. Can we please fix this? Do you need a patch? sorry for the long response time. Will be fixed with the soon coming 0.63-1 version. Kind regards Nicolas -- epost: nico...@fjasle.eu gpg key: 7d970932 55a0ce7f ↳ fpr: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#913880: ITP: overlay-userns -- Overlay mounting in user namespaces (DKMS)
> > > Why don't you talk to the kernel team about adding a module > > > parameter > > > enable this, rather than packaging a fragile hack? > > > > thanks for the pointer. Do you think about something like the > > attached patch? Would you recommend a post in debian-kernel@l.d.o > > about it or better a salsa merge request? > > I'd prefer a merge request. please see https://salsa.debian.org/kernel-team/linux/merge_requests/73 thanks and kind regards Nicolas -- epost: nico...@fjasle.eu gpg key: 7d970932 55a0ce7f ↳ fpr: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#913880: ITP: overlay-userns -- Overlay mounting in user namespaces (DKMS)
Dear Ben,
> Why don't you talk to the kernel team about adding a module parameter
> enable this, rather than packaging a fragile hack?
thanks for the pointer. Do you think about something like the attached
patch? Would you recommend a post in debian-kernel@l.d.o about it or
better a salsa merge request?
Kind regards,
Nicolas
From 8e09f86b72903c29bff005425bee997fa9521147 Mon Sep 17 00:00:00 2001
From: Nicolas Schier
Date: Mon, 19 Nov 2018 21:16:26 +0100
Subject: [PATCH] ovl: permit overlayfs mounts in user namespaces (taints
kernel)
Permit overlayfs mounts within user namespaces to allow utilisation of e.g.
unprivileged LXC overlay snapshots.
Except by the Ubuntu community [1], overlayfs mounts in user namespaces are
expected to be a security risk [2] and thus are not enabled on upstream Linux
kernels. For the non-Ubuntu users that have to stick to unprivileged
overlay-based LXCs, this meant to patch and compile the kernel manually.
Instead, adding the kernel tainting 'permit_mounts_in_userns' module parameter
allows a kind of a user-friendly way to enable the feature.
Testable with:
sudo modprobe overlay permit_mounts_in_userns=1
sudo sysctl -w kernel.unprivileged_userns_clone=1
mkdir -p lower upper work mnt
unshare --map-root-user --mount \
mount -t overlay none mnt -o lowerdir=lower,upperdir=upper,workdir=work
[1]: Ubuntu allows unprivileged mounting of overlay filesystem
https://lists.ubuntu.com/archives/kernel-team/2014-February/038091.html
[2]: User namespaces + overlayfs = root privileges
https://lwn.net/Articles/671641/
Signed-off-by: Nicolas Schier
---
.../overlayfs-permit-mounts-in-userns.patch | 55 +++
debian/patches/series | 3 +
2 files changed, 58 insertions(+)
create mode 100644 debian/patches/debian/overlayfs-permit-mounts-in-userns.patch
diff --git a/debian/patches/debian/overlayfs-permit-mounts-in-userns.patch b/debian/patches/debian/overlayfs-permit-mounts-in-userns.patch
new file mode 100644
index ..3697d8cf7708
--- /dev/null
+++ b/debian/patches/debian/overlayfs-permit-mounts-in-userns.patch
@@ -0,0 +1,55 @@
+From: Nicolas Schier
+Subject: ovl: permit overlayfs mounts in user namespaces (taints kernel)
+Date: Mon, 19 Nov 2018 20:36:14 +0100
+
+Permit overlayfs mounts within user namespaces to allow utilisation of e.g.
+unprivileged LXC overlay snapshots.
+
+Except by the Ubuntu community [1], overlayfs mounts in user namespaces are
+expected to be a security risk [2] and thus are not enabled on upstream Linux
+kernels. For the non-Ubuntu users that have to stick to unprivileged
+overlay-based LXCs, this meant to patch and compile the kernel manually.
+Instead, adding the kernel tainting 'permit_mounts_in_userns' module parameter
+allows a kind of a user-friendly way to enable the feature.
+
+Testable with:
+
+sudo modprobe overlay permit_mounts_in_userns=1
+sudo sysctl -w kernel.unprivileged_userns_clone=1
+mkdir -p lower upper work mnt
+unshare --map-root-user --mount \
+mount -t overlay none mnt -o lowerdir=lower,upperdir=upper,workdir=work
+
+[1]: Ubuntu allows unprivileged mounting of overlay filesystem
+ https://lists.ubuntu.com/archives/kernel-team/2014-February/038091.html
+
+[2]: User namespaces + overlayfs = root privileges
+ https://lwn.net/Articles/671641/
+
+--- a/fs/overlayfs/super.c
b/fs/overlayfs/super.c
+@@ -56,6 +56,12 @@
+ MODULE_PARM_DESC(ovl_xino_auto_def,
+ "Auto enable xino feature");
+
++static bool ovl_permit_mounts_in_userns;
++module_param_named_unsafe(permit_mounts_in_userns, ovl_permit_mounts_in_userns,
++ bool, 0444);
++MODULE_PARM_DESC(ovl_permit_mounts_in_userns,
++ "Permit mounts in user namespaces");
++
+ static void ovl_entry_stack_free(struct ovl_entry *oe)
+ {
+ unsigned int i;
+@@ -1545,6 +1551,11 @@
+ if (ovl_inode_cachep == NULL)
+ return -ENOMEM;
+
++ if (unlikely(ovl_permit_mounts_in_userns)) {
++ pr_warn("Allowing overlay mounts in user namespaces bears security risks\n");
++ ovl_fs_type.fs_flags |= FS_USERNS_MOUNT;
++ }
++
+ err = register_filesystem(_fs_type);
+ if (err)
+ kmem_cache_destroy(ovl_inode_cachep);
diff --git a/debian/patches/series b/debian/patches/series
index 57872c847500..2f45ed47d44a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -152,4 +152,7 @@ bugfix/x86/tools-turbostat-Add-checks-for-failure-of-fgets-and-.patch
# wireless: Disable regulatory.db direct loading (until we sort out signing)
debian/wireless-disable-regulatory.db-direct-loading.patch
+# overlay: allow mounting in user namespaces
+debian/overlayfs-permit-mounts-in-userns.patch
+
# ABI maintenance
--
2.19.1
signature.asc
Description: PGP signature
Bug#913880: ITP: overlay-userns -- Overlay mounting in user namespaces (DKMS)
Package: wnpp Severity: wishlist Owner: Nicolas Schier * Package name: overlay-userns Version : 0.4 Upstream Author : Nicolas Schier * URL : https://rocketgit.com/user/nicolas/overlay-userns-dkms * License : GPL Programming Lang: C Description : Overlay mounting in user namespaces (DKMS) This DKMS package enables overlay file system mounts within user namespaces. Please be aware that this induces a security risk and thus cannot be recommended in general. Overlay file system is considered to be a security risk when it would be allowed to be used within user namespaces. The utilisation of unprivileged Linux containers in combination with overlay-based snapshotting is thus not possible by default. The 'lxc' provides unpriviledged LXC snapshot support by using overlay within user namespaces, which is currently only enabled in Ubuntu Linux kernels. When unpriviledged overlay LXCs are required on Debian systems, this package provides an alternative to a manually patched and built Linux kernel. Personally, I use that DKMS module at work, as I have to stick to unpriviledged LXCs but still would like to run a Debian kernel rather than a manually patched and updated one. I know that patching the runtime kernel is quite dirty, and I am expecting that this technique is not possible in the far future, but right now (and since the last two years) it worked quite fine on a few machines. As I am not an official Debian Maintainer, I do need a sponsor for the package. I am going to push the Debian stuff into a personal salsa repository (nsc-guest/overlay-userns); iff the package gets sponsored, moving to an official Debian salsa repo would be great. Kind regards, Nicolas
Bug#913879: u-boot-sunxi: please add dependency on u-boot-tools
Package: u-boot-sunxi Version: 2018.11+dfsg-1 Severity: normal Dear Vagrant, can you please add 'u-boot-tools' as dependency for u-boot-sunxi: /usr/bin/u-boot-install-sunxi64: 59: /usr/bin/u-boot-install-sunxi64: mkimage: not found Thanks for all your efforts and kind regards, Nicolas -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: arm64 (aarch64) Kernel: Linux 3.10.105-bsp-1.2-ayufan-77 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.UTF-8), LANGUAGE=nb:nn:se:dk:de:C (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) u-boot-sunxi depends on no packages. Versions of packages u-boot-sunxi recommends: ii atf-allwinner 1.0.aw-6-1 u-boot-sunxi suggests no packages. -- no debconf information
Bug#912808: RFS: sleepenh/1.7-1 -- sleep until a given date with subsecond resolution
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "sleepenh" * Package name: sleepenh Version : 1.7-1 Upstream Author : Nicolas Schier * URL : https://rocketgit.com/user/nicolas/sleepenh * License : GPL-2.0+ Section : utils It builds those binary packages: sleepenh - Sleep until a given date with subsecond resolution To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sleepenh Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sleepenh/sleepenh_1.7-1.dsc Changes since the last upload: * Import upstream version 1.7 * Purge obsolete Debian patch * Update maintainer email address * Update Vcs-* and remove obsolete Homepage URIs (Closes: #911267), thanks to Micha Lenk for reporting and repo migration to salsa * Update Priority from extra to optional * debian/copyright: update source URI * debian/copyright: update upstream email address * Update package description * debian/copyright: use https scheme for copyright format URI * debian/rules: enable hardening build flags * Bump standards version to 4.2.1 * Update debhelper compat level to 11 Thanks in advance and kind regards, Nicolas
Bug#912537: gitlab-cli: Please add (a pointer to) documentation about necessary initial configuration
Package: gitlab-cli
Version: 1:1.6.0-1
Severity: minor
Dear maintainer,
I installed the 'gitlab' package and expected to find some documentation
about how to set up a valid '~/.python-gitlab.cfg', but I couldn't find
anything about it.
Thus, starting 'gitlab' leads for me to:
$ gitlab
Traceback (most recent call last):
File "/usr/lib/python3.6/configparser.py", line 1138, in _unify_values
sectiondict = self._sections[section]
KeyError: 'global'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gitlab/config.py", line 49, in
__init__
self.gitlab_id = self._config.get('global', 'default')
File "/usr/lib/python3.6/configparser.py", line 781, in get
d = self._unify_values(section, vars)
File "/usr/lib/python3.6/configparser.py", line 1141, in _unify_values
raise NoSectionError(section)
configparser.NoSectionError: No section: 'global'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/gitlab", line 11, in
load_entry_point('python-gitlab==1.6.0', 'console_scripts',
'gitlab')()
File "/usr/lib/python3/dist-packages/gitlab/cli.py", line 144, in main
options.config_file)
File "/usr/lib/python3/dist-packages/gitlab/config.py", line 51, in
__init__
raise GitlabIDError("Impossible to get the gitlab id "
gitlab.config.GitlabIDError: Impossible to get the gitlab id (not
specified in config file)
Can you please add some (pointers to) documentation about the required initial
configuration?
Thanks and kind regards,
Nicolas
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'oldoldstable'), (500, 'unstable'), (500,
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=nb:nn:dk:se:de:en:C, LC_CTYPE=nb:nn:dk:se:de:en:C (charmap=UTF-8)
(ignored: LC_ALL set to nb_NO.UTF-8), LANGUAGE=nb_NO.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to nb_NO.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gitlab-cli depends on:
ii python3 3.6.5-3
ii python3-gitlab 1:1.6.0-1
gitlab-cli recommends no packages.
gitlab-cli suggests no packages.
-- no debconf information
Bug#886383: bugwarrior: phabricator import fails due to no issues found (= undefined 'issue' dict)
Package: bugwarrior
Version: 1.5.1-2
Severity: normal
Tags: patch
Dear maintainer(s),
I have added these lines to my ~/.config/bugwarrior/bugwarriorrc
attempting to import my issues from our phabricator instance (even
though I still not have any):
[phabricator]
phabricator.only_if_assigned = PHID-USER-7yut3lpslyc2mmm5mxuj,NSchier
phabricator.user_phids = PHID-USER-7yut3lpslyc2mmm5mxuj
#phabricator.project_phids = PHID-PROJ-wak4hlhspgyjxgx4ibsg
service = phabricator
(The 'project_phids' setting is disabled, as the local installation does
not provide the required API (that could make up yet another bug report,
as the error is not catched).)
When running 'bugwarrior-pull', I get this output:
$ bugwarrior-pull --dry-run
INFO:bugwarrior.db:Service-defined UDAs exist: you can optionally use
the `bugwarrior-uda` command to export a list of UDAs you can add to your
taskrc file.
INFO:bugwarrior.services:Starting to aggregate remote issues.
INFO:bugwarrior.services:Spawning 1 workers.
INFO:bugwarrior.services:Working on [phabricator]
INFO:bugwarrior.services.phab:Found 0 issues
INFO:bugwarrior.services.phab:Found 39 differentials
ERROR:bugwarrior.services:Worker for [phabricator] failed: local
variable 'issue' referenced before assignment
Traceback (most recent call last):
File
"/usr/lib/python3/dist-packages/bugwarrior/services/__init__.py", line 506, in
_aggregate_issues
for issue in service.issues():
File "/usr/lib/python3/dist-packages/bugwarrior/services/phab.py",
line 147, in issues
project = projects.get(issue['projectPHIDs'][0], project)
UnboundLocalError: local variable 'issue' referenced before assignment
INFO:bugwarrior.services:Done with [phabricator] in 0.116974s
INFO:bugwarrior.services:Terminating workers
'type': 'issue',
CRITICAL:bugwarrior.command:Aborted (critical error in target
'phabricator')
Without really knowing what I'm doing, I simply patched the
'bugwarrior/services/phab.py' and can now import the stuff I want to
have:
$ bugwarrior-pull
INFO:bugwarrior.db:Service-defined UDAs exist: you can optionally use
the `bugwarrior-uda` command to export a list of UDAs you can add to your
taskrc file.
INFO:bugwarrior.services:Starting to aggregate remote issues.
INFO:bugwarrior.services:Spawning 1 workers.
INFO:bugwarrior.services:Working on [phabricator]
INFO:bugwarrior.services.phab:Found 0 issues
INFO:bugwarrior.services.phab:Found 39 differentials
INFO:bugwarrior.services:Done with [phabricator] in 0.119559s
INFO:bugwarrior.services:Done aggregating remote issues.
INFO:bugwarrior.db:Adding 2 tasks
INFO:bugwarrior.db:Adding task (bw)PR#D3625 - ARM: etc/scripts/p...
INFO:bugwarrior.db:Adding task (bw)PR#D3448 - Reduce compilation
warnings
INFO:bugwarrior.db:Updating 0 tasks
INFO:bugwarrior.db:Closing 0 tasks
I don't know, if the patch breaks something, when there are issues
found... but for me it works with that patch, currently.
Kind regards,
Nicolas
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'oldoldstable'), (500, 'unstable'), (500,
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=nb:nn:dk:se:de:en:C, LC_CTYPE=nb:nn:dk:se:de:en:C (charmap=UTF-8)
(ignored: LC_ALL set to nb_NO.UTF-8), LANGUAGE=nb_NO.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to nb_NO.UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bugwarrior depends on:
ii libjs-sphinxdoc1.6.5-4
ii python33.6.4-1
ii python3-click 6.7-2
ii python3-dateutil 2.6.1-1
ii python3-dogpile.cache 0.6.2-5
ii python3-future 0.15.2-4
ii python3-jinja2 2.10-1
ii python3-lockfile 1:0.12.2-2
ii python3-requests 2.18.1-1
ii python3-six1.11.0-1
ii python3-taskw 1.2.0-1
ii python3-tz 2017.2-2
Versions of packages bugwarrior recommends:
ii python3-keyring 10.5.1-1
ii python3-phabricator 0.7.0-1
bugwarrior suggests no packages.
-- no debconf information
diff --git a/bugwarrior/services/phab.py b/bugwarrior/services/phab.py
index 37155fa..bca942d 100644
--- a/bugwarrior/services/phab.py
+++ b/bugwarrior/services/phab.py
@@ -97,6 +97,7 @@ class PhabricatorService(IssueService):
log.info("Found %i issues" % len(issues))
+issue = {'projectPHIDs': []}
for phid, issue in issues:
project = self.target # a sensible default
Bug#867167: chronic: document return value semantics of -e option
tags 867167 + patch thanks
Bug#718816: moreutils: split parallel binary in extra package
Dear Mika, > With the upload of parallel 20161222-1 > (https://tracker.debian.org/news/828794) there seems to be a nice > solution to have parallel and moreutils installed at the same time: thanks for the pointer. I don't like that kind of "solution", but as moreutils and parallel are now installable at the same time, it is time to close this one. Kind regards, Nicolas signature.asc Description: Digital signature
Bug#848578: /usr/bin/ts: charset issue with ts and localization
Dear Yves-Alexis, > LANG=fr_FR.utf8 > LC_TIME="fr_FR.utf8" > LC_MESSAGES=en_US.UTF-8 > LC_ALL= > > > When running ts, I have: > > echo toto |ts > d�c. 18 15:57:51 toto I am trying to reproduce this issue on my system, but I am (yet) not able to get it. Can you please try to help me? * I enabled 'fr_FR.UTF-8' and 'en_US.UTF-8' in /etc/locale.gen and ran 'dpkg-reconfigure -p high locales'. * I reset my locale related environment variables in this order: export LC_ALL= LANG= then I start a new terminal with these settings, thus, 'locale' in the new terminal shows 'POSIX' to all LC_* variables. Then I issue export LC_ALL= export LANG=fr_FR.utf8 export LC_TIME="fr_FR.utf8" export LC_MESSAGES=en_US.UTF-8 and the 'locale' output is almost as expected: LANG=fr_FR.utf8 LANGUAGE= LC_CTYPE="fr_FR.utf8" LC_NUMERIC="fr_FR.utf8" LC_TIME=fr_FR.utf8 LC_COLLATE="fr_FR.utf8" LC_MONETARY="fr_FR.utf8" LC_MESSAGES=en_US.UTF-8 LC_PAPER="fr_FR.utf8" LC_NAME="fr_FR.utf8" LC_ADDRESS="fr_FR.utf8" LC_TELEPHONE="fr_FR.utf8" LC_MEASUREMENT="fr_FR.utf8" LC_IDENTIFICATION="fr_FR.utf8" LC_ALL= * Running 'date', it seems to show the behaviour you described: vendredi 23 décembre 2016, 05:25:47 (UTC+0100) but with 'ts' it seems to be correct to me: $ echo bicycle repair man | ts déc. 23 05:26:07 bicycle repair man An interesting point to me: when I am starting from my usual locale settings (LANG=de_DE.UTF-8, LC_ALL=nb_NO.UTF.8) and then set the specific values as written above, I get the same 'locale' output but $ date | ts déc. 23 05:32:11 vendredi 23 décembre 2016, 05:32:11 (UTC+0100) seems to ok. So, since 'ts' always shows me the correct output, I am not yet able to reproduce your issue; but am confused about 'date' behaving as you wrote about 'ts'... Kind regards, Nicolas -- gpg key id: 55a0ce7f, epost: nicolas@(fjasle.eu|hjem.rpa.no) ↳ fpr: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
Bug#697052: moreutils: 'pee' with 'echo' buggy.
Dear Ole,
> I'm quite sure the issue is that 'echo' close the stream immediately,
> causing a SIGPIPE that kills the pee process.
>
> [...]
>
> I'm sure there are cases where one wants the SIGPIPE to abort the
> rest of pipes, but there should at least be an option to ignore it.
thanks for your valueable pointers! Reading pipe(7) confirms your
statement about SIGPIPE. If there wasn't the backward-compatibility
issue, I would like to see 'pee' to always ignore SIGPIPE and write
errors to pipes.
I am going to forward a patch suggestion to Joey (upstream).
Kind regards,
Nicolas
From 5dbbbee5d1e2cccf1d1ed9920459cde6254512e8 Mon Sep 17 00:00:00 2001
From: Nicolas Schier <n.sch...@avm.de>
Date: Tue, 20 Dec 2016 08:03:24 +0100
Subject: [PATCH v1] pee: ignore SIGPIPE and write errors (Closes: #697052)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Without ignoring SIGPIPE, any command run by 'pee' that exists early
will close the pipe to 'pee' and thus cause a SIGPIPE that terminates
'pee'. The more convinient (and possible less surprising) way is
probably to simply ignore the SIGPIPE and let all other commands issued
by 'pee' continue without any harm.
The same argumentation goes for ignoring write errors, as any early
exiting child of 'pee' is closing the pipe and thus causing a write
error.
With this patch examples like
seq 10 | pee 'head -n1' 'tail -n1'
echo foo | pee cat 'echo bar' cat cat
do output the expected to lines.
Thanks to Ole Jørgen Brønner.
Signed-off-by: Nicolas Schier <n.sch...@avm.de>
---
pee.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/pee.c b/pee.c
index a8565c0..fe312d2 100644
--- a/pee.c
+++ b/pee.c
@@ -30,10 +30,18 @@ int
main(int argc, char **argv) {
size_t i, r;
FILE **pipes;
+ int *inactive_pipe;
+ int inactive_pipes = 0;
char buf[BUFSIZ];
+ if ((signal(SIGPIPE, SIG_IGN) == SIG_ERR)) {
+ fprintf(stderr, "Unable to ignore SIGPIPE\n");
+ exit(EXIT_FAILURE);
+ }
+
pipes = malloc(((argc - 1) * sizeof *pipes));
- if (!pipes)
+ inactive_pipe = calloc((argc - 1), (sizeof *inactive_pipe));
+ if (!pipes || !inactive_pipe)
exit(EXIT_FAILURE);
for (i = 1; i < argc; i++) {
@@ -50,11 +58,18 @@ main(int argc, char **argv) {
while(!feof(stdin) && (!ferror(stdin))) {
r = fread(buf, sizeof(char), BUFSIZ, stdin);
for(i = 0; i < argc; i++) {
- if (fwrite(buf, sizeof(char), r, pipes[i]) != r) {
-fprintf(stderr, "Write error to `%s\'\n", argv[i + 1]);
+ if (inactive_pipe[i])
+continue;
+
+ if (fwrite(buf, sizeof(char), r, pipes[i]) == r)
+continue;
+
+ if (++inactive_pipes == argc) {
close_pipes(pipes, argc);
exit(EXIT_FAILURE);
}
+
+ inactive_pipe[i] = 1;
}
}
exit(close_pipes(pipes, argc));
--
2.10.2
From 1bee9b1ec034fa2d12a02517fad1a6b2dafbe9d5 Mon Sep 17 00:00:00 2001
From: Nicolas Schier <n.sch...@avm.de>
Date: Tue, 20 Dec 2016 08:03:24 +0100
Subject: [PATCH v2] pee: ignore SIGPIPE and write errors (Closes: #697052)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Without ignoring SIGPIPE, any command run by 'pee' that exists early
will close the pipe to 'pee' and thus cause a SIGPIPE that terminates
'pee'. The more convinient (and possible less surprising) way is
probably to simply ignore the SIGPIPE and let all other commands issued
by 'pee' continue without any harm.
The same argumentation goes for ignoring write errors, as any early
exiting child of 'pee' is closing the pipe and thus causing a write
error.
With this patch examples like
seq 10 | pee 'head -n1' 'tail -n1'
echo foo | pee cat 'echo bar' cat cat
do output the expected to lines, in contrast to
seq 10 | pee --no-ignore-sigpipe --no-ignore-write-errors 'head -n1' 'tail -n1'
echo foo | pee --no-ignore-sigpipe --no-ignore-write-errors cat 'echo bar' cat cat
.
Thanks to Ole Jørgen Brønner.
Signed-off-by: Nicolas Schier <n.sch...@avm.de>
---
pee.c | 53 +
pee.docbook | 42 +-
2 files changed, 90 insertions(+), 5 deletions(-)
diff --git a/pee.c b/pee.c
index a8565c0..9243f4e 100644
--- a/pee.c
+++ b/pee.c
@@ -1,5 +1,6 @@
#include
#include
+#include
#include
#include
@@ -28,12 +29,43 @@ close_pipes(FILE **p, size_t i)
int
main(int argc, char **argv) {
+ int ignore_write_error = 1;
+ int ignore_sigpipe = 1;
size_t i, r;
FILE **pipes;
+ int *inactive_pipe;
+ int inactive_pipes = 0;
char buf[BUFSIZ];
+ while(argc > 1) {
+ if (!strcmp(argv[1], "--no-ignore-sigpipe")) {
+ argc--, argv++;
+ ignore_sigpipe = 0;
+ continue;
+ } else if (!strcmp(argv[1], "--ignore-sigpipe")) {
+ argc--, argv++;
+ ignore_sigpipe = 1;
+ continue;
+ } else if (!strcmp(argv[1], "--no-i
Bug#717563: reportbug: web access thru proxy not available
Sorry, I checked to roughly... > > > Running querybts with strace results in: > > > > > > nicolas@my-machine:~$ strace -e trace=connect querybts > > > --proxy=http://172.16.0.66:8080/ -b reportbug > > > > I don't see the error you report, with Reportbug version “6.6.6”. The > > connection succeeds and the ‘querybts’ command continues successfully. > > with version 6.6.6 I cannot reproduce the issue anymore: works for me, > thanks! Unfortunately I have to go with Olaf: It works when I have the HTTP_PROXY environment variable set. Unsetting it and using only the '--proxy' option does _not_ work: 'querybts' always tries to connect directly, not via the given proxy server. Sorry for confusion. Kind regards, Nicolas signature.asc Description: Digital signature
Bug#717563: reportbug: web access thru proxy not available
Dear Ben, > > Running querybts with strace results in: > > > > nicolas@my-machine:~$ strace -e trace=connect querybts > > --proxy=http://172.16.0.66:8080/ -b reportbug > > I don't see the error you report, with Reportbug version “6.6.6”. The > connection succeeds and the ‘querybts’ command continues successfully. with version 6.6.6 I cannot reproduce the issue anymore: works for me, thanks! Nicolas -- gpg key id: 55a0ce7f, epost: nicolas@(hjem.rpa.no|ip6.li) ↳ fpr: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: Digital signature
Bug#820412: irssi-scripts: auto_away: timeout trigger/reset also on '\n' (not only '\r')
Package: irssi-scripts
Version: 20160301
Severity: normal
Tags: patch
Dear maintainer,
the auto_away script does actually not work on my systems due to the
limited timeout/reset triggering: auto_away currently only sets up the
timeout handler on '\r', not on '\n'. The attached patch works for me.
Kind regards,
Nicolas
--- a/usr/share/irssi/scripts/auto_away.pl
+++ b/usr/share/irssi/scripts/auto_away.pl
@@ -39,7 +39,7 @@ Irssi::settings_add_str('misc', 'away_se
sub reset_timer{
my $key=shift;
- if($key == 10){
+ if (($key == 10) or ($key == 13)) {
my (@servers) = Irssi::servers();
foreach my $server (@servers) {
if($server->{usermode_away} == 1){
Bug#817787: slim: leaks open file descriptor
Package: slim Version: 1.3.6-4 Severity: normal Dear Maintainer, slim leaks a read-write open file descriptor (/var/log/slim.log) to child processes. I discovered it by running 'pvcreate': nicolas@deb:~$ pvcreate File descriptor 3 (/var/log/slim.log) leaked on pvcreate invocation. Parent PID 4446: bash Thus, also my window-manager (i3) and all bashs started within to have this descriptor open; modification is easily possible: nicolas@deb:~$ readlink -v /proc/$(pidof i3)/fd/3 /var/log/slim.log nicolas@deb:~$ pidof bash | tr " " "\n" | xargs -n1 -IPID readlink /proc/PID/fd/3 /var/log/slim.log /var/log/slim.log /var/log/slim.log /var/log/slim.log nicolas@deb:~$ echo bla >&3 nicolas@deb:~$ cp /proc/$$/fd/3 /tmp/fd3 && cat /tmp/fd3 slim: waiting for X server to shut down. slim: waiting for X server to begin accepting connections. slim: waiting for X server to shut down slim: waiting for X server to begin accepting connections. .. bla nicolas@deb:~$ Kind regards, Nicolas -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armel Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=nb:nn:dk:se:de:en:C, LC_CTYPE=nb:nn:dk:se:de:en:C (charmap=UTF-8) (ignored: LC_ALL set to nb_NO.UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages slim depends on: ii dbus 1.10.6-1 ii debconf [debconf-2.0] 1.5.58 ii libc6 2.21-9 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.6.3-3 ii libgcc11:5.3.1-10 ii libjpeg62-turbo1:1.4.2-2 ii libpam0g 1.1.8-3.2 ii libpng12-0 1.2.54-4 ii libstdc++6 5.3.1-10 ii libx11-6 2:1.6.3-1 ii libxext6 2:1.3.3-1 ii libxft22.3.2-1 ii libxmu62:1.1.2-2 ii libxrandr2 2:1.5.0-1 ii libxrender11:0.9.9-2 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages slim recommends: ii xterm 322-1 Versions of packages slim suggests: ii scrot 0.8-17 ii xauth 1:1.0.9-1 -- Configuration Files: /etc/slim.conf changed [not included] -- debconf information excluded -- Nicolas Schier Tel: +49 30 39976-790 Fax: +49 30 39976-255 Mail: n.sch...@avm.de https://avm.de/ AVM Audiovisuelles Marketing und Computersysteme GmbH, Alt-Moabit 95, 10559 Berlin HRB 23075 AG Charlottenburg, Geschäftsführer: Johannes Nill signature.asc Description: Digital signature
Bug#718816: +1
Dear Josip, I have already made some patches at home that do prepare separation of parallel from moreutils (as described previously); but these changes do only make sense iff the GNU parallel package is also going to be adjusted (since GNU parallel 'conflicts' with moreutils). I haven't heard anything yet that the proposed solution has a chance to be implemented in the GNU parallel package... But you're right, it is time to push it a bit further within the next weeks... Kind regards, Nicolas -- gpg key id: 55a0ce7f, epost: nicolas@(hjem.rpa.no|ip6.li) ↳ fpr: 18ed 52db e34f 860e e9fb c82b 7d97 0932 55a0 ce7f -- frykten for herren er opphav til kunnskap -- signature.asc Description: PGP signature
