Bug#1073505: RM: rust-pyo3-file -- ROM; dependencies have been removed
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: rust-pyo3-f...@packages.debian.org Control: affects -1 + src:rust-pyo3-file User: ftp.debian@packages.debian.org Usertags: remove Please remove rust-pyo3-file from the archive; having this package in the archive makes updating pyo3 more complicated. There used to be build dependencies on rust-pyo3-file from other packages in the archive, but those have migrated to pyo3-filelike
Bug#1056435: Patch added
I've patched the git repo to mark python 3.12 as supported.
However, there are several test failures with python 3.12 that need to be fixed:
==
ERROR: test_query_float (pony.orm.tests.test_json.TestJson.test_query_float)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/core.py", line 519,
in new_func
result = func(*args, **kwargs)
^
File
"/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/tests/test_json.py", line
91, in test_query_float
self.assertAlmostEqual(val, 9.7)
File "/usr/lib/python3.11/unittest/case.py", line 904, in assertAlmostEqual
diff = abs(first - second)
~~^~~~
TypeError: unsupported operand type(s) for -: 'NoneType' and 'float'
==
FAIL: test_composite_param
(pony.orm.tests.test_json.TestJson.test_composite_param)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
^^^^
File "/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/core.py", line 519,
in new_func
result = func(*args, **kwargs)
^
File
"/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/tests/test_json.py", line
318, in test_composite_param
self.assertEqual(val, 'Wi-Fi')
AssertionError: None != 'Wi-Fi'
==
FAIL: test_equal_json_1 (pony.orm.tests.test_json.TestJson.test_equal_json_1)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/core.py", line 519,
in new_func
result = func(*args, **kwargs)
^
File
"/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/tests/test_json.py", line
335, in test_equal_json_1
self.assertTrue(p)
AssertionError: None is not true
==
FAIL: test_equal_json_2 (pony.orm.tests.test_json.TestJson.test_equal_json_2)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/core.py", line 519,
in new_func
result = func(*args, **kwargs)
^
File
"/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/tests/test_json.py", line
343, in test_equal_json_2
self.assertTrue(p)
AssertionError: None is not true
==
FAIL: test_equal_list_1 (pony.orm.tests.test_json.TestJson.test_equal_list_1)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/core.py", line 519,
in new_func
result = func(*args, **kwargs)
^
File
"/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/tests/test_json.py", line
369, in test_equal_list_1
self.assertTrue(p)
AssertionError: None is not true
==
FAIL: test_equal_list_3 (pony.orm.tests.test_json.TestJson.test_equal_list_3)
--
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/decorator.py", line 232, in fun
return caller(func, *(extras + args), **kw)
File "/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/core.py", line 519,
in new_func
result = func(*args, **kwargs)
^
File
"/home/jelmer/src/build-area/ponyorm-0.7.17/pony/orm/tests/test_json.py",
Bug#1064436: lintian-brush: Missing git commit + changelog entry for added upstream/metadata
On Mon, Feb 26, 2024 at 06:38:24PM +0100, Andreas Tille wrote: > Control: tags -1 - moreinfo > thanks > > Hi Jelmer, > > Am Mon, Feb 26, 2024 at 03:14:20PM +0000 schrieb Jelmer Vernooij: > > On Thu, Feb 22, 2024 at 08:30:46AM +0100, Andreas Tille wrote: > > > if upstream/metadata are added this is not added+commited to > > > the packaging repository. There is also no changelog created > > > which should be something like > > > > > > * Add upstream metadata > > > > Are you specifying --update-changelog ? > > Not explicitly yet. I'm pretty sure when I started calling > lintian-brush from routine-update changelog was updated. It would have dependend on the package. If lintian-brush determines that the changelog is updated using "gbp dch" then it would not update the changelog; it has had this behaviour since the beginning. You can override the detection with the --update-changelog / --no-update-changelog flags. (But as mentioned earlier, I'm curious to hear about packages for which the detection doesn't work, like the one you've presumably just encountered) > And as you can see in my other bug report > >#1060338 lintian-brush: Changelog entries are lacking asterisk > > there actually *are* changelog entries ... but they are more ugly > than before. Yep, thanks for the bug report - hoping to get to that later this week. > > By default lintian-brush > > autodetects whether it needs to update the changelog. > > Well, this actual bug is about "if upstream/metadata are added this is > not added+commited to the packaging repository". It simply happens that > upstream/metadata is added and after lintian-brush git consideres the > local repository not clean any more since there are files that are not > yet added. You should be able to verify this by simply removing > upstream/metadata and run lintian-brush (or whatever tool finally is > adding this file.) I would not mind about a missing changelog entry but > at least the freshly created file should be added. I'm pretty sure this > is a regression since that worked before. Thanks, I'll give that a try. > > You can see whether it thinks it needs to update the changelog by running > > ``detect-changelog-behaviour``. > > I simply want to have a changelog entry once something was changed. Right, --update-changelog should do that independently of whether lintian-brush things gbp dch is in use. Cheers, Jelmer
Bug#1064436: lintian-brush: Missing git commit + changelog entry for added upstream/metadata
tags 1064436 +moreinfo thanks On Thu, Feb 22, 2024 at 08:30:46AM +0100, Andreas Tille wrote: > if upstream/metadata are added this is not added+commited to > the packaging repository. There is also no changelog created > which should be something like > > * Add upstream metadata Are you specifying --update-changelog ? By default lintian-brush autodetects whether it needs to update the changelog. You can see whether it thinks it needs to update the changelog by running ``detect-changelog-behaviour``. (Also happy to take bug reports on the autodetection behaviour not working well, but in that case, please provide extra context). Cheers, Jelmer
Bug#1061772: Missing dependencies
There's a bunch of dependencies for JJ that probably need to be packaged first. IIRC there is somebody working on gitoxide (gix-*) already in debcargo clap-markdown v0.1.3 esl01-renderdag v0.3.0 gix-config v0.32.1 gix-diff v0.38.0 gix-discover v0.27.0 gix-hashtable v0.4.1 gix-index v0.27.1 gix-macros v0.1.3 gix-object v0.39.0 gix-odb v0.55.0 gix-pack v0.45.0 gix-refspec v0.20.0 gix-ref v0.39.1 gix-revision v0.24.0 gix-revwalk v0.10.0 gix-traverse v0.35.0 gix v0.56.0 pollster v0.3.0 scm-record v0.2.0 serde_bser v0.3.1 tracing-chrome v0.7.1 watchman_client v0.8.0
Bug#1061102: Not related to xsltproc?
tags 1061102 + moreinfo thanks Hi Jonas, Looking at the output of the build log, the problem appears to be this: configure: error: in `/build/biome-1.5.2/target/x86_64-unknown-linux-gnu/release/build/tikv-jemalloc-sys-2de43a13417834c8/out/build': configure: error: cannot compute suffix of object files: cannot compile The fact that xsltproc can't be found isn't fatal as far as I can tell. When building tikv-jemalloc-sys in sbuild, this step succeeds for me and it successfully finds the suffix of object files: [tikv-jemalloc-sys 0.5.4+5.3.0-patched] checking for xsltproc... false [tikv-jemalloc-sys 0.5.4+5.3.0-patched] checking for x86_64-unknown-linux-gnu-gcc... cc [tikv-jemalloc-sys 0.5.4+5.3.0-patched] checking whether the C compiler works... yes [tikv-jemalloc-sys 0.5.4+5.3.0-patched] checking for C compiler default output file name... a.out [tikv-jemalloc-sys 0.5.4+5.3.0-patched] checking for suffix of executables... [tikv-jemalloc-sys 0.5.4+5.3.0-patched] checking whether we are cross compiling... no [tikv-jemalloc-sys 0.5.4+5.3.0-patched] checking for suffix of object files... o [tikv-jemalloc-sys 0.5.4+5.3.0-patched] checking whether we are using the GNU C compiler... yes ... the package also builds successfully otherwise, as well as its other reverse dependencies (e.g. rust-tikv-jemalloc-ctl).
Bug#1062437: python-debian: When Files: is a whitespace-separated list, files are matched too eagerly
severity 1062437 important
tags 1062437 +confirmed
thanks
Thanks for the bugreport! I agree that this is an important thing to fix and
we're not following the specification in
https://dep-team.pages.debian.net/deps/dep5/ here.
I don't think it violates policy 2.3 though; the meaning of the copyright files
doesn't change, and DEP-5 is not part of policy. python-debian's own copyright
file
is not invalid (which is how I would read policy 2.3). So downgrading this to
important.
Jelmer
On Thu, Feb 01, 2024 at 02:39:06PM +0100, Carmen Bianca BAKKER wrote:
> Source: python-debian
> Version: 0.1.49
> Severity: serious
> Tags: upstream
> Justification: Policy 2.3
>
> So this is an interesting bug inside of the python-debian source code first
> spotted in <https://github.com/fsfe/reuse-tool/issues/900> by Chris Pressey. I
> marked it as serious because fixing the bug might potentially break the
> debian/copyright of an unknown number of Debian packages.
>
> Problem description:
>
> When `Files:` contains a whitespace-separated list of paths, each non-ultimate
> path appears to be matched as if there were a glob at the end.
>
> To reproduce:
>
> 1. Create a debian/copyright file with a `Files:` paragraph that has one line
> for 'foo', and one line for 'bar'.
> 2. Use the method Copyright.find_files_paragraph("foo quz")
>
> Result:
>
> A match is found on the paragraph.
>
> Running Copyright.find_files_paragraph("bar quz") here results in no match,
> unless you add an extra item to the `Files:` list.
>
> Expected result:
>
> No match is found on the paragraph.
>
>
> I have a repository at <https://codeberg.org/carmenbianca/dep5-eager-example>
> that serves as example.
>
> Yours with kindness,
> Carmen
>
>
> -- System Information:
> Debian Release: 12.4
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=eo.UTF-8, LC_CTYPE=eo.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> --
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-python-debian-maint
Bug#1057860: Will do release + upload this weekend
We'll just need to do an upstrema release and an upload for this, the change is already in upstream bzr. I'll do this over the weekend; if I fail to do a release for some reason then I'll ship the patch in Debian. Jelmer
Bug#1055242: pkg-config files have empty Version
Package: libsvn-dev Version: 1.14.2-4+b3 Severity: normal The pkg-config files for the libsvn libraries have an empty Version string. E.g.: ... Name: libsvn_client Description: Subversion Client Library Version: Requires: apr-util-1, apr-1 Requires.private: libsvn_wc, libsvn_ra, libsvn_delta, libsvn_diff, libsvn_subr ... (in /usr/lib/x86_64-linux-gnu/pkgconfig/libsvn_client.pc) This makes it hard to e.g. check for what version is present. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libsvn-dev depends on: ii libapr1-dev 1.7.2-3 ii libaprutil1-dev 1.6.3-1 ii libsvn1 1.14.2-4+b3 libsvn-dev recommends no packages. Versions of packages libsvn-dev suggests: pn libserf-dev pn libsvn-doc ii zlib1g-dev 1:1.2.13.dfsg-3 -- debconf-show failed
Bug#1054568: breezy - broken rust regex build-dependency
Hi Peter, Please do go ahead and NMU this. Thanks! Cheers, Jelmer On Thu, Oct 26, 2023 at 04:19:28AM +0100, Peter Green wrote: > Package: breezy > Version: 3.3.4-1 > Severity: serious > Tags: patch > > Breezy build-depends on librust-regex+aho-corasick-dev which is no longer > provided (in either physical or virtual form) by rust-regex. > > Looking at the Cargo.toml files I belive the correct build-dependency is > librust-regex-1+default-dev (>= 1.5.4), after changing the build-dependency > I was able to get a succesful build. > > If there are no objections I will likely NMU this in the not too distant > future. > diff -Nru breezy-3.3.4/debian/changelog breezy-3.3.4/debian/changelog > --- breezy-3.3.4/debian/changelog 2023-09-04 17:39:38.0 + > +++ breezy-3.3.4/debian/changelog 2023-10-26 02:55:52.0 + > @@ -1,3 +1,12 @@ > +breezy (3.3.4-1.1) UNRELEASED; urgency=medium > + > + * Non-maintainer upload. > + * Replace broken build-dependency on "librust-regex+aho-corasick-dev" > +with build-dependency on "librust-regex-1+default-dev (>= 1.5.4)" > +based on the contents of Cargo.toml. > + > + -- Peter Michael Green Thu, 26 Oct 2023 02:55:52 > + > + > breezy (3.3.4-1) unstable; urgency=low > >* New upstream release. > diff -Nru breezy-3.3.4/debian/control breezy-3.3.4/debian/control > --- breezy-3.3.4/debian/control 2023-09-04 17:39:38.0 + > +++ breezy-3.3.4/debian/control 2023-10-26 02:55:40.0 + > @@ -31,7 +31,7 @@ > debhelper-compat (= 13), > librust-pkg-version-dev, > librust-pyo3-dev, > - librust-regex+aho-corasick-dev, > + librust-regex-1+default-dev (>= 1.5.4), > rustc > Standards-Version: 4.6.2 > Rules-Requires-Root: no
Bug#1030835: ITP: ruff -- linter for Python, written in Rust
On Wed, Oct 25, 2023 at 02:05:39PM +0200, Matthias Urlichs wrote: > Hello, > > Package: wnpp > > Severity: wishlist > > Owner: James Addison > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: ruff > >Version : 0.0.243 > >Upstream Contact: Charlie Marsh > > * URL : https://github.com/charliermarsh/ruff/ > > * License : MIT > >Programming Lang: Rust > >Description : linter for Python, written in Rust > > > > Ruff is a linter for Python that includes implementations of many common > > checks implemented by flake8, flake8 plugins, and pylint. > > > Any progress with this? See my recent posts to the bug report. We're waiting on various dependencies of ruff to pass through NEW. Jelmer
Bug#1030835: Current status
Current status: in NEW: librust-imperative-dev librust-libcst-dev Need to upload: librust-tikv-jemalloc-sys-dev librust-tikv-jemallocator-dev Need to update: thiserror thiserror-impl Cheers, Jelmer
Bug#1052709: RM: bzr-upload -- ROM; transitional package
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: bzr-upl...@packages.debian.org Control: affects -1 + src:bzr-upload Please remove the bzr-upload package from unstable. This transitional package has been present for a few releases now (⇒ breezy).
Bug#1052650: overflows stack on ruff
Package: cargo-debstatus Version: 0.5.0-3 Severity: normal Hello, "cargo debstatus" runs out of stack space on ruff: $ git clone https://github.com/astral-sh/ruff $ cd ruff $ cargo debstatus -p ruff_cli --no-indent ... thread 'main' has overflowed its stack fatal runtime error: stack overflow ruff's dependency stack is pretty crazy FWIW, so that may be related. -- System Information: Debian Release: trixie/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, 'buildd-experimental'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cargo-debstatus depends on: ii libc6 2.37-10 ii libgcc-s1 13.2.0-4 cargo-debstatus recommends no packages. cargo-debstatus suggests no packages. -- no debconf information
Bug#1030835: More updates
newer versions of ruff now use a forked vendored copy of rustpython, and upstream says they're diverging. I've updated the packaging to ruff 0.0.291, which is the point after the vendoring. State of unmet dependencies: * lalrpop/lalrpop-util needs updating to 0.20. unstable has 0.19, updating it is nontrivial - help appreciated! * argfile v0.1.6 (in NEW queue) * clearscreen v2.0.1 (in NEW queue) * imperative v1.0.5 (in NEW queue) * rust-stemmers (in NEW queue) * libcst v0.1.0 (in NEW queue) * syn-ext v0.4.0 (in NEW queue) * serde_with v3.3.0 (in NEW queue) * result-like-derive v0.4.6 (in NEW queue) * result-like v0.4.6 (in NEW queue) That's probably an incomplete list; "cargo debstatus" runs out of stack space analyzing ruff now :-/ Cheers, Jelmer
Bug#1052319: ITP: rust-analyzer -- LSP server for Rust
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: rust-analyzer Version : 0.3.1631 Upstream Contact: Rust Analyzer Developers * URL : https://github.com/rust-lang/rust-analyzer * License : MIT or Apache-2.0 Programming Lang: Rust Description : LSP server for Rust rust-analyzer is an implementation of Language Server Protocol for the Rust programming language. It provides features like completion and goto definition for many code editors, including VS Code, Emacs and Vim.
Bug#1052286: please re-enable building against pkcs5 crate
Source: rust-pkcs8 Version: 0.10.2+ds-7 Severity: wishlist Hello, The pkcs5 crate has entered unstable. Please consider dropping the 2002_pkcs5.patch patch. I've verified that the package still builds without it. This will enable building of the rsa crate. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1051766: lintian-brush: apply-multiarch-hints does not finish
tags 1051766 + confirmed thanks On Tue, Sep 12, 2023 at 12:29:31PM +0200, Andreas Tille wrote: > after upgrading to lintian-brush 0.150 apply-multiarch-hints just does > not end and I need to kill the actual xterm (even ^C does not back the > prompt). After killing the xterm it leaves a broken git repository. > > I cloned my test repository freshly from salsa and downgraded to > lintian-brush 0.149. Then I get: > > > $ apply-multiarch-hints > Traceback (most recent call last): > File "/usr/bin/apply-multiarch-hints", line 8, in > sys.exit(main()) > ^^ > File "/usr/lib/python3/dist-packages/lintian_brush/multiarch_hints.py", > line 512, in main > MultiArchHintFixer(hints), > ^ > TypeError: No constructor defined > > > No idea whether this gives some hint - but at least neither the git > repository is broken nor I have to interrupt really hard. Thanks for the report. I've got a fix for this in progress, will hopefully upload this weekend. Jelmer
Bug#1051501: provide subcommand that lists debian dependencies for a crate
Package: debcargo Severity: wishlist I've packaged a few Python packages that include rust code. Since they're python packages, I can't just use debcargo. However, it would be great if I somehow use debcargo to extract Debian dependency information from Cargo.toml. Perhaps a subcommand for debcargo that just dumps out a list of Debian dependencies and the features they are relevant for? -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages debcargo depends on: ii libc62.36-9 ii libcurl3-gnutls 7.88.1-10 ii libgcc-s112.2.0-14 pn libgit2-1.5 ii libssh2-11.10.0-3+b1 ii libssl3 3.0.9-1 ii quilt0.67+really0.66-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages debcargo recommends: pn dh-cargo debcargo suggests no packages.
Bug#1030835: Progress
Status update: ruff-macros: not touched yet rustpython-common: packaged, waiting for lexical-parse-* lexical-parse-integer: uploaded, in NEW lexical-parse-float: waiting for lexical-parse-integer python-libcst: uploaded, in NEW libcst: need to package rust crate; it'd be convenient if we could get it from crates.io (https://github.com/Instagram/LibCST/issues/967), but otherwise I'll just package a git snapshot Cheers, Jelmer
Bug#1030835: Another round of updates
> * python-maturin in NEW > * ruff-macros Not touched yet > * rustpython-ast in NEW > * rustpython-common packaged, waiting on dependencies (lexical-parse-*) to land in unstable > * lexical-parse-float packaged, waiting on dependencies (lexical-util) to land in unstable > * lexical-parse-integer packaged, waiting on dependencies (lexical-util) to land in unstable > * lexical-util in NEW > * chic packaged, waiting on dependencies (annotate-snippets) to land in unstable > * annotate-snippets in NEW > * criterion-cycles-per-byte in NEW > And python packages: > > * libcst in process of packaging Cheers, Jelmer -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc
Bug#1030835: Updates
> * python-maturin in NEW > * ruff-macros Not touched yet > * rustpython-ast packaged, waiting on dependencies to land in unstable > * rustpython-common packaged, waiting on dependencies to land in unstable > * lexical-parse-float packaged, waiting on dependencies to land in unstable > * lexical-parse-integer packaged, waiting on dependencies to land in unstable > * lexical-util in NEW > * volatile in NEW > * unic-ucd-category in NEW > * rustpython-compiler-core in NEW > * hexf-parse ACCEPTED > * rustpython-parser packaged, waiting on dependencies to land in unstable > * unic-emoji-char in NEW > * unic-ucd-ident in NEW > * unicode_names2 in process of packaging > * schemars ACCEPTED > * titlecase packaged, waiting on dependencies (joinery) to land in unstable > * joinery in NEW > * ciborium in NEW > * chic packaged, waiting on dependencies (annotate-snippets) to land in unstable > * annotate-snippets packaged, waiting on dependencies (yansi-term) to land in unstable > * yansi-term in NEW > And python packages: > > * libcst in process of packaging Jelmer -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc signature.asc Description: PGP signature
Bug#1030835: Quite a lot of dependencies
I've picked up ruff now that maturin (which it uses for building) is in NEW. It does look like there's quite a lot of other crates that need to be packaged first: * ruff-macros * rustpython-ast * rustpython-common * lexical-parse-float * lexical-parse-integer * lexical-util * volatile * unic-ucd-category * rustpython-compiler-core * lexf-parse * rustpython-parser * unic-emoji-char * unic-ucd-ident * unicode_names2 * schemars * titlecase * joinery * ciborium * chic * annotate-snippets And python packages: * libcst Jelmer
Bug#1043391: debianize crash
Package: lintian-brush On Sun, Jun 25, 2023 at 05:42:11PM +0200, Alexandre Detiste wrote: > I know it's experimental :-) > > url = g...@github.com:dcarp/cmake-d.git > > > > debianize > debianize is experimental and often generates packaging that is incomplete > or does not build as-is. If you encounter issues, please consider filing a > bug. > No upstream repository specified, using upstream source in > /home/tchet/git/cmake-d/ > Switching to packaging branch debian/main. > No upstream releases found, falling back to snapshot. > No upstream releases found, falling back to snapshot. > found 457 deltas to reuse > > > found 457 deltas to reuse > No support in debianize for build system cmake, falling back to default. > Creating core packaging using process_default > Kickstarting from dist tarball. Using upstream version > 0+git20210905.1.34095f2 > Looking for upstream 0+git20210905.1.34095f2 in upstream branch > file:///home/tchet/git/cmake-d/,branch=debian%2Fmain. > Looking for upstream 0+git20210905.1.34095f2 in upstream branch > file:///home/tchet/git/cmake-d/,branch=debian%2Fmain. > Traceback (most recent call last): > > > File "/usr/bin/debianize", line 8, in > sys.exit(main()) > ^^ > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 1660, in main > debianize_result = debianize( >^^ > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 1098, in debianize > control = process( > > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 688, in process_default > kickstart_from_dist(wt, subpath) > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 1016, in kickstart_from_dist > result.tag_names) = import_upstream_dist( > ^ > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 822, in import_upstream_dist > upstream_branch_name) = import_upstream_version_from_dist( > ^^ > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 336, in import_upstream_version_from_dist > locations = upstream_source.fetch_tarballs( > ^^^ > File > "/usr/lib/python3/dist-packages/breezy/plugins/debian/upstream/branch.py", > line 614, in fetch_tarballs > fn = self.create_dist( > ^ > File "/usr/lib/python3/dist-packages/lintian_brush/debianize.py", line > 290, in default_create_dist > return ogni_create_dist( >^ > File "/usr/lib/python3/dist-packages/ognibuild/dist.py", line 162, in > create_dist > return dist(session, os.path.join(export_directory, subpath), >^^ > File "/usr/lib/python3/dist-packages/ognibuild/dist.py", line 81, in dist > from .fixers import ( > File "/usr/lib/python3/dist-packages/ognibuild/fixers.py", line 22, in > > from buildlog_consultant.common import ( > ImportError: cannot import name 'MissingGoSumEntry' from > 'buildlog_consultant.common' > (/usr/lib/python3/dist-packages/buildlog_consultant/common.py)
Bug#1042830: Issue in Breezy
This is an issue in breezy; see #968111
Bug#999850: Almost there..
At this point, the maturin package is just waiting for rust-cargo-config2 (which I've just uploaded) to make it through NEW. Once that has happened, I'll upload maturin. I have disabled the upload and scaffolding features for now, since they requires a couple of other crates that are not yet packaged (with a deep dependency stack). Cheers, Jelmer
Bug#1023477: (no subject)
retitle 1023477 RFP: libtypec -- user-space library for accessing USB-C/USB-PD metadata thanks I replied to your email to me about this ITP a couple of days ago, but perhaps that got lost in a spam filter somewhere: > Hi Colin, > > I originally started on this but didn't get very far. IIRC there were > some issues building on Debian, and then I got distracted by other > things before I could resolve those. > > If you're interested in taking over the ITP, please feel free to > do so. > > Cheers, > > Jelmer
Bug#1040641: lintiant-brush: crash in debian-watch-file-old-format
Package: lintian-brush thanks On Sat, Jul 08, 2023 at 01:52:52AM +0200, Alexandre Detiste wrote: > tchet@antec:~/git/boswars$ cat debian/watch > version=3 > > https://www.boswars.org/download.shtml > dist/releases/boswars-([0-9.]*)-src\.tar\.gz > > > > lintian-brush --list-fixers | while read f; do echo $f; lintian-brush $f ; > done > > > debian-watch-contains-dh_make-template > No changes made. > debian-watch-file-is-missing > No changes made. > debian-watch-file-old-format > Traceback (most recent call last): > File "/usr/bin/lintian-brush", line 8, in > sys.exit(main()) > ^^ > File "/usr/lib/python3/dist-packages/lintian_brush/__main__.py", > line 357, in main > overall_result = run_lintian_fixers( > ^^^ > File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", > line 740, in run_lintian_fixers > result, summary = run_lintian_fixer( > ^^ > File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", > line 462, in run_lintian_fixer > result = fixer.run( > ^^ > TypeError: FormattingUnpreservable.__init__() missing 3 required > positional arguments: 'path', 'original_contents', and > 'rewritten_contents'
Bug#999850: Remaining changes
Current todo list in terms of crate changes: python-pkginfo: in NEW cargo-config2: package v0.1.7 cfg-expr: update to v0.15.2 toml: update to v0.7.4 serde_spanned: update to v0.6.2 toml_datetime: update to v0.6.2 toml_edit: update to v0.19.10 serde_spanned: update to v0.6.2 winnow: update to v0.4.6 dirs: update to v5.0.1 dirs-sys: update to v0.4.1 option-ext: update to v0.2.0 cargo_metadata: update to v0.15.4 clap_complete_command: update to v0.5.1 clap_complete_fig: update to v4.2.0 fat-macho: update to v0.4.6 goblin: update to v0.6.1 scroll: update to v0.11.0 scroll_derive: update to v0.11.0 syn: update to v1.0.109 lddtree: update to v0.3.2 multipart v0.18.0 normpath: update to v1.1.1 trycmd: update to v0.14.11 humantime-serde: update to v1.1.1 snapbox: update to v0.4.4 concolor: update to v0.0.11 bitflags: update to v1.3.2 Note that "update to X" can also mean patching maturin to use the version currently in the Debian archive. Cheers, Jelmer
Bug#1006871: Bug is not fixed in pmacct 1.7.7 from bookworm
Hi Oliver, On Wed, Jun 21, 2023 at 03:20:13PM +0200, Oliver wrote: > Dear Maintainer, > > this is not fixed in pmacct 1.7.7 from bookworm. > > Paolos patch is still valid: > https://github.com/pmacct/pmacct/commit/73af9545ea33cd87846306f648f634063ac41765 > > Please fix this at least in Debian Bookworm 12 Unfortunately this package is currently orphaned, and doesn't have a current maintainer. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968052 Cheers, Jelmer
Bug#1038786: RM: bzr-stats -- ROM; transitional package present since bullseye
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: bzr-st...@packages.debian.org Control: affects -1 + src:bzr-stats Please remove the bzr-stats package; it's been present as a transitional package since bullseye.
Bug#1038657: RM: bzr-git -- ROM; transitional package present since bullseye
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: bzr-...@packages.debian.org Control: affects -1 + src:bzr-git Please remove the bzr-git source package; it has been purely transitional since bullseye.
Bug#1038656: RM: bzr-fastimport -- ROM; transitional package since bullseye & bookworm
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: bzr-fastimp...@packages.debian.org Control: affects -1 + src:bzr-fastimport Please remove the bzr-fastimport source package; it has been purely transitional since bullseye
Bug#1038655: RM: bzr-email -- ROM; transitional package present in bookworm & bullseye
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: bzr-em...@packages.debian.org Control: affects -1 + src:bzr-email Please remove the bzr-email package from the archive. It has been a purely transitional package since bullseye.
Bug#1038654: RM: bzr-builddeb -- ROM; transitional package that was present for bullseye and bookworm
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: bzr-build...@packages.debian.org Control: affects -1 + src:bzr-builddeb Please remove the bzr-builddeb package from the archive. It has been a purely transitional package since bullseye.
Bug#1037521: false positive NONVERBOSE BUILD for rust code in Python modules
Package: blhc
Severity: minor
blhc reports false positives when analyzing build logs for Python
modules that include rust code.
Example:
$ blhc --debian --line-numbers --color ${SALSA_CI_BLHC_ARGS}
${WORKING_DIR}/*.build || [ $? -eq 1 ]
75:NONVERBOSE BUILD:Compiling autocfg v1.1.0
76:NONVERBOSE BUILD:Compiling proc-macro2 v1.0.60
79:NONVERBOSE BUILD:Compiling target-lexicon v0.12.3
82:NONVERBOSE BUILD:Compiling unicode-ident v1.0.0
84:NONVERBOSE BUILD:Compiling quote v1.0.27
90:NONVERBOSE BUILD:Compiling syn v1.0.109
92:NONVERBOSE BUILD:Compiling pyo3-build-config v0.19.0
98:NONVERBOSE BUILD:Compiling once_cell v1.17.0
101:NONVERBOSE BUILD:Compiling libc v0.2.146
104:NONVERBOSE BUILD:Compiling serde_derive v1.0.152
108:NONVERBOSE BUILD:Compiling pyo3-ffi v0.19.0
110:NONVERBOSE BUILD:Compiling lock_api v0.4.9
112:NONVERBOSE BUILD:Compiling parking_lot_core v0.9.3
114:NONVERBOSE BUILD:Compiling serde v1.0.152
116:NONVERBOSE BUILD:Compiling ryu v1.0.2
123:NONVERBOSE BUILD:Compiling memoffset v0.6.5
125:NONVERBOSE BUILD:Compiling indexmap v1.9.2
127:NONVERBOSE BUILD:Compiling smallvec v1.9.0
129:NONVERBOSE BUILD:Compiling cfg-if v1.0.0
131:NONVERBOSE BUILD:Compiling scopeguard v1.1.0
138:NONVERBOSE BUILD:Compiling pyo3-macros-backend v0.19.0
141:NONVERBOSE BUILD:Compiling pyo3 v0.19.0
143:NONVERBOSE BUILD:Compiling serde_json v1.0.87
145:NONVERBOSE BUILD:Compiling hashbrown v0.12.3
148:NONVERBOSE BUILD:Compiling unindent v0.1.8
150:NONVERBOSE BUILD:Compiling linked-hash-map v0.5.6
152:NONVERBOSE BUILD:Compiling yaml-rust v0.4.5
154:NONVERBOSE BUILD:Compiling indoc v1.0.4
159:NONVERBOSE BUILD:Compiling pyo3-macros v0.19.0
162:NONVERBOSE BUILD:Compiling parking_lot v0.12.1
166:NONVERBOSE BUILD:Compiling itoa v1.0.1
170:NONVERBOSE BUILD:Compiling serde_yaml v0.8.26
172:NONVERBOSE BUILD:Compiling lintian-brush v0.148.0
(/builds/jelmer/lintian-brush/debian/output/source_dir)
174:NONVERBOSE BUILD:Compiling lintian-brush-py v0.0.0
(/builds/jelmer/lintian-brush/debian/output/source_dir/lintian-brush-py)
https://salsa.debian.org/jelmer/lintian-brush/-/jobs/4307243
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.3.0-0-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages blhc depends on:
ii libdpkg-perl 1.21.22
blhc recommends no packages.
blhc suggests no packages.
Bug#999850: More progress
Current status, left: * charset: packaged, fails to build * mailparse: packaged, not yet uploaded (depends on charset) * python-pkginfo: packaged, not yet uploaded (depends on mailparse) * pep508-rs: in NEW * pyproject-toml: uploaded to NEW * pyo3-log: in NEW Jelmer
Bug#999850: More progress
I've gotten a little bit further on this: Now packaged in unstable: * cargo-options * pep440_rs * quoted-printable In NEW: * pep508_rs * python-project In the process of being packaged (in debcargo-conf, not yet uploaded): * python-pkginfo * charset * mailparse * rfc2047-decoder Still todo (help welcome!): * update clap-complete-command >= 4 Cheers, Jelmer
Bug#1036731: python3-debian: fails to parse some debian/control.in files
On Wed, May 24, 2023 at 10:56:21PM +0200, Dylan Aïssi wrote: > python3-debian is not able anymore to parse correctly some debian/control.in. > The first version with this issue is 0.1.44, so I suppose it is related to the > new RTS parser. The consequence of this bug is wrap-and-sort crashes when it > run on these files. Below is the error message: > > Traceback (most recent call last): > File "/usr/bin/wrap-and-sort", line 496, in > main() > File "/usr/bin/wrap-and-sort", line 481, in main > modified_files = wrap_and_sort(args) > ^^^ > File "/usr/bin/wrap-and-sort", line 312, in wrap_and_sort > control = WrapAndSortControl(control_file, args) > ^^ > File "/usr/bin/wrap-and-sort", line 99, in __init__ > super().__init__(filename, use_rts_parser=args.rts_parser) > File "/usr/lib/python3/dist-packages/devscripts/control.py", line > 210, in __init__ > self._deb822_file = parse_deb822_file(sequence) > ^^^ > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py", > line 3095, in parse_deb822_file > deb822_file = Deb822FileElement(LinkedList(tokens)) > ^^ > File "/usr/lib/python3/dist-packages/debian/_util.py", line 159, in __init__ > self.extend(values) > File "/usr/lib/python3/dist-packages/debian/_util.py", line 272, in extend > for v in values: > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", > line 104, in _impl > for token in token_stream: > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", > line 104, in _impl > for token in token_stream: > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py", > line 2991, in _build_field_with_value > value_element = next(buffered_stream, None) > ^^^ > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", > line 143, in __next__ > return next(self._stream) >^^ > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", > line 104, in _impl > for token in token_stream: > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py", > line 2939, in _build_value_line > tokens_in_value = list(buffered_stream.takewhile(_non_end_of_line_token)) > ^^^ > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", > line 149, in takewhile > while buffer or self._fill_buffer(5): > > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", > line 198, in _fill_buffer > self._buffer.append(next(self._stream)) > ^^ > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/_util.py", > line 104, in _impl > for token in token_stream: > File "/usr/lib/python3/dist-packages/debian/_deb822_repro/parsing.py", > line 3031, in _abort_on_error_tokens > raise SyntaxOrParseError( > debian._deb822_repro.types.SyntaxOrParseError: Syntax or Parse error > on the line: "%if USE_SYSTEM_ZLIB\n" > > An easy way to reproduce the crash is to run wrap-and-sort on the > debian/ folder of > firefox-esr: > > wget > > http://deb.debian.org/debian/pool/main/f/firefox-esr/firefox-esr_102.11.0esr-1.debian.tar.xz > > tar -xvf firefox-esr > > wrap-and-sort > > It crashes in a similar way on these packages: babel-minify and > xapian-bindings. Thanks for the bug report. FWIW Deb822 isn't really built to support parsing deb822 files with arbitrary data in the middle. This means it doesn't do well with at least some .in files (which use a variety of styles). That said, it would be good to handle this particular case better. Cheers, Jelmer
Bug#999850: More progress
I've done another round of updates to the maturin package. Mostly this has involved loosening dependencies so that it can use versions of rust crates that are already in the archive. It's possible that some of this will bite us further down the line (since some of the dependencies are actually strict for a good reason), but for the majority of crates this is fine. When that happens, we can selectively bump the versions of those crate in the archive. I've also dropped support for some optional features, including cross building for Windows and Mac OS X, which requires crates that are not packaged in Debian. Right now, building is blocked on the following crates not being in the archive: * cargo-options (packaged in debcargo-conf, will be uploaded shortly) * clap-complete-command >= 4 (not yet packaged) + this depends on a clap-complete-fig >= 4, newer than is currently in the archive * pyproject-toml * python-pkginfo * lddtree * pep440 * minijinja2 Initially I'd probably disable optional features that depend on crates that aren't in the archive. Some of these crates are: * multipart * native-tls-crate * keyring If you're familiar with debcargo, then help packaging these crates would be great towards getting maturin into Debian. Cheers, Jelmer
Bug#1035742: lintian-brush: excessive dependencies
reassign 1035742 python3-launchpadlib thanks On Mon, May 08, 2023 at 06:18:33PM +0300, Martin-Éric Racine wrote: > On Mon, May 8, 2023 at 6:11 PM Jelmer Vernooij wrote: > > On Mon, May 08, 2023 at 05:56:47PM +0300, Martin-Éric Racine wrote: > > > lintian-brush currently Depends on or Recommends packages that pull a > > > large part of GNOME. > > > > > > This is excessive, especialy for a CLI tool. Please demote some of these > > > to mere Suggests. > > > > Thanks for the bug report. > > > > Can you be more specific - which packages is it pulling in that are > > unexpected? lintian-brush has a Suggests on gnome-pkg-tools, but none of > > its hard > > dependencies/recommends should (transitively) depend on GNOME. > > python3-launchpadlib pulls everything and the kitchen sink: > > $ LC_ALL=C sudo apt-get install --option > Debug::pkgDepCache::AutoInstall=true lintian-brush > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done >Installing python3-breezy:i386 as Depends of lintian-brush:i386 > Installing python3-configobj:i386 as Depends of python3-breezy:i386 > Installing python3-fastbencode:i386 as Depends of python3-breezy:i386 > Installing python3-merge3:i386 as Depends of python3-breezy:i386 > Installing python3-dulwich:i386 as Depends of python3-breezy:i386 > Installing python3-fastimport:i386 as Recommends of python3-dulwich:i386 > Installing python3-patiencediff:i386 as Depends of python3-breezy:i386 > Installing python3-launchpadlib:i386 as Recommends of python3-breezy:i386 > Installing python3-lazr.restfulclient:i386 as Depends of > python3-launchpadlib:i386 > Installing python3-lazr.uri:i386 as Depends of > python3-lazr.restfulclient:i386 > Installing python3-wadllib:i386 as Depends of > python3-lazr.restfulclient:i386 > Installing python3-oauthlib:i386 as Depends of > python3-lazr.restfulclient:i386 > Installing python3-blinker:i386 as Depends of python3-oauthlib:i386 > Installing python3-jwt:i386 as Depends of python3-oauthlib:i386 > Installing python3-keyring:i386 as Recommends of > python3-launchpadlib:i386 > Installing python3-jaraco.classes:i386 as Depends of > python3-keyring:i386 > Installing python3-jeepney:i386 as Depends of python3-keyring:i386 > Installing python3-secretstorage:i386 as Depends of > python3-keyring:i386 > Installing gnome-keyring:i386 as Recommends of > python3-secretstorage:i386 > Installing dconf-gsettings-backend:i386 as Depends of > gnome-keyring:i386 > Installing dconf-service:i386 as Depends of > dconf-gsettings-backend:i386 > Installing libdconf1:i386 as Depends of dconf-service:i386 > Installing libgck-1-0:i386 as Depends of gnome-keyring:i386 > Installing libgcr-base-3-1:i386 as Depends of gnome-keyring:i386 > Installing gcr:i386 as Depends of gnome-keyring:i386 > Installing libgcr-ui-3-1:i386 as Depends of gcr:i386 > Installing libcairo2:i386 as Depends of libgcr-ui-3-1:i386 > Installing libpixman-1-0:i386 as Depends of libcairo2:i386 > Installing libxcb-render0:i386 as Depends of libcairo2:i386 > Installing libxcb-shm0:i386 as Depends of libcairo2:i386 > Installing libxrender1:i386 as Depends of libcairo2:i386 > Installing libgdk-pixbuf-2.0-0:i386 as Depends of > libgcr-ui-3-1:i386 > Installing libgdk-pixbuf2.0-common:i386 as Depends > of libgdk-pixbuf-2.0-0:i386 > Installing libgdk-pixbuf2.0-bin:i386 as Recommends > of libgdk-pixbuf-2.0-0:i386 > Installing libgtk-3-0:i386 as Depends of libgcr-ui-3-1:i386 > Installing adwaita-icon-theme:i386 as Depends of > libgtk-3-0:i386 > Installing hicolor-icon-theme:i386 as Depends of > adwaita-icon-theme:i386 > Installing gtk-update-icon-cache:i386 as Depends > of adwaita-icon-theme:i386 > Installing librsvg2-common:i386 as Recommends of > adwaita-icon-theme:i386 > Installing librsvg2-2:i386 as Depends of > librsvg2-common:i386 > Installing libcairo-gobject2:i386 as Depends > of librsvg2-2:i386 > Installing libpango-1.0-0:i386 as Depends of > librsvg2-2:i386 > Installing fontconfig:i386 as Depends of > libpango-1.0-0:i386 > Installing libharfbuzz0b:i386 as Depends of
Bug#1035742: lintian-brush: excessive dependencies
Hi Martin-Éric, On Mon, May 08, 2023 at 05:56:47PM +0300, Martin-Éric Racine wrote: > lintian-brush currently Depends on or Recommends packages that pull a large > part of GNOME. > > This is excessive, especialy for a CLI tool. Please demote some of these to > mere Suggests. Thanks for the bug report. Can you be more specific - which packages is it pulling in that are unexpected? lintian-brush has a Suggests on gnome-pkg-tools, but none of its hard dependencies/recommends should (transitively) depend on GNOME. Jelmer
Bug#1032623: vcswatch: should not raise error on repos > 1GiB in size
retitle 1032623 vcswatch: should not raise error on repos > 1GiB in size thanks My understanding is that the restriction on 1Gb in size for repositories was recently introduced and is intentional (due to disk constraints on the host where vcswatch runs?).
Bug#1032623: lintian-brush: vcswatch should not raise error on repos > 1GiB in size
reassign 1032623 qa.debian.org thanks On Fri, Mar 10, 2023 at 12:23:06PM +0100, Diederik de Haas wrote: > I'm not sure this is the right package, but filed it against > lintian-brush as it contains vcswatch.py. > lintian-brush just consults vcswatch. It's not what actually contains the vcswatch implementation.
Bug#1030734: link to upstream bug tracker and repository
Hi Raphael, On Sat, Feb 25, 2023 at 03:53:28PM +0100, Raphael Hertzog wrote: > On Mon, 06 Feb 2023, Jelmer Vernooij wrote: > > A large number of Debian packages now has upstream metadata, including > > links to > > upstream repositories (Repository-Browse) and bugtrackers (Bug-Database / > > Bug-Submit). Would it be possible to link to those from tracker? > > It's of course possible but is there something already extracting all > those values and making them available in a convenient way? Maybe UDD? They're actually already available in UDD: udd=> select key, value from upstream_metadata where source = 'dulwich'; key| value ---+-- Bug-Database | https://github.com/dulwich/dulwich/issues Bug-Submit| https://github.com/dulwich/dulwich/issues/new Repository| https://github.com/dulwich/dulwich.git Repository-Browse | https://github.com/jelmer/dulwich Security-Contact | https://github.com/dulwich/dulwich/tree/HEAD/SECURITY.md (5 rows) udd=> > Otherwise we first need to implement something like that which can be a > bit of a pain. > > Usually the tracker fetches some external file and turns it into PackageData > entries that can then be easily displayed for example with a > LinksPanel.ItemProvider to add links in the "Links" panel on the right. > > If we have to extract the upstream metadata on our own, then we should > modify distro_tracker/extract_source_files/ to extract it and add some > new Task to parse those files after they have been extracted (or do it > directly in extract_source_files but that would be a scope expansion for > that Django application). > > FWIW, I don't plan to work on this (at least not in the short term) but > I'll happily review MR and answer questions. I might spend some time on this, but would appreciate any further hints on where to add this if the information is available in UDD. Jelmer
Bug#1031944: ITP: python-aioredlock -- asyncio implementation of the redlock algorithm
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: python-aioredlock Version : 0.7.3 Upstream Contact: Joan Vilà Cuñat * URL : https://github.com/joanvila/aioredlock * License : MIT Programming Lang: Python Description : asyncio implementation of the redlock algorithm This Python module provides an async implementation of the redis Redlock algorithm, which provides a Distributed Lock Manager.
Bug#1021582: closed by Piotr Ożarowski (fixed in 1.0.4-1)
On Tue, Feb 21, 2023 at 06:12:30PM +, Debian Bug Tracking System wrote: > Date: Tue, 21 Feb 2023 19:10:43 +0100 > From: Piotr Ożarowski > To: 1021582-d...@bugs.debian.org > Subject: fixed in 1.0.4-1 > > Source: pytest-aiohttp > Source-Version: 1.0.4-1 > > ups, looks like I hijacked your ITP. Sorry. > If you want to comaintain or take over this package, just update it in > DPT repo. > > I needed this package as a build dependency for another package and > apparently didn't check WNPP close enough No worries, all good - thanks for packaging it! Your package ended up in the archive before I managed to do duplicate work on it. Cheers, Jelmer
Bug#1031679: lintian: d/rules: should suggest using `execute_before/_after_dh_command` instead of `override_dh_command`
On Mon, Feb 20, 2023 at 03:48:00PM +0100, Christoph Berg wrote: > Re: Gioele Barabucci > > execute_after_dh_clean: > > touch this_strange_file > > The downside of this is that it makes backporting to buster-and-older > harder since it doesn't have the required debhelper version yet. It might make sense to only give this warning for packages that are already on >= 13? Jelmer
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Thu, Feb 09, 2023 at 02:15:42PM -0700, Sean Whitton wrote: > Hello, > > On Fri 03 Feb 2023 at 05:24PM GMT, Jelmer Vernooij wrote: > > > Package: debian-policy > > Severity: wishlist > > > > Policy currently describes Vcs-* headers as something optional, but stops to > > endorse a particular Vcs. > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > specifically here. Apart from technical arguments, it's the vcs that the > > majority of packages in the archive uses - and thus will have the better > > tooling, less of a learning curve for other contributors, etc. > > > > There are very few holdouts of other vcses in the archive. I count 62 > > (ignoring those with an alioth URL): > > > > * 26 on Svn > > * 3 on Cvs > > * 4 on Hg (2 are hg/hg-buildpackage) > > * 39 on bzr (half of these are actually bzr and related packages, which I > > maintain) > > This strikes me as a matter for devref not Policy? I've created a PR for devref - https://salsa.debian.org/debian/developers-reference/-/merge_requests/41 Are you saying that it doesn't belong in policy because it'd be a recommendation rather than a must/should (at this point?), or because it's more about the workflow inside of Debian than package contents? Cheers, Jelmer
Bug#1029750: Needs Depends: python3-breezy, python3-ruamel.yaml
Since somebody just asked upstream: this can be resolved by simply adding python3-breezy and python3-ruamel.yaml to the Depends line for the binary package in debian/control. See https://salsa.debian.org/jelmer/upstream-ontologist/-/blob/debian/master/debian/control Unless somebody beats me to it, I'll probably make this change this weekend.
Bug#1030879: ognibuild: FTBFS randomly (failing tests)
On Wed, Feb 08, 2023 at 07:06:16PM +0100, Santiago Vila wrote:
> ==
> ERROR: test_tee (tests.test_logs.TestCopyOutput.test_tee)
> --
> Traceback (most recent call last):
> File "/<>/.pybuild/cpython3_3.11/build/tests/test_logs.py",
> line 48, in test_tee
> with open(p) as f:
> ^^^
> FileNotFoundError: [Errno 2] No such file or directory:
> '/tmp/tmp7kt8qvlo/foo.log'
>
> --
> Ran 29 tests in 1.676s
>
> FAILED (errors=1)
> E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd
> /<>/.pybuild/cpython3_3.11/build; python3.11 -m unittest
> discover -v
> dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit
> code 13
> make: *** [debian/rules:4: binary-indep] Error 25
> dpkg-buildpackage: error: debian/rules binary-indep subprocess returned exit
> status 2
>
>
> The above is really for version 0.0.18-1 where I tested one more time before
> sending this report (I usually don't do archive-wide rebuilds for unstable),
> but this kind of error also happens in the buildds:
>
> https://buildd.debian.org/status/fetch.php?pkg=ognibuild=all=0.0.16-2=1672869872=0
>
> and also in reproducible-builds:
>
> https://tests.reproducible-builds.org/debian/logs/unstable/armhf/ognibuild_0.0.18-1.build2.log.gz
>
> This seems to be "random", but on the machines I've tested it, the failure
> rate is 100%.
Thanks! I've managed to reproduce this locally; will upload an upstream fix &
updated package in
the next couple of days.
Cheers,
Jelmer
Bug#1030734: link to upstream bug tracker and repository
Package: tracker.debian.org Severity: wishlist A large number of Debian packages now has upstream metadata, including links to upstream repositories (Repository-Browse) and bugtrackers (Bug-Database / Bug-Submit). Would it be possible to link to those from tracker?
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 06:48:13PM +0100, Bill Allombert wrote: > On Fri, Feb 03, 2023 at 05:24:36PM +0000, Jelmer Vernooij wrote: > > Package: debian-policy > > Severity: wishlist > > > > Policy currently describes Vcs-* headers as something optional, but stops to > > endorse a particular Vcs. > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > specifically here. Apart from technical arguments, it's the vcs that the > > majority of packages in the archive uses - and thus will have the better > > tooling, less of a learning curve for other contributors, etc. > > > > There are very few holdouts of other vcses in the archive. I count 62 > > (ignoring those with an alioth URL): > > > > * 26 on Svn > > * 3 on Cvs > > * 4 on Hg (2 are hg/hg-buildpackage) > > * 39 on bzr (half of these are actually bzr and related packages, which I > > maintain) > > I do not quite understand. Surely the package need to use the VCS-* header > corresponding to the VCS used by the repository, whathever it is ? This is not > a matter of preference. Sorry, to be clear I also meant encouraging the use of Git as a Vcs - rather than just of the Vcs-Git header. Jelmer
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
On Fri, Feb 03, 2023 at 06:43:06PM +0100, Jérémy Lal wrote: > Le ven. 3 févr. 2023 à 18:27, Jelmer Vernooij a écrit : > > > Package: debian-policy > > Severity: wishlist > > > > Policy currently describes Vcs-* headers as something optional, but stops > > to > > endorse a particular Vcs. > > > > At this point, it seems uncontroversial to encourage use of Vcs-Git > > specifically here. Apart from technical arguments, it's the vcs that the > > majority of packages in the archive uses - and thus will have the better > > tooling, less of a learning curve for other contributors, etc. > > > > There are very few holdouts of other vcses in the archive. I count 62 > > (ignoring those with an alioth URL): > > > > * 26 on Svn > > * 3 on Cvs > > * 4 on Hg (2 are hg/hg-buildpackage) > > * 39 on bzr (half of these are actually bzr and related packages, which I > > maintain) > > > > Could this remark also address the fact that in most cases, > Vcs-Git == Vcs-Browser, > and thus Vcs-Browser is irrelevant ? I do agree that it is silly to have to have to set nearly the same header for the 90% of packages that are on salsa. It does seem like an orthogonal issue and perhaps best kept separate - there are quite a few Vcs-Git headers set to something other than salsa.debian.org or github.com, which means that Vcs-Browser isn't necessarily always predictable even for Vcs-Git headers. Jelmer
Bug#1030382: encourage Vcs-Git over other Vcs-* headers
Package: debian-policy Severity: wishlist Policy currently describes Vcs-* headers as something optional, but stops to endorse a particular Vcs. At this point, it seems uncontroversial to encourage use of Vcs-Git specifically here. Apart from technical arguments, it's the vcs that the majority of packages in the archive uses - and thus will have the better tooling, less of a learning curve for other contributors, etc. There are very few holdouts of other vcses in the archive. I count 62 (ignoring those with an alioth URL): * 26 on Svn * 3 on Cvs * 4 on Hg (2 are hg/hg-buildpackage) * 39 on bzr (half of these are actually bzr and related packages, which I maintain) Cheers, Jelmer -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 5.3.0-3 Versions of packages debian-policy suggests: pn doc-base
Bug#1029966: ITP: aiojobs -- Python jobs scheduler for managing asyncio background tasks
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: aiojobs Version : 1.1.0 Upstream Contact: Andrew Svetlov. * URL : https://github.com/aio-libs/aiojobs * License : Apache2 Programming Lang: Python Description : Python jobs scheduler for managing asyncio background tasks Job scheduler for managing background tasks (asyncio) in Python The library gives a controlled way for scheduling background tasks for asyncio applications.
Bug#1029722: lintian-brush: upstream-metadata should add Repository line
reassign 1029722 python3-upstream-ontologist thanks On Thu, Jan 26, 2023 at 07:48:18PM +, Jelmer Vernooij wrote: > On Thu, Jan 26, 2023 at 02:43:04PM -0500, Jeremy Bicha wrote: > > On Thu, Jan 26, 2023 at 2:36 PM Jelmer Vernooij wrote: > > > It does actally support setting the Repository field, but it will verify > > > that the upstream repository looks plausible - i.e. that it has at least > > > some tags matching upstream versions. That verification is probably > > > broken for some reason. > > > > It isn't adding the Repository field most of the time that I've been > > running it this month. > > Do you happen to have a few examples handy? Actually, I've reproduced this - assuming you're just seeing this for GitHub repositories. Jelmer
Bug#1029722: lintian-brush: upstream-metadata should add Repository line
On Thu, Jan 26, 2023 at 02:43:04PM -0500, Jeremy Bicha wrote: > On Thu, Jan 26, 2023 at 2:36 PM Jelmer Vernooij wrote: > > It does actally support setting the Repository field, but it will verify > > that the upstream repository looks plausible - i.e. that it has at least > > some tags matching upstream versions. That verification is probably > > broken for some reason. > > It isn't adding the Repository field most of the time that I've been > running it this month. Do you happen to have a few examples handy? Jelmer
Bug#1029722: lintian-brush: upstream-metadata should add Repository line
tags 1029722 +confirmed severity 1029722 normal thanks On Thu, Jan 26, 2023 at 12:32:39PM -0500, Jeremy Bicha wrote: > The upstream-metadata-file fixer creates the Repository-Browse line > but not the Repository line. > > Recent versions of git-buildpackage support use that field. For instance: > > gbp clone https://salsa.debian.org/gnome-team/gnome-console --add-upstream-vcs > > For Github and Gitlab, the Repository field is the same as > Repository-Browse but with a .git suffix. It does actally support setting the Repository field, but it will verify that the upstream repository looks plausible - i.e. that it has at least some tags matching upstream versions. That verification is probably broken for some reason. Cheers, Jelmer
Bug#1029727: python-debian: please depend on zstd
On Thu, Jan 26, 2023 at 07:49:28PM +0100, Gianfranco Costamagna wrote:
> Hello, I see dh-cmake FTBFS in Ubuntu due to this:
>
> test_run_debian_rules
> (dhcmake.tests.cmake.DHCMakeTestCase.test_run_debian_rules) ... ok
> test_autopep8 (dhcmake.tests.source_check.SourceCheckTestCase.test_autopep8)
> ... ok
> test_pyflakes (dhcmake.tests.source_check.SourceCheckTestCase.test_pyflakes)
> ... ok
>
> ==
> ERROR: test_run_debian_rules
> (dhcmake.tests.cpack.DHCPackTestCase.test_run_debian_rules)
> --
> Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 121, in
> _custom_decompress
> proc = subprocess.Popen(
>^
> File "/usr/lib/python3.11/subprocess.py", line 1024, in __init__
> self._execute_child(args, executable, preexec_fn, close_fds,
> File "/usr/lib/python3.11/subprocess.py", line 1901, in _execute_child
> raise child_exception_type(errno_num, err_msg, err_filename)
> FileNotFoundError: [Errno 2] No such file or directory: 'unzstd'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/<>/dhcmake/tests/cpack.py", line 200, in
> test_run_debian_rules
> packages = deb822.Packages(f.debcontrol())
>^^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 493, in
> debcontrol
> return self.control.debcontrol()
>^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 367, in
> debcontrol
> return Deb822(self.get_content(CONTROL_FILE))
> ^^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 308, in
> get_content
> f = self.get_file(
> ^^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 260, in
> get_file
> fobj = self.tgz().extractfile(fname)
>^^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 146, in tgz
> buffer = _custom_decompress(['unzstd', '--stdout'])
> ^^
> File "/usr/lib/python3/dist-packages/debian/debfile.py", line 129, in
> _custom_decompress
> raise DebError("error while running command '%s' as subprocess: '%s'" %
> debian.debfile.DebError: error while running command 'unzstd --stdout' as
> subprocess: '[Errno 2] No such file or directory: 'unzstd''
python3-debian has zstd as a Recommends since it work fine without it
and with any package found in Debian. The ch-cmake tests pass fine here without
zstd installed.
On Ubuntu, I believe zstd compression is the default, so it might make
sense for Ubuntu to move zstd from Recommends to Depends.
Cheers,
Jelmer
Bug#999850: Planning to get back to maturin
FWIW I'm planning to get back to maturin, but got distracted packaging pyo3. It'll probably be a week or two before I have time to look at it. If somebody wanted to look at it before then, please say so here. Jelmer
Bug#1028093: warn about python*-dev dependencies breaking cross compilation
On Fri, Jan 06, 2023 at 06:54:43PM +0100, Helmut Grohne wrote: > Joe noticed a repetitive cross build failure. Can we turn that into a > lintian check? > > Preconditions > * A source package builds an architecture-dependent binary package. > * The package Build-Depends: python([0-9.]*|3?(-all))-dev without any >:native or :any qualifier. > > The assumption is that in this case, the package very likely builds a > Python extension module. For doing so, it needs a build architecture > Python interpreter and a host architecture Python development package. > This dependency however will cause both components to be installed for > the host architecture and for the Python interpreter this tends to fail > postinst. > > Instead, it should be Build-Depends: &:native, lib& (where "&" is the > package name previously used). The :native qualifier will cause the > interpretr to be installed for the build architecture and the second > dependency will pull the host architecture development package. For > native builds, there is no difference as the first package depends on > the second. > > This transformation is quite mechanical, affects many packages and helps > cross building a lot. I suppose that this could be automated by the > janitor. >From the Janitor's point of view, it would be easiest if these were included in the multi-arch hint output (perhaps as a new type of hint) - since then it would just be another case to handle in apply-multiarch-hints. Cheers, Jelmer
Bug#1025984: watch: add json output
On Fri, Dec 23, 2022 at 11:10:18AM +0100, Lucas Nussbaum wrote: > On 12/12/22 at 21:26 +0000, Jelmer Vernooij wrote: > > Package: qa.debian.org > > Severity: wishlist > > > > It would be great if watch had a json mode, like vcswatch does. > > > > E.g. allowing the retrieval of > > https://qa.debian.org/cgi-bin/watch?package=foo=1 to get the watch > > status for package foo. > > Hi, > > Note that this CGI just queries UDD. If this request is related to your > work on Janitor, I wonder if it would be better for you to run a private > UDD mirror, or query the public UDD mirror using SQL? Yeah, the Janitor uses UDD for most of its scheduling. :) I'm planning to use this for one-off fetches. Jelmer
Bug#1026331: lintian-brush: autopkgtest regression: test_matches_package_version
fixed 1026331 0.145 thanks On Sun, Dec 18, 2022 at 06:10:30PM +0100, Paul Gevers wrote: > Source: lintian-brush > Version: 0.144 > Severity: serious > User: debian...@lists.debian.org > Usertags: regression > > Dear maintainer(s), > > With a recent upload of lintian-brush the autopkgtest of lintian-brush fails > in testing when that autopkgtest is run with the binary packages of > lintian-brush from unstable. It passes when run with only packages from > testing. In tabular form: > >passfail > lintian-brush from testing0.144 > versioned deps [0] from testingfrom unstable > all others from testingfrom testing > > I copied some of the output at the bottom of this report. > > Currently this regression is blocking the migration to testing [1]. Can you > please investigate the situation and fix it? > > More information about this bug and the reason for filing it can be found on > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation This should be fixed in 0.145, which was already in unstable - but apparently hasn't made its way into CI? Jelmer
Bug#1019457: lintian-brush: Is deb-scrub-obsolete worth it?
Hi Jeremy, On Fri, Sep 09, 2022 at 01:55:46PM -0400, Jeremy Bicha wrote: > The Debian Janitor service is opening merge proposals to drop > "obsolete" dependency relations. I'm wondering what the justification > is for this? Does it significantly speed up apt upgrades? > > It's useful for packages to match dependencies and their versions in > debian/control with what's provided in the upstream build system > (meson.build, configure.ac, CMakeLists.txt etc.). > > It's perhaps more developer work to think about whether the versions > are so old that the Janitor will recommend their removal. So if the > Janitor is potentially requiring more developer mental energy, then > it's worth questioning whether it should be making these merge > proposals by default. > > I'm not sure that it's actually "best practice" to be dropping those > package version relationships. > > > For reference, I guess you can add 'gnome-shell' to your ignore list > for this feature. See > https://salsa.debian.org/gnome-team/shell-extensions/gnome-shell-extension-hide-activities/-/merge_requests/4 > for a brief explanation. Sorry for the slow response. Some background: deb-scrub-obsolete "scrubs" a bunch of different things that have become unnecessary with newer Debian versions. By default, it'll drop things that have become unnecessary since $DEB_COMPAT_RELEASE (which defaults to stable - but can be overridden to older versions to ease backporting). There are different categories of changes: * obsolete maintscript entries for upgrades from versions older than that in $compat_release * depends on packages that are essential since $compat_release * build-depends on packages that are build-essential since $compat_release * replacing dependencies on "transitional dummy packages" with the real thing (if satisfiable since $compat_release) * conflicts with packages that are gone since before $compat_release * version constraints in build-depends or depends that are met by the package in $compat_release I think your comments are specifically about the last category, which are admittedly also the most common. (This does remind me that I should probably update the deb-scrub-obsolete manpage with this information) On dropping versioned constraints: The motivation for removing the obsolete version constraints is that for a lot of packages, the version constraint is meaningless (because incorrect) when the minimum version is ancient - and that's arguably worse than no minimum version being specified If you bump minimum versions as you run into build problems and you depend on a minimum version that's not been seen in the wild for years, it's likely the true minimum version is actually more recent, but you wouldn't know if the version in unstable is newer. This means that when e.g. backporting, you can't really rely on the minimum version. While the above may be true for some packages (certainly for a quite a lot of mine), there is another set of packages where these version constraints are better curated to always match whatever upstream defines. The premise that they're meaningless doesn't hold there (assuming upstream keep their dependencies list up to date - but that's a different problem), and they can be helpful in e.g. backporting. My impression is that the packages in e.g. the GNOME team fall into this category. As you may have seen, there is now a --keep-minimum-depends-version flag for deb-scrub-obsolete that disables this last category of changes. Going forward: Two things I will do: * update the deb-scrub-obsolete manpage to document the * add an FAQ item to the janitor page about this Perhaps --keep-minimum-depends-version should be the default, with an option to drop unnecessary minimum depends versions? It would be ideal if there was some way of determining whether a package's minimum version depends were curated in some way (e.g. synced with upstream) so we don't a flag, but I can't think of a good way of doing that. Another approach would be to somehow verify that the minimum versions are correct (by building on a much older Debian and pulling in new packages as necessary? Seems challenging, but perhaps not impossible). Let me know what you think. Cheers, Jelmer
Bug#1025984: watch: add json output
Package: qa.debian.org Severity: wishlist It would be great if watch had a json mode, like vcswatch does. E.g. allowing the retrieval of https://qa.debian.org/cgi-bin/watch?package=foo=1 to get the watch status for package foo.
Bug#1025685: [Pkg-rust-maintainers] Bug#1025685: rust-pyo3: please upgrade to v0.17
On Sun, Dec 11, 2022 at 03:40:59AM +, Peter Michael Green wrote: > I've prepared an upload of verion 0.17 of pyo3 and built/tested breezy with > it. It built successfully the autopkgtest passed. Any objections if I go > ahead and update to this version? No objections. Thanks! Jelmer
Bug#1025057: More details
FWIW I've come across this specific filename before (not sure if it was this package). IIRC it's not just the fact that it's UTF8 but rather that it uses a non-canonical representation of the characters.
Bug#1024788: ITP: setuptools-protobuf -- protocol buffer compilation for setuptools
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij * Package name: setuptools-protobuf Version : 0.1.3 Upstream Author : Jelmer Vernooij * URL : https://github.com/jelmer/setuptools-protobuf * License : Apachev2 Programming Lang: Python Description : protocol buffer compilation for setuptools Plugin for setuptools that adds support for compiling protobuf files. . It can optionally also generate mypy interface files if mypy-protobuf is present.
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
On Wed, Nov 23, 2022 at 08:09:36AM +0100, Roland Clobus wrote:
> Hello Jelmer,
>
> On 22/11/2022 00:49, Jelmer Vernooij wrote:
> > On Mon, Nov 21, 2022 at 09:19:41PM +0100, Roland Clobus wrote:
> > > On 19/11/2022 18:20, Jelmer Vernooij wrote:
> > > > Package: wnpp
> > > > Severity: wishlist
> > > > Owner: Jelmer Vernooij
> > > > X-Debbugs-Cc: debian-de...@lists.debian.org
> > > >
> > > > * Package name: setuptools-gettext
> > > > Version : 0.0.1
> > > > Upstream Author : Breezy Team
> > > > * URL : https://github.com/jelmer/setuptools-gettext
> > > > * License : GPL
> > > > Programming Lang: Python
> > > > Description : Compile .po files into .mo files
> > > >
> > > > This extension for setuptools compiles gettext .po files
> > > > found in the source directory into .mo files and installs them.
> > >
> > > How does this tool differ from 'msgfmt' from 'gettext'?
> >
> > It's a wrapper around msgfmt, but making it convenient to run from
> > setuptools.
> > I'll clarify that in the final description.
>
> Sorry to bother you again.
>
> Today I found the following post:
> https://www.redhat.com/sysadmin/python-subprocess-module
>
> Wouldn't this package effectively be 'subprocess.run("msgfmt")'?
> Or would the package name 'python3-gettext' be more suitable?
It's specifically an extension to setuptools to do these things and integrate
with the python ecosystem. It's /not/ a generic module for compiling gettext
files.
For the latter, the name python3-gettext would indeed be more appropriate and
I'm not sure whether it would be more than a wrapper around subprocess.
Jelmer
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
Hi Roland, On Mon, Nov 21, 2022 at 09:19:41PM +0100, Roland Clobus wrote: > On 19/11/2022 18:20, Jelmer Vernooij wrote: > > Package: wnpp > > Severity: wishlist > > Owner: Jelmer Vernooij > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: setuptools-gettext > >Version : 0.0.1 > >Upstream Author : Breezy Team > > * URL : https://github.com/jelmer/setuptools-gettext > > * License : GPL > >Programming Lang: Python > >Description : Compile .po files into .mo files > > > > This extension for setuptools compiles gettext .po files > > found in the source directory into .mo files and installs them. > > How does this tool differ from 'msgfmt' from 'gettext'? It's a wrapper around msgfmt, but making it convenient to run from setuptools. I'll clarify that in the final description. Jelmer
Bug#1024570: RM: sphinxcontrib-rubydomain -- ROM; broken since 2018, low popcon score, dead upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: 896...@bugs.debian.org Please remove the sphinxcontrib-rubydomain source package. The package has failed to work since at least April 2018 (see bug 896395), it has a popcon score of 3 and is dead upstream (no commits for >10 years). It has no reverse dependencies.
Bug#979257: RabbitVCS status?
tags 979257 +upstream forwarded 979257 https://github.com/rabbitvcs/rabbitvcs/issues/34 thanks There doesn't appear to be much movement on this at all in upstream, the bug has been open since 2014. There is other upstream activity though. Perhaps the best approach would be to drop this specific binary package for bookworm. -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc
Bug#732570: Let's remove it
reassign 732570 ftp.debian.org title 732570 RM: libarch-perl -- RoM; few users, dead upstream user debian-rele...@lists.debian.org usertag 732570 + bsp-2022-11-nl-tilburg thanks Let's remove it - popcon has dropped below 20 at this point (https://qa.debian.org/popcon.php?package=libarch-perl) and I can no longer discern the line for it on the percent graph (https://qa.debian.org/popcon-graph.php?packages=git-all%2Cgit-arch%2Ctla%2Clibarch-perl_installed=on_percent=on_legend=on_date=_date=_date=_fmt=%25Y-%25m=1) The last upstream release is more than 12 years old - https://metacpan.org/dist/Arch/changes libarch-perl by itself is also not useful, it's a library meant to be used by other software - and no reverse dependencies are packaged in Debian. I have some experience with arch, but all arch repositories I knew about have also long since migrated to other VCSes. I think there's an argument that tla itself should be kept around, to at least allow people to be able to access old repositories and migrate away. -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc
Bug#1015914: Uploaded to DELAYED/10
I've also uploaded a NMU to DELAYED/10, please feel free to cancel or let me know here if you prefer not to see that go through. Jelmer -- Jelmer Vernooij PGP Key: https://www.jelmer.uk/D729A457.asc
Bug#1015914: (no subject)
tags 1015914 +patch thanks Hi Paul, Sandro, I've verified that node-clipboard works too, and proposed a PR at https://salsa.debian.org/python-team/packages/sphinx-copybutton/-/merge_requests/2 Cheers, Jelmer
Bug#1024398: lintian-brush: suggests removing moving udebs to oldlibs
tags 1024398 +pending user debian-rele...@lists.debian.org usertag 1024398 + bsp-2022-11-nl-tilburg thanks On Fri, Nov 18, 2022 at 07:37:19PM +, Simon McVittie wrote: > To reproduce: clone source package gdk-pixbuf, reset to > debian/2.42.9+dfsg-1 and run lintian-brush. > > Expected result: libgdk-pixbuf2.0-0-udeb remains in > Section: debian-installer and is not moved to Section: oldlibs. > > Actual result: lintian-brush suggests moving it to oldlibs, > which causes a Lintian warning: > > > W: libgdk-pixbuf2.0-0-udeb udeb: wrong-section-for-udeb oldlibs > > N: > > N: udeb packages should have "Section: debian-installer". > > ... > > I think Lintian is correct here: I would interpret "udebs should be in > Section: debian-installer" as a higher-precedence rule than "transitional > packages should be in Section: oldlibs". Thanks for the detailed bug report - I've committed a fix that should make it into 0.137. Jelmer
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
On Sat, Nov 19, 2022 at 06:43:01PM +0100, Niels Thykier wrote: > Jelmer Vernooij: > > Package: wnpp > > Severity: wishlist > > Owner: Jelmer Vernooij > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: setuptools-gettext > >Version : 0.0.1 > >Upstream Author : Breezy Team > > * URL : https://github.com/jelmer/setuptools-gettext > > * License : GPL > >Programming Lang: Python > >Description : Compile .po files into .mo files > > > > This extension for setuptools compiles gettext .po files > > found in the source directory into .mo files and installs them. > > > > FYI: The upstream URL is a 404. Maybe there is a typo or the repo is still > private? Ah, thanks. It's actually https://github.com/breezy-team/setuptools-gettext
Bug#1024450: ITP: setuptools-gettext -- Compile .po files into .mo files
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: setuptools-gettext Version : 0.0.1 Upstream Author : Breezy Team * URL : https://github.com/jelmer/setuptools-gettext * License : GPL Programming Lang: Python Description : Compile .po files into .mo files This extension for setuptools compiles gettext .po files found in the source directory into .mo files and installs them.
Bug#1023505: include verification steps in commit message for out-of-date-standards-version
Package: lintian-brush Version: 0.133 Severity: wishlist lintian-brush will verify that all conditions documented in the Debian policy upgrade checklist (https://www.debian.org/doc/debian-policy/upgrading-checklist.html) have been met before bumping the Standards-Version. However, this isn't made clear in any way in the Janitor merge proposals or the commits/changelog entries that it creates. It might make sense to list all the individual verification steps in the commit message. I think it'd be a bit verbose to list all the verifications in the changelog message, but perhaps we could at least mention that verification has taken place. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.22.2 ii python3 3.10.6-1 ii python3-asyncpg 0.26.0-1 ii python3-breezy 3.3.0+bzr7661-2 ii python3-debian 0.1.48 ii python3-debmutate0.61 ii python3-distro-info 1.2 ii python3-dulwich 0.20.46-2 ii python3-iniparse 0.5-1 ii python3-iso8601 1.0.2-1 ii python3-levenshtein 0.12.2-2+b2 ii python3-pyinotify0.9.6-2 ii python3-ruamel.yaml 0.17.16-1 ii python3-semver 2.10.2-3 ii python3-tomlkit 0.11.5-1 ii python3-tqdm 4.64.0-2 ii python3-upstream-ontologist 0.1.25-2 Versions of packages lintian-brush recommends: ii debhelper 13.10.1 ii decopy0.2.4.7-0.2 ii dos2unix 7.4.3-1 ii gpg 2.2.40-1 ii lintian 2.115.3 ii ognibuild 0.0.13-1 ii python3-bs4 4.11.1-2 ii python3-docutils 0.17.1+dfsg-2 ii python3-lxml 4.9.1-1+b1 ii python3-markdown 3.4.1-2 Versions of packages lintian-brush suggests: ii brz-debian 2.8.74 ii git-buildpackage 0.9.29 pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 245 -- debconf-show failed
Bug#1023477: ITP: libtypec -- user-space library for accessing USB-C/USB-PD metadata
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libtypec Version : 0.1 Upstream Author : Rajaram Regupathy * URL : https://github.com/Rajaram-Regupathy/libtypec/ * License : MIT Programming Lang: C Description : User-space library for accessing USB-C/USB-PD metadata USB-Type C and USB Power Delivery systems are with multiple specification versions, platform designs and microcontroller vendors to manage data, power and display. This library defines a generic way for userspace System Software on Linux, Android, Chrome OS or Other OSes to build developer tools or other management applications for USB-Type C and USB Power Delivery class devices.
Bug#1023304: salsa: allow changing notifications for packages I maintain / am an uploader for
Package: devscripts Severity: wishlist It would be great if there was a way to easily change the notifications for all salsa projects that I care about. At the moment, I can subscribe to individual packages or change my global settings, but one is too fine grained and the other too broad. Ideally I'd like to subscribe to a subset of packages - e.g. those I am uploader for or maintainer of, or that I ever uploaded. A salsa subcommand seems ideal for this - it can query apt for relevant packages, resolve Vcs-Git URLs, then use the API to change notification settings. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#1021899: wrongly reports a typo for rule execute_before_mh_install
On Sun, Oct 16, 2022 at 09:47:14PM +0200, Pierre Gruet wrote: > In the debian/rules file of the source package jmol, I have a rule called > execute_before_mh_install > and lintian-brush reports a typo-in-debhelper-override-target and changes it > to > execute_before_dh_install > although mh_install is a valid sequence brought up by maven_repo_helper, which > one uses to add Maven coordinates for Java projects. > > Do you think this might get fixed? Thanks for the report! I've committed a fix to master, should hopefully make it into the archive in the next couple of weeks. Cheers, Jelmer
Bug#1021582: ITP: python3-pytest-aiohttp -- Pytest plugin for aiohttp support
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python3-pytest-aiohttp Version : 1.0.4 Upstream Author : aiohttp team * URL : https://github.com/aio-libs/pytest-aiohttp * License : Apache-v2 Programming Lang: Python Description : Pytest plugin for aiohttp support pytest plugin for aiohttp support The library provides useful fixtures for creation test aiohttp server and client. Add asyncio_mode = auto line to pytest configuration (see pytest- asyncio modes for details). The plugin works with strict mode also.
Bug#1021131: Fix national-encoding tag
Package: lintian-brush Version: 0.132 Severity: wishlist Yadd writes in https://salsa.debian.org/jelmer/janitor/-/issues/153: > could Janitor fix this lintian tag? Here is a little script I use for this: > > ```bash > #!/bin/bash > TO="UTF-8"; FILE=$1 > FROM=$(file -i $FILE | cut -d'=' -f2) > if [[ $FROM = "binary" ]]; then > echo "Skipping binary $FILE..." > exit 0 > fi > iconv -f $FROM -t $TO -o $FILE.tmp $FILE; ERROR=$? > if [[ $ERROR -eq 0 ]]; then > echo "Converting $FILE..." > mv -f $FILE.tmp $FILE > else > echo "Error on $FILE" > fi > ``` Running "select information from lintian where tag = 'national-encoding' and package_type = 'source';" in UDD I see 731 issues for this tag. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.22.2 ii python3 3.10.6-1 ii python3-breezy 3.2.2-2+b1 ii python3-debian 0.1.47 ii python3-debmutate0.57 ii python3-distro-info 1.1 ii python3-dulwich 0.20.46-1 ii python3-iniparse 0.5-1 ii python3-iso8601 1.0.2-1 ii python3-ruamel.yaml 0.17.16-1 ii python3-tqdm 4.64.0-2 ii python3-upstream-ontologist 0.1.25-2 Versions of packages lintian-brush recommends: ii debhelper13.9.1 ii decopy 0.2.4.7-0.2 ii dos2unix 7.4.3-1 ii gpg 2.2.39-1 ii lintian 2.115.3 ii ognibuild0.0.13-1 ii python3-asyncpg 0.26.0-1 ii python3-bs4 4.11.1-1 ii python3-docutils 0.17.1+dfsg-2 ii python3-levenshtein 0.12.2-2+b2 ii python3-lxml 4.9.1-1+b1 ii python3-markdown 3.4.1-1 ii python3-pyinotify0.9.6-2 ii python3-semver 2.10.2-3 ii python3-tomlkit 0.9.2-1 Versions of packages lintian-brush suggests: ii brz-debian 2.8.70 ii git-buildpackage 0.9.28 pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 243 -- debconf-show failed
Bug#1021129: deal with fuzz in debian/patches
Package: lintian-brush Version: 0.132 Severity: wishlist lintian-brush should deal better with patch application: * https://janitor.debian.net/cupboard/pkg/ros-robot-model/96756a8d-9272-40d6-ad26-30eb25a43326/ * https://janitor.debian.net/cupboard/pkg/doomsday/8c0583cf-609a-47dc-8273-2be8e441e03f/ * https://janitor.debian.net/cupboard/pkg/jnoisemeter/cd7ef123-502c-4274-9bb4-0b6aaf54a41f/ * https://janitor.debian.net/cupboard/pkg/giada/bbf98d6d-744e-4814-83c7-3e30d23041b4/ -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian-brush depends on: ii devscripts 2.22.2 ii python3 3.10.6-1 ii python3-breezy 3.2.2-2+b1 ii python3-debian 0.1.47 ii python3-debmutate0.57 ii python3-distro-info 1.1 ii python3-dulwich 0.20.46-1 ii python3-iniparse 0.5-1 ii python3-iso8601 1.0.2-1 ii python3-ruamel.yaml 0.17.16-1 ii python3-tqdm 4.64.0-2 ii python3-upstream-ontologist 0.1.25-2 Versions of packages lintian-brush recommends: ii debhelper13.9.1 ii decopy 0.2.4.7-0.2 ii dos2unix 7.4.3-1 ii gpg 2.2.39-1 ii lintian 2.115.3 ii ognibuild0.0.13-1 ii python3-asyncpg 0.26.0-1 ii python3-bs4 4.11.1-1 ii python3-docutils 0.17.1+dfsg-2 ii python3-levenshtein 0.12.2-2+b2 ii python3-lxml 4.9.1-1+b1 ii python3-markdown 3.4.1-1 ii python3-pyinotify0.9.6-2 ii python3-semver 2.10.2-3 ii python3-tomlkit 0.9.2-1 Versions of packages lintian-brush suggests: ii brz-debian 2.8.70 ii git-buildpackage 0.9.28 pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 ii postgresql-common 243 -- debconf-show failed
Bug#1020572: lintian-brush shouldn't add a build dependency to pkg-js-tools
reassign 1020572 python3-debmutate thanks On Mon, Sep 26, 2022 at 07:13:24AM +0200, Yadd wrote: > On 26/09/2022 06:41, Jelmer Vernooij wrote: > > On Fri, Sep 23, 2022 at 03:48:42PM +0200, Yadd wrote: > > > now lintian-brush replaces build dependency to dh-sequence-nodejs by > > > "pkg-js-tools | dh-sequence-nodejs". This change is wrong: > > > dh-sequence-nodejs is provided by dh-nodejs, not pkg-js-tools (which has > > > a lot of dependencies and depends on dh-nodejs). > > > > > > Question, why this change, is dh-sequence-nodejs not enough ? > > > > Do you have an example where it did this? It shouldn't normally do > > this, so perhaps it's hitting some sort of corner case. > > > > Jelmer > > Hi, > > an example here: > https://salsa.debian.org/js-team/node-i18next/-/commit/da05bcd0 > > lintian-brush added a dependency to "pkg-js-tools | dh-sequence-nodejs" > while there were already a dependency to dh-sequence-nodejs Thanks! It looks like debmutate is getting confused by the comments in the control field here, causing it to miss the existing dependency on dh-sequence-nodejs. Previously, it would refuse to touch any file with comments since it wouldn't be able to preserve the comments. The new RTS parser in python-debian now allows editing files while preserving those comments. For the moment, I think debmutate needs to: * properly ignore comments when parsing control fields * refuse to edit any control fields that embed comments Jelmer
Bug#1020572: lintian-brush shouldn't add a build dependency to pkg-js-tools
On Fri, Sep 23, 2022 at 03:48:42PM +0200, Yadd wrote: > now lintian-brush replaces build dependency to dh-sequence-nodejs by > "pkg-js-tools | dh-sequence-nodejs". This change is wrong: > dh-sequence-nodejs is provided by dh-nodejs, not pkg-js-tools (which has > a lot of dependencies and depends on dh-nodejs). > > Question, why this change, is dh-sequence-nodejs not enough ? Do you have an example where it did this? It shouldn't normally do this, so perhaps it's hitting some sort of corner case. Jelmer signature.asc Description: PGP signature
Bug#1019568: lintian-brush: Fixer lintian debian-watch-does-not-check-gpg-signature reformats wrongly
On Mon, Sep 12, 2022 at 10:09:40AM +0200, Mathias Behrle wrote: > running lintian-brush --allow-reformatting > introduced the following change: > > -opts=uversionmangle=s/(rc|a|b|c)/~$1/ \ > -https://pypi.debian.net/zeep/zeep-(.+)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) > +opts=uversionmangle=s/(rc|a|b|c)/~$1/,pgpsigurlmangle=s/$/.asc/,pgpmode=auto > https://pypi.debian.net/zeep > zeep-(.+)\.(?:zip|tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz))) > > Note that the slash between zeep/zeep was replaced by a space. That's correct behaviour as far as I can tell. This is the canonical format as documented in the uscan manpage: • opts=" ... " http://URL matching-pattern [version [script]] • http://URL matching-pattern [version [script]] But the manpage also says: • If the hrefs do not contain directories, you can combine this with the previous entry. I.e., http://URL/matching-pattern . and that's the format that was used in the original watch file you quote. Cheers, Jelmer signature.asc Description: PGP signature
Bug#1019414: prometheus-xmpp-alerts: Datetime format is not the same as what prometheus-alertmanager uses
Hi Craig,
Thanks for the bug report.
On Fri, Sep 09, 2022 at 08:58:55AM +1000, Craig Small wrote:
> prometheus-xmpp-alerts is expecting its datetime to be in UTC, but that
> is not what the prometheus alertmanager uses.
>
> This means basically prometheus-xmpp-alerts does not work with
> prometheus-alermanager which is its main use-case.
>
> I suspect that one or both of the programming teams assumes the servers
> run UTC which is a pretty bad assuption, not sure if it is xmpp-alerts
> fault for hard-coding the timezone or alermanagers fault for not setting
> it. In reality its both.
>
> In my opinion, the xmpp-alerts should accept both a UTC timezone and a
> different timezone.
>
> The file in question is
> /usr/lib/python3/dist-packages/prometheus_xmpp/__init__.py
> with the function parse_timestring
>
> ts = re.sub('\\.([0-9]{6})([0-9]{0,3})Z$', r'.\1Z', ts)
> return datetime.strptime(ts, '%Y-%m-%dT%H:%M:%S.%fZ')
>
> The error message is:
> Sep 08 21:26:39 constantine prometheus-xmpp-alerts[2111702]: ValueError: time
> data '2022-09-08T21:26:09.706263468+10:00' does not match format
> '%Y-%m-%dT%H:%M:%S.%fZ'
>
> which is true, "+10:00" doesn't match "Z", but it does match "%z". Also
> %z understands "Z" too. Oddly enough it doesn't understand any other
> sort of timezone, e.g. K is UTC+10h but that's strptime for you.
>
> You'll also notice that the nanoseconds have not been stripped, again
> because of the assumption of the timezone for the regex.
>
> So the answer is, do timezones properly.
> 1) Make the regex understand both sorts of timezones
> 2) Use %z because that's what its for.
>
> The regex is we either get "Z" or +/-hh:mm so the solution on a single
> line is:
>
> >>> datetime.strptime(re.sub('\\.([0-9]{6})([0-9]{0,3})(Z|[-+][0-9]{1,2}:[0-9]{2})$',
> >>> r'.\1\3',"2022-09-08T21:26:09.706263468+10:00"),
> >>> '%Y-%m-%dT%H:%M:%S.%f%z')
> datetime.datetime(2022, 9, 8, 21, 26, 9, 706263,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=36000)))
> >>> datetime.strptime(re.sub('\\.([0-9]{6})([0-9]{0,3})(Z|[-+][0-9]{1,2}:[0-9]{2})$',
> >>> r'.\1\3',"2022-09-08T21:26:09.706263468Z"), '%Y-%m-%dT%H:%M:%S.%f%z')
> datetime.datetime(2022, 9, 8, 21, 26, 9, 706263, tzinfo=datetime.timezone.utc)
> >>> datetime.strptime(re.sub('\\.([0-9]{6})([0-9]{0,3})(Z|[-+][0-9]{1,2}:[0-9]{2})$',
> >>> r'.\1\3',"2022-09-08T21:26:09.706263468-10:00"),
> >>> '%Y-%m-%dT%H:%M:%S.%f%z')
> datetime.datetime(2022, 9, 8, 21, 26, 9, 706263,
> tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=50400)))
>
> I can provide a patch if required.
I believe this is already fixed upstream. See
https://github.com/jelmer/prometheus-xmpp-alerts/blob/master/prometheus_xmpp/__init__.py#L23
Jelmer
Bug#1019374: deb-scrub-obsolete crashes with AttributeError
On Thu, Sep 08, 2022 at 07:55:16AM +0200, Marcin Owsiany wrote: > Package: lintian-brush > > Please see > https://janitor.debian.net/cupboard/pkg/apt-forktracer/b292a431-c8b4-421b-9c7f-b3555ead4046/ > > Removing run time and build time constraints unnecessary since > busterTraceback (most recent call last): File > "/code/lintian-brush/scripts/deb-scrub-obsolete", line 4, in > main() File "/code/lintian-brush/lintian_brush/scrub_obsolete.py", > line 712, in mainresult = scrub_obsolete( File > "/code/lintian-brush/lintian_brush/scrub_obsolete.py", line 529, in > scrub_obsolete+ release_aliases(release)) File > "/code/lintian-brush/lintian_brush/scrub_obsolete.py", line 471, in > release_aliasesdebian_distro_info.unstable: > 'unstable',AttributeError: 'DebianDistroInfo' object has no attribute > 'unstable'. Did you mean: 'stable'? Thanks for the bug report - this has indeed already been fixed. Feel free to press the "Reschedule' button to get it to reprocess the package again. FWIW The janitor generally runs snapshots of lintian-brush, so whatever is in the archive is usually more stable. If you come across issues on the site, a bug report in salsa is usually best @ https://salsa.debian.org/jelmer/janitor.debian.net/-/issues/new Jelmer signature.asc Description: PGP signature
Bug#761933: Using libroken through heimdal-multidev
On Fri, Sep 02, 2022 at 08:12:10AM +1000, Brian May wrote: > On Sat, Apr 25, 2015 at 04:23:14PM +0000, Jelmer Vernooij wrote: > > I think a separate pkg-config file for libroken would be reasonable. > > Ideally this would be upstream rather than Debian-specific. Let's take > > this to the upstream bug tracker. > > Splitting up libroken into a shared package would probably be good. > > But I don't see this happening anytime spoon. There simply isn't anyone > willing to do the work. Plus there has to be people willing to use it if > the work was done, not convinced that will happen either. > > As this is outside the scope of what I can do as a package maintainer I > have tagged this "wontfix". Yeah, that seems reasonable. The main motivator here was Samba, but it has also gone into the other direction on this - basically just vendoring in a copy of Heimdal, rather than linking against system Heimdal. (I'm personally also no longer involved in either Samba or Heimdal development) signature.asc Description: PGP signature
Bug#1018893: support for unshare in some form
Package: piuparts Severity: wishlist It would be great if piuparts supported root-less operation, ideally in a less complicated way than via podman+docker. Conversation in #debian-qa suggests the are various options for building on top of infrastructure that's provided by other packages, e.g. sbuild, autopkgtest or mmdebootstrap. Jelmer, h01ger: I'd second what helmut said. With mmdebstrap you get the equivalent of "lxc-usernsexec -- lxc-unshare -s 'MOUNT|PID|UTSNAME|IPC' -- /usr/sbin/chroot ./debian-rootfs /bin/bash" but without having to depend on lxc -- You can see a variant of this in the mmdebstrap man page where mmdebstrap is used as a wrapper of debootstrap to fix #829134. That way you can run debootstrap without needing root: mmdebstrap --variant=custom --mode=unshare --setup-hook='env container=lxc debootstrap unstable "$1"' - debian-debootstrap.tar Alternatively, if you want to depend on neither lxc nor mmdebstrap, a number of tools implemented a simple unshare backend already using code like this: https://salsa.debian.org/debian/sbuild/-/blob/main/lib/Sbuild/Utility.pm#L382 or this: https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/virt/autopkgtest-virt-unshare#L131 re-using the unshare functionality of either mmdebstrap, sbuild or autopkgtest would probably be best there was some discussion whether those three tools could share some code here: https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/138#note_306768 unfortunately i don't see how if somebody wants to work on unshare support for piuparts, feel free to ask me questions about unshare or its implementation in mmdebstrap, sbuild or autopkgtest the other people in the know are smcv and jochensp oh and there is this as a standalone replacement: https://gitlab.mister-muffin.de/josch/user-unshare/src/branch/main/user-unshare -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.18.0-4-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages piuparts depends on: ii debootstrap 1.0.127 pn debsums ii libjs-sphinxdoc 4.5.0-4 ii lsb-release 11.2 ii lsof 4.95.0-1 ii mount2.38.1-1 pn piuparts-common ii python3 3.10.6-1 ii python3-debian 0.1.47 Versions of packages piuparts recommends: pn adequate Versions of packages piuparts suggests: pn docker.io pn schroot
Bug#1018822: Exceptions on Python 3.8
package: python3-debian severity: important thanks I'm get exceptions importing the _deb822_repo module on Python 3.8: File "/opt/hostedtoolcache/Python/3.8.13/x64/lib/python3.8/site-packages/debian/copyright.py", line 58, in from debian._deb822_repro import ( File "/opt/hostedtoolcache/Python/3.8.13/x64/lib/python3.8/site-packages/debian/_deb822_repro/__init__.py", line 166, in from debian._deb822_repro.parsing import ( File "/opt/hostedtoolcache/Python/3.8.13/x64/lib/python3.8/site-packages/debian/_deb822_repro/parsing.py", line 12, in from debian._deb822_repro._util import (combine_into_replacement, BufferingIterator, File "/opt/hostedtoolcache/Python/3.8.13/x64/lib/python3.8/site-packages/debian/_deb822_repro/_util.py", line 120, in _bufferingIterator_Base = collections.abc.Iterator[T] TypeError: 'ABCMeta' object is not subscriptable The odd thing is that both 3.7 and 3.9 work fine. signature.asc Description: PGP signature
Bug#1018697: deb-scrub-obsolete: please document the RELEASE names
tags 1018697 +confirmed thanks Hi Martin, Thanks for the bug report. On Mon, Aug 29, 2022 at 09:40:58AM +0200, Martin Quinson wrote: > I am always reluctant to apply the merge requests of deb-scrub-obsolete, > because I'm not sure of which release I cut off while applying these changes. > It would be really helpful if the script could augment the changelog to add > the > release name since which the removed versionning is useless, please. There is a release name in the changelog entry at the moment. Do you have a proposed format/wording for the changelog? > Along the same line, it could be helpful to document in the deb-scrub-obsolete > manpage the list of accepted releases. In particular, I'm wondering whether I > have to use a codename such as bookworm, or whether an alias such as old-old- > stable is acceptable. Both should work, but I've just added a note in the manpage. Thanks! I'll leave the bug report open for the first issue. Cheers, Jelmer
Bug#1018300: ITP: gcloud-aio -- (Asyncio OR Threadsafe) Google Cloud Client Library for Python
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gcloud-aio Version : 7.0.1 Upstream Author : Vi Engineering * URL : https://github.com/talkiq/gcloud-aio/ * License : MIT Programming Lang: Python Description : Async Python Client for Google Cloud Storage asyncio python library for accessing Google Cloud Storage. This is a dependency for the Debian Janitor.
Bug#1014473: vcswatch: track identity of committers of unuploaded commits
Thanks!
It would indeed be great if we could also extract the authors into a proper
JSON structure so downstream consumers like the janitor don't have to implement
that themselves for each VCS type.
On 8 August 2022 17:14:44 CEST, Christoph Berg wrote:
>Re: To Jelmer Vernooij
>> Does that work? I guess we could try extracting the authors
>> (committers?) into a proper json structure if that helps.
>>
>> Helmut was approaching me about extracting even more fields from git,
>> Maintainer, Uploaders, Homepage, updated Vcs info, debian/watch, and
>> expose that for an easier feedback into the packages file without
>> requiring new uploads. That will likely happen shortly. (Mentioning
>> that here since it seems similar.)
>
>Fwiw, that has happened at DebConf, there is now new fields
>"controlfile" and "upstream_metadata" in the json:
>
> {
>"browser": "https://salsa.debian.org/debian/kanyremote;,
>"vcslog": "commit 2461c1171fc9103e2fd9ec946208fe5e1bc2deb7\nAuthor:
> Philipp Huebner \n
>Date: Sat May 28 00:32:06 2022 +0200\n\nUpdated years in
>debian/copyright\n\ncommit a72ff16979f78545d0eb83
>09370e47782536e4fd\nAuthor: Debian Janitor \nDate: Fri
>Sep 24 05:04:54 2021 +\n\nRe
>move obsolete field Name from debian/upstream/metadata (already present in
>machine-readable debian/copyright).\n
>\nChanges-By: lintian-brush\n\ncommit
> 77bcda14a9bc556ecc7d5029ddf82282ff0c3303\nAuthor: Debian Janitor <
>jani...@jelmer.uk>\nDate: Fri Sep 24 05:04:43 2021 +\n\nTrim
>trailing whitespace.\n\nChanges-B
>y: lintian-brush\nFixes: lintian: trailing-whitespace\nSee-also:
>https://lintian.debian.org/tags/trailin
>g-whitespace.html",
>"ci_url": "https://salsa.debian.org/debian/kanyremote/-/pipelines;,
>"last_scan": "2022-08-04 18:18:12+00",
>"issues": null,
>"url": "https://salsa.debian.org/debian/kanyremote.git;,
>"valid_checkout": 1,
>"changelog_version": "8.1-1.2",
>"watchfile":
> "version=4\nhttps://sf.net/anyremote/kanyremote-(.*)\\.tar\\.gz",
>"package": "kanyremote",
>"changelog_distribution": "UNRELEASED",
>"branch": "master",
>"merge_requests": 1,
>"vcs": "Git",
>"dumb_http": null,
>"controlfile": "Source: kanyremote\nSection: kde\nPriority:
> optional\nMaintainer: Philipp Huebner @debian.org>\nBuild-Depends: debhelper-compat (= 13), dh-python,
>python3-all\nStandards-Version: 4.5.1\nRules-Re
>quires-Root: no\nHomepage: http://anyremote.sourceforge.net\nVcs-Git:
>https://salsa.debian.org/debian/kanyremote
>.git\nVcs-Browser: https://salsa.debian.org/debian/kanyremote\n\nPackage:
>kanyremote\nArchitecture: all\nDepends
>: ${misc:Depends},\n ${python3:Depends},\n anyremote (>=
>6.7),\n python3-bluez (>= 0.9.1
>),\n python3-pyqt5\nRecommends: bluez\nDescription: KDE frontend for
>anyRemote\n kAnyRemote package is K
>DE GUI frontend for anyRemote.\n (http://anyremote.sourceforge.net/). The
>overall goal of this project is to\n p
>rovide remote control service on Linux through Bluetooth, InfraRed, Wi-Fi\n or
>TCP/IP connection.",
>"edited_at": null,
>"edited_by": null,
>"hash": "2461c1171fc9103e2fd9ec946208fe5e1bc2deb7",
>"debian_dir": 1,
>"changelog": "kanyremote (8.1-1.2) UNRELEASED; urgency=medium\n\n * Trim
> trailing whitespace.\n * Remove o
>bsolete field Name from debian/upstream/metadata (already present in\n
>machine-readable debian/copyright).\n\
>n -- Debian Janitor Fri, 24 Sep 2021 05:04:43 -",
>"next_scan": "2022-08-12 12:11:00+00",
>"commits": 3,
>"package_version": "8.1-1.1",
>"ci_status": null,
>"status": "NEW",
>"upstream_metadata": "Bug-Database:
> https://sourceforge.net/p/anyremote/discussion/\nBug-Submit:
> https://sourceforge.net/p/anyremote/discussion/\nChangelog:
> https://sourceforge.net/p/anyremote/code/HEAD/tree/kanyremote/trunk/ChangeLog\nRepository:
> svn://svn.code.sf.net/p/anyremote/code/kanyremote/trunk\nRepository-Browse:
> https://sourceforge.net/p/anyremote/code/HEAD/tree/kanyremote/\nRegistration:
> https://sourceforge.net/user/registration\nContact:
> anyrem...@mail.ru\nDocumentation:
> http://anyremote.sourceforge.net/docs.html\nFAQ:
> http://anyremote.sourceforge.net/faq.html;,
>"avatar":
> "https://salsa.debian.org/uploads/-/system/project/avatar/1272/anyremote.png;,
>"tag": "debian/8.1-1.1",
>"error": null
> },
>
>Christoph
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#999850: ITP: maturin -- Build and publish crates with pyo3, rust-cpython and cffi bindings as well as rust binaries as python packages.
This is still waiting for pyo3 to make it through NEW. On 7 August 2022 23:18:12 CEST, Thomas Goirand wrote: >Hi Jelmer, > >Any progress here? It'd be nice if you could update the status if this >package. FYI, it's needed by orjson, which I would also need for >home-assistant (which I'm attempting to package, but not ITP for this yet). > >Cheers, > >Thomas Goirand (zigo) -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#1014956: More understandable text for inconsistent-appstream-metadata-license tag
On Fri, Jul 15, 2022 at 10:15:18AM +, Suman wrote: > Package: lintian > Version: 2.115.2 > Severity: wishlist > X-Debbugs-Cc: su...@protonmail.com > > Dear Maintainer, > inconsistent-appstream-metadata-license , tag gives the below description: > The specified AppStream metadata file specifies a metadata_license field > but this does not match the files in debian/copyright. > > While reading the above, I didnt get the point that upstream metadata > lincese should be added to debiab/copyright too. > > It would have been good if something like the following was included: > > "The upstream metadata_license should be represented in debian/copyright" Is that necessarily the case? The way I read the tag description, it just says there is an inconsistency. It may also be that debian/copyright is correct and metadata_license is incorrect (e.g. because the upstream license changed but AppStream metadata was not updated). Jelmer signature.asc Description: PGP signature
Bug#1014473: vcswatch: track identity of committers of unuploaded commits
Package: qa.debian.org Severity: wishlist X-Debbugs-Cc: m...@debian.org It would be great if vcswatch could track who the committers were of the commits have not yet made it into the archive. I'm curious about this as a way to track the number of janitor commits that have not yet been uploaded, and to find packages I should help upload. (Interested in working on a patch for vcswatch that does this)
