Bug#1076245: lintian-brush: hangs and when killed leaved lock in Git repository

[Jelmer Vernooij]

On Sat, Jul 13, 2024 at 08:38:04PM +0200, Andreas Tille wrote:
> Hi Jelmer,
> 
> Am Sat, Jul 13, 2024 at 02:13:24PM + schrieb Jelmer Vernooij:
> > > This is not only true for this specific package but for *all* packages
> > > I tried in the last couple of weeks.
> > 
> > It looks like it's an issue with one of the fixers that seems to hang. I 
> > think there's three things we need to do here:
> 
> I'm not comfortable with the technical details - so if you say so ...
> sounds reasonable.
>  
> > * Add timeouts for fixers
> 
> This could be a first means to solve the issue.
> 
> > * Handle Ctrl+C more gracefully
> 
> This makes sense in any case.
> 
> > * Fix the actual hanging fixer
> 
> The optimal solution but the first one would be OK for me.
> 
> Can you reproduce the issue at your side?

Yeah, I have managed to.

This appears to be some weird issue in the reqwest crate used in
upstream-ontologist, which causes it to hang.

Seems similar to 
https://stackoverflow.com/questions/73805971/reqwest-post-request-freezes-after-random-amount-of-time

Cheers,

Jelmer

Bug#1076245: lintian-brush: hangs and when killed leaved lock in Git repository

[Jelmer Vernooij]

On Sat, Jul 13, 2024 at 07:55:40AM +0200, Andreas Tille wrote:
> Package: lintian-brush
> Version: 0.155
> Severity: grave
> Justification: renders package unusable
> 
> Hi,
> 
> I'm currently do not use lintian-brush extensively currently (since I
> reduced my packaging work in DPL) term but *always* when using it hangs.
> Not even some ^C in terminal kann bring back some prompt I have to kill
> the process manually or close the terminal.  After this some lock files
> are remaining in the Git repository which need to be manually removed.
> 
> Latest example 
>https://salsa.debian.org/med-team/tao-json
> 
> tao-json(master) $ lintian-brush 
> 
>  88/153
> ^C^C^C^C^C
> 
> This is not only true for this specific package but for *all* packages
> I tried in the last couple of weeks.

It looks like it's an issue with one of the fixers that seems to hang. I think 
there's three things we need to do here:

* Add timeouts for fixers
* Handle Ctrl+C more gracefully
* Fix the actual hanging fixer

Cheers,

Jelmer

Bug#1056435: Patch added

[Jelmer Vernooij]

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", line 
381, in test_equal_list_3
self.assertIsNotNone(p)
AssertionError: unexpectedly None

==
FAIL: test_equal_list_4 (pony.orm.te

Bug#1056435: marked as pending in ponyorm

[Jelmer Vernooij]

Control: tag -1 pending

Hello,

Bug #1056435 in ponyorm reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/ponyorm/-/commit/8a2fe1e6ff88b6f4a02533c82d45f1bd38c8c060


Add python3.12 to list of supported versions. Closes: #1056435


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1056435

Bug#1061102: Not related to xsltproc?

[Jelmer Vernooij]

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

[Jelmer Vernooij]

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  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 
> 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

[Jelmer Vernooij]

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#1051766: lintian-brush: apply-multiarch-hints does not finish

[Jelmer Vernooij]

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#1026331: lintian-brush: autopkgtest regression: test_matches_package_version

[Jelmer Vernooij]

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#979257: RabbitVCS status?

[Jelmer Vernooij]

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

[Jelmer Vernooij]

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&show_installed=on&want_percent=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=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

[Jelmer Vernooij]

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)

[Jelmer Vernooij]

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#1022283: marked as pending in python-wikkid

[Jelmer Vernooij]

Control: tag -1 pending

Hello,

Bug #1022283 in python-wikkid reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/wikkid/-/commit/81ff821dcf412ca065570df47a8ba38607690408


Switches to merge3. Closes: #1022283


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1022283

Bug#1020024: marked as pending in pydoctor

[Jelmer Vernooij]

Control: tag -1 pending

Hello,

Bug #1020024 in pydoctor reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/pydoctor/-/commit/10fcac04892784c9b8d8e7ddb51ae37400ecbf20


Depend on python3-filelock rather than python3-lockfile, following 
python3-cachecontrol. Closes: #1020024


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1020024

Bug#1013485: marked as pending in python-debian

[Jelmer Vernooij]

Control: tag -1 pending

Hello,

Bug #1013485 in python-debian reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-debian-team/python-debian/-/commit/28f640c47e7d49f30772a5247cdb0f59e3ca2cc5


RTS parser: don't add trailing whitespace when setting field values
that start with a newline. Closes: #1013485


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1013485

Bug#1012373: marked as pending in dulwich

[Jelmer Vernooij]

Control: tag -1 pending

Hello,

Bug #1012373 in dulwich reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/dulwich/-/commit/568cc3367f4e298b55a2f1d0ac5e6756a7093b68


Drops unnecessary imports. Closes: #1012373


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1012373

Bug#1002851: xdelta 1.1.3-10.2 merged, nmudiff

[Jelmer Vernooij]

Hi Ian,

Thanks for cleaning up this mess, and apologies for creating it in the
first place... I agree the tooling could & should be better here, but
I still should have caught this while I did the upload.

The changes look good to me.

Jelmer

On Fri, Dec 31, 2021 at 12:09:29AM +, Ian Jackson wrote:
> Hi.  I have just pushed a version of xdelta which resolves the changes
> made in 1.1.3-9.4 with those made in 1.1.3-10.1 (which was mistakenly
> based on 1.1.3-9, omitting the intervening NMU changes).
> 
> The resulting package now has the libraries in the multiarch paths.  I
> think all is probably well, but the package doesn't have
> autopkgtests.  Typing "xdelta" with the .debs installed works so I
> think it's fine ?  I hope some other package's autopkgtests will
> detect it if not.
> 
> Here is the numduff.  It is against 1.1.3-9.4.  I think this should be
> regarded as the nmudiff for both #965890 and #1002851.  Diffs
> involving 1.1.3-10.1 are unreasonably cluttered by autogenerated file
> changes.
> 
> I hope this meets with everyone's approval.
> Happy new year!
> 
> Ian.
> 


> 
> 
> -- 
> Ian JacksonThese opinions are my own.  
> 
> Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
> that is a private address which bypasses my fierce spamfilter.


-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#1000716: More details

[Jelmer Vernooij]

forwarded 1000716 https://github.com/ponyorm/pony/issues/598
thanks

Upstream is working on this. See:

https://github.com/ponyorm/pony/commits/py_3_10_dev
https://github.com/ponyorm/pony/issues/598

Bug#995410: breezy: FTBFS:

[Jelmer Vernooij]

Hi Steve,

On Thu, Sep 30, 2021 at 12:21:53PM -0700, Steve Langasek wrote:
> While tracking a build failure of breezy 3.2.1 in Ubuntu, I found that it is
> currently also reproducible in Debian unstable:

Thanks for the bug report.

> [...]
> ==
> ERROR: 
> breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)
> --
> Traceback (most recent call last):
> testtools.testresult.real._StringException: log: {{{
> 763.552  creating repository in 
> file:///tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path%28WorkingTreeFormat4%29/work/tree/.bzr/.
> 763.553  creating branch  0x7f323de98100> in 
> file:///tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path%28WorkingTreeFormat4%29/work/tree/
> 763.558  trying to create missing lock 
> '/tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)/work/tree/.bzr/checkout/dirstate'
> 763.558  opening working tree 
> '/tmp/testbzr-_zh_moh_.tmp/breezy.tests.per_workingtree.test_workingtree.TestIllegalPaths.test_bad_fs_path(WorkingTreeFormat4)/work/tree'
> }}}
> 
> Traceback (most recent call last):
>   File "/tmp/breezy-3.2.1/breezy/tests/per_workingtree/test_workingtree.py", 
> line 1253, in test_bad_fs_path
> with open(b'tree/subdir/m\xb5', 'wb') as f:
> OSError: [Errno 84] Invalid or incomplete multibyte or wide character: 
> b'tree/subdir/m\xb5'

This looks like a behaviour change on the Python side; it should be
possible to use bytestrings for paths on Linux without those being
valid in the current locale..

> [...]
> ==
> ERROR: 
> breezy.tests.test_plugins.TestPlugins.test_1_2_3__version__with_version_info
> --
> Traceback (most recent call last):
> testtools.testresult.real._StringException: log: {{{
> 853.935  loading plugins!
> 853.935  using _Path('breezy.testingplugins', [], [], ['.'])
> 853.935  Traceback (most recent call last):
>   File "/tmp/breezy-3.2.1/breezy/plugin.py", line 429, in _load_plugin_module
> __import__(_MODULE_PREFIX + name)
> ModuleNotFoundError: No module named 'breezy.testingplugins.plugin'
> 
> 853.935  Unable to load plugin 'plugin' from '.': No module named 
> 'breezy.testingplugins.plugin'
>  WARNING  Unable to load plugin 'plugin' from '.': No module named 
> 'breezy.testingplugins.plugin'
> 853.936  removed breezy.testingplugins from sys.modules
> }}}
> 
> Traceback (most recent call last):
>   File "/tmp/breezy-3.2.1/breezy/tests/test_plugins.py", line 468, in 
> test_1_2_3__version__with_version_info
> plugin = breezy.plugin.plugins()['plugin']
> KeyError: 'plugin'
> 
> [...]
> 
> (There are multiple errors of these two classes in the log, but this seems to
> be the gist of it.)

I've seen one earlier reference to this error - I think it had to do
with a regression introduced by a new version of Python.

Cc'ing Martin, who has more background on the plugin code.

Cheers,

Jelmer

Bug#994223: Processed: retitle 994223 to lintian-brush is unusable

[Jelmer Vernooij]

reassign 994223 python3-breezy
fixed 994223 3.2.0+bzr7543-1
thanks

On Thu, Sep 16, 2021 at 06:18:04AM +, Debian Bug Tracking System wrote:
> > retitle 994223 lintian-brush is unusable
> Bug #994223 [lintian-brush] lintian-brush unusable
> Changed Bug title to 'lintian-brush is unusable' from 'lintian-brush 
> unusable'.
> > thanks
> Stopping processing here.
This isn't a bug in lintian-brush, but in one of its dependencies (breezy).
Once the new version of breezy migrates to testing, this should be fixed.

Bug#988909: Please make sure lintian-brush will migrate to testing (Was: routine-update is marked for autoremoval from testing)

[Jelmer Vernooij]

Hi Andreas,

Thanks for the pointer - I hadn't realized that this bug was still
affecting testing.

How hard would it be to drop support for lintian-brush in
routine-update in testing? It looks like properly fixing this bug is
going to be tricky if it involves going via unstable - it would mean
rolling back several packages in unstable. Dropping lintian-brush is
probably the safest option to avoid impact on routine-update, as I am
not sure I'll be able to get all of that done properly in time.

Sorry :-/

Cheers,

Jelmer

On Fri, Jul 09, 2021 at 08:53:27AM +0200, Andreas Tille wrote:
> Hi Jelmer,
> 
> its only four days left to get lintian-brush migrating.  You definitely
> need to do some action.
> 
> Kind regards
> Andreas.
> 
> On Fri, Jul 09, 2021 at 04:39:03AM +, Debian testing autoremoval watch 
> wrote:
> > routine-update 0.0.6 is marked for autoremoval from testing on 2021-07-13
> > 
> > It (build-)depends on packages with these RC bugs:
> > 988909: lintian-brush: autopkgtest failure and FTBFS
> >  https://bugs.debian.org/988909
> > 
> > 
> > 
> > This mail is generated by:
> > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
> > 
> > Autoremoval data is generated by:
> > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
> > 
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> > 
> 
> -- 
> http://fam-tille.de
> 


signature.asc
Description: PGP signature

Bug#988166: (no subject)

[Jelmer Vernooij]

severity 988166 normal
tags 988166 +upstream
thanks

I've moved Dulwich from Recommends to Depends for the moment. This will
at least work around the issue. 

Ideally we'd keep dulwich as a recommends, but that will require some
investigation and fixes upstream.

Bug#988166: breezy breaks check-manifest autopkgtest: brz: ERROR: No module named 'dulwich'

[Jelmer Vernooij]

On Thu, May 06, 2021 at 09:36:30PM +0200, Paul Gevers wrote:
> With a recent upload of breezy the autopkgtest of check-manifest fails
> in testing when that autopkgtest is run with the binary packages of
> breezy from unstable. It passes when run with only packages from
> testing. In tabular form:
> 
>passfail
> breezy from testing3.2.0-1
> check-manifest from testing0.46-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. Looking at the
> error message, it seems that either package needs an additional
> dependency on dulwich.
> 
> Currently this regression is blocking the migration of breezy to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package? Note, because we're in the freeze for
> bullseye, we need to take a bit of care. I have marked this bug as
> bullseye-ignore because I don't intent this bug to cause the removal of
> check-manifest from bullseye and the autopkgtest failure will keep this
> version of breezy out of bullseye automatically.
> 
> More information about this bug and the reason for filing it can be found 
> on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=breezy
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/check-manifest/12161616/log.gz
> 
> ==
> ERROR: test_get_vcs_files (tests.TestBzr)
> --
> Traceback (most recent call last):
>   File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
> line 992, in test_get_vcs_files
> self._init_vcs()
>   File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
> line 978, in _init_vcs
> self.vcs._init_vcs()
>   File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
> line 1128, in _init_vcs
> self._run('bzr', 'init')
>   File "/tmp/autopkgtest-lxc.g_f8zl9e/downtmp/build.mRe/src/tests.py",
> line 949, in _run
> raise subprocess.CalledProcessError(rc, command[0], output=stdout)
> subprocess.CalledProcessError: Command 'bzr' returned non-zero exit
> status 3.
>  >> begin captured stdout << -
> $ bzr init
> brz: ERROR: No module named 'dulwich'
> You may need to install this Python library separately.
Pretty sure this is a Breezy regression - at the very least it should be
giving a clearer error message.

I'll take a look.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#986510: lintian-brush: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.9 returned exit code 13

[Jelmer Vernooij]

On Fri, Apr 16, 2021 at 09:24:38AM +0200, Andreas Tille wrote:
> I've got a testing-removal warning for routine-update due this bug.  I
> know you are usually very prompt in replying to issues thus I'm simply
> wondering whether you might have missed this bug report.  I personally
> have never dived into lintian-brush but if you give some signal that you
> are not managing to work on this in the next couple of days I could at
> lest seek for help.

Looks like I actually forgot to tag the bug appropriately - it's
alreday fixed. Thanks for the ping, I had indeed missed this.

Jelmer


signature.asc
Description: PGP signature

Bug#972793: marked as pending in hg-git

[Jelmer Vernooij]

Control: tag -1 pending

Hello,

Bug #972793 in hg-git reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/hg-git/-/commit/a26dcacaa646fccbc43cce9829d44c636874858b


Add patch 0003-dulwich-compat.patch: avoid deprecation warning with newer 
versions of Dulwich. Closes: #972793


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/972793

Bug#972793: Patch attached

[Jelmer Vernooij]

The attached patch (also available on
https://salsa.debian.org/python-team/packages/hg-git/-/merge_requests/3)
fixes the compatibility with
the new Dulwich API and should allow both Dulwich and hg-git to
migrate to testing.

I couldn't easily work out how to prevent DeprecationWarnings from
breaking the tests, so I'll file a separate (normal severity) bug
about that.

Tristan, are you happy for me to upload the package with that
change?

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc
=== modified file 'debian/changelog'
--- old/debian/changelog	2020-09-24 06:48:41 +
+++ new/debian/changelog	2020-10-30 00:05:53 +
@@ -1,10 +1,15 @@
 hg-git (0.9.0-2) UNRELEASED; urgency=medium
 
+  [ Ondřej Nový ]
   * d/control: Update Maintainer field with new Debian Python Team
 contact address.
   * d/control: Update Vcs-* fields with new Debian Python Team Salsa
 layout.
 
+  [ Jelmer Vernooij ]
+  * Add patch 0003-dulwich-compat.patch: avoid deprecation warning with newer
+versions of Dulwich. Closes: #972793
+
  -- Ondřej Nový   Thu, 24 Sep 2020 08:48:41 +0200
 
 hg-git (0.9.0-1) unstable; urgency=medium

=== modified file 'debian/control'
--- old/debian/control	2020-09-24 06:48:41 +
+++ new/debian/control	2020-10-30 00:05:53 +
@@ -10,7 +10,7 @@
  python3-mercurial,
  openssh-client,
  python3,
- python3-dulwich,
+ python3-dulwich (>= 0.20.6),
  python3-setuptools,
  unzip,
 Standards-Version: 4.5.0
@@ -23,7 +23,7 @@
 Architecture: all
 Depends:
  python3-mercurial,
- python3-dulwich (>= 0.9.7),
+ python3-dulwich (>= 0.20.6),
  ${misc:Depends},
  ${python3:Depends},
 Description: Git plugin for Mercurial

=== added file 'debian/patches/0003-dulwich-compat.patch'
--- old/debian/patches/0003-dulwich-compat.patch	1970-01-01 00:00:00 +
+++ new/debian/patches/0003-dulwich-compat.patch	2020-10-30 00:05:53 +
@@ -0,0 +1,13 @@
+=== modified file 'hggit/git_handler.py'
+--- old/hggit/git_handler.py	2020-08-13 11:43:06 +
 new/hggit/git_handler.py	2020-10-29 23:50:16 +
+@@ -1113,7 +1113,7 @@
+ 
+ try:
+ new_refs = client.send_pack(path, changed, genpack,
+-progress=callback)
++progress=callback).refs
+ if len(change_totals) > 0:
+ self.ui.status(_(b"added %d commits with %d trees"
+  b" and %d blobs\n") %
+

=== modified file 'debian/patches/series'
--- old/debian/patches/series	2020-08-13 14:15:34 +
+++ new/debian/patches/series	2020-10-30 00:05:53 +
@@ -1,2 +1,3 @@
 0001-Set-explicit-merge-messages.patch
 0002-Silence-git-pull-warning.patch
+0003-dulwich-compat.patch



signature.asc
Description: PGP signature

Bug#952536: Drop support for architectures not supported by upstream?

[Jelmer Vernooij]

I can see two options here:

 1) drop support for architectures not supported by upstream

 2) disable the unsupported architecture check somehow
  * either by setting the environment variable
  * by patching out the check in the source code

I'm not entirely sure what the right thing is for our users; does etcd
actually work on the other platforms and/or do we have the bandwidth
to get it to work there, or would it be safer to just exclude them for
the moment?

Since one can either way set the ETC_UNSUPPORTED_ARCH environment
variable, does this warrant severity serious rather than e.g.
important?

Jelmer

Bug#952348: marked as pending in backupchecker

[Jelmer Vernooij]

Control: tag -1 pending

Hello,

Bug #952348 in backupchecker reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/applications/backupchecker/-/commit/fb813ddef7b5ebbcb83d20b1a2ace77e46350f16


Merge branch 'debian/master' into 'debian/master'

Add dh-python to build depends (Closes: #952348)

See merge request python-team/applications/backupchecker!1


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/952348

Bug#952348: marked as pending in backupchecker

[Jelmer Vernooij]

Control: tag -1 pending

Hello,

Bug #952348 in backupchecker reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/applications/backupchecker/-/commit/b1a032d933318ba4d2c68c3acdb5774564479b58


Add dh-python to build depends (Closes: #952348)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/952348

Bug#950470: breezy still fails with one autopkg test on the binary-indep buid

[Jelmer Vernooij]

severity 950470 important
thanks

On Sun, Feb 02, 2020 at 10:37:41AM +0100, Matthias Klose wrote:
> see
> https://buildd.debian.org/status/fetch.php?pkg=breezy&arch=all&ver=3.0.2-3&stamp=1580478666&raw=0
> 
> ==
> ERROR:
> breezy.tests.per_branch.test_stacking.TestStackingConnections.test_open_stacked_relative(RemoteBranchFormat-v2)
> --
> Traceback (most recent call last):
> testtools.testresult.real._StringException: lost connection during test
> 'breezy.tests.per_branch.test_stacking.TestStackingConnections.test_open_stacked_relative(RemoteBranchFormat-v2)'
> --
> Ran 24171 tests in 6121.269s

I'm going to downgrade the importance of this since the buildds are
happy with the last build.

My suspicion is that there are still some flaky tests, but these
weren't recently introduced so this is not a regression. I'll keep
chasing them down; in the mean time, I think this should not be a
blocker for Breezy 3.0.2-4 migrating to testing.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#950321: lintian-brush: test failures with new lintian 2.48.0

[Jelmer Vernooij]

On Fri, Jan 31, 2020 at 11:47:40AM +0100, Gianfranco Costamagna wrote:
> Source: lintian-brush
> Version: 0.56
> Severity: serious
> 
> Hello, looks like the new lintian removed one renamed tag in its latest 
> version:
>   * Remove data/override/renamed-tags; they are defined in the tag
> declarations now.
> 
> 
> autopkgtest for lintian-brush/0.56: amd64: Regression ♻ , arm64: Regression ♻
> 
> 
> FAIL: fixer test: simple for renamed-tag
> --
> Traceback (most recent call last):
>   File 
> "/tmp/autopkgtest-lxc.ggj8jh3h/downtmp/build.Rym/src/lintian_brush/tests/fixers.py",
>  line 91, in runTest
> self.assertEqual(p.returncode, 0)
> AssertionError: 2 != 0
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/l/lintian-brush/4148249/log.gz
> https://ci.debian.net/data/autopkgtest/testing/arm64/l/lintian-brush/4143693/log.gz
> 
> Do you have a patch for this? I don't know if we have to remove that test, 
> the code or whatever else...
I'm working to move this into a lintian-brush specific file - for
performance reasons. Expect an update shortly.

Jelmer


signature.asc
Description: PGP signature

Bug#936617: Updated on salsa; pending upload

[Jelmer Vernooij]

On Fri, Jan 31, 2020 at 03:50:57AM +0100, Philippe Mathieu-Daudé wrote:
> On Thu, Jan 30, 2020 at 3:27 PM Jelmer Vernooij  wrote:
> >
> > It looks like this package has been ported to Python 3, but has not
> > yet been uploaded. The last changelog entry on salsa
> > (https://salsa.debian.org/philmd-guest/git-publish.git) says:
> >
> > git-publish (1.5.1-1) UNRELEASED; urgency=medium
> >
> >   * Non-maintainer upload.
> >   * Update to git-publish 1.5.1:
> > - few bugfixes
> > - added more options
> > - use Python3
> >
> >  -- Philippe Mathieu-Daudé   Fri, 06 Dec 2019 15:53:10 
> > +0100
> >
> > Philippe, would you like me to sponsor an upload of the package?
> 
> This is very kind of you!
> 
> I updated to git-publish 1.6.0 about a month ago, but then got
> distracted when looking for a sponsor...
> So your help is very much appreciated :)
Thanks! Uploaded to unstable just now.

I've made one minor change, to add the bug # to the changelog. See 
https://salsa.debian.org/philmd-guest/git-publish/merge_requests/1

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#937484: Info received (Taking over)

[Jelmer Vernooij]

Oops - I should have read the earlier part of the this bug better. :-/

gpodder's mtp support appears to have been commented out for a long
time. FWIW, the MTP support in gvfs doesn't appear to work as an
alternative for me - get an error about the filesystem not being
local.

I do actually have a version of the package ported to Python 3, if
that would be useful.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#937484: Taking over

[Jelmer Vernooij]

Hi Hans-Christoph,

I'm interested in pymtp, since gpodder can optionally use it.  Thanks for 
packaging it!

I'll prepare an upload to migrate it to Python3, and will move it to
the Python team.

Cheers,

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#936617: Updated on salsa; pending upload

[Jelmer Vernooij]

It looks like this package has been ported to Python 3, but has not
yet been uploaded. The last changelog entry on salsa
(https://salsa.debian.org/philmd-guest/git-publish.git) says:

git-publish (1.5.1-1) UNRELEASED; urgency=medium

  * Non-maintainer upload.
  * Update to git-publish 1.5.1:
- few bugfixes
- added more options
- use Python3

 -- Philippe Mathieu-Daudé   Fri, 06 Dec 2019 15:53:10 +0100

Philippe, would you like me to sponsor an upload of the package?

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#948958: marked as pending in python-pyscss

[Jelmer Vernooij]

Control: tag -1 pending

Hello,

Bug #948958 in python-pyscss reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/modules/python-pyscss/commit/b1a4e75e475d6d59a82979c52272cd16eae0acdd


Remove pyversions from d/rules, use pybuild pytest

Remove the manual invocation of "pyversions" from debian/rules, to
prevent picking up Python 2 versions during the tests. Replace the
override_dh_auto_test with a more streamlined usage of pybuild pytest
support.

Closes: #948958


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/948958

Bug#947904: ledger2beancount autopkgtest failure with new ledger

[Jelmer Vernooij]

On Wed, Jan 01, 2020 at 09:53:31PM +, plugwash wrote:
> package: ledger2beancount
> version: 1.8-1
> severity: serious
> 
> ledger recently migrated to python 3 (forced by boost dropping python 2
> support), this has broken the ledger2beancount autopkgtest and this is
> blocking ledger from migrating to testing.

It looks like the last upload (in unstable) doesn't actually migrate Python 3,
but just disables Python support altogether. :-(

I'll see if I can do an upload that just disables the Python tests for now.

Cheers,

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#938327: Upstream references

[Jelmer Vernooij]

FWIW Upstream is working on Python 3 support here: 
https://github.com/rabbitvcs/rabbitvcs/issues/279


signature.asc
Description: PGP signature

Bug#936454: No longer depends on python-fastimport

[Jelmer Vernooij]

severity 936454 normal
thanks

Resetting this to normal. As of 0.19.14-1 (uploaded at the same time as the
python-fastimport removal), Dulwich has stopped build-depending on 
python-fastimport.

Bug#941008: loggerhead, multiple dependency issues.

[Jelmer Vernooij]

On Mon, Sep 23, 2019 at 12:50:14PM +0100, peter green wrote:
> Package: loggerhead
> Version: 1.19~bzr479+dfsg-3
> Severity: serious
> 
> Loggerhead has multiple dependency issues.
> 
> The loggerhead source package build-depends on python-subunit which is no 
> longer built by the subunit source package.
> 
> The loggerhead source package build-depends on python-bzrlib.tests || bzr (<< 
> 2.4.0~beta1-2), the former is no longer built by the bzr source package and 
> the latter fails version constraints (the current version of bzr is 
> 2.7.0+bzr6622+brz )
> 
> The loggerhead binary package depends on python-bzrlib, which is no longer 
> built by the bzr source package.
> 
> I notice these issues seem to be fixed in experimental by turning loggerhead 
> into a transitional package to loggerhead-breezy. Should the experimental 
> package simply be uploaded to unstable?
We'll actually do this the other way around, since loggerhead upstream has 
moved to Breezy.

I'm planning to do an upload of loggerhead in the next couple of days that 
switches it to be Python3 and based on Breezy.

Loggerhead-breezy will then become a dummy transitional package that upgrades 
to loggerhead.

Jelmer

Bug#932584: Epydoc and Pydoctor

[Jelmer Vernooij]

Hi Kenneth, Ian,

On Wed, Jul 31, 2019 at 08:45:54PM -0500, Kenneth Pronovici wrote:
> On Wed, Jul 31, 2019 at 10:46 AM Ian Jackson
>  wrote:
> > > Otherwise, I will see if I can determine how well the package works
> > > without epydoc installed.  If it works (i.e. doesn't blow up) and I
> > > don't hear back with other instructions, I will eventually NMU my
> > > changes to remove the epydoc dependency.   Given that I haven't gotten
> > > any replies for more than 18 months now, I won't wait that long before
> > > doing this NMU.
> >
> > That sounds really good to me for now.  I think you can do this NMU
> > whenever you like.
> 
> I tested pydoctor against my own cedar-backup2 code, which I never converted
> away from Epydoc since it's Python 2-only.   It seems to work fine:
> 
> mars:~/projects/dev/software/cedar-backup2> pydoctor CedarBackup2/
> adding directory 
> /home/pronovic/projects/dev/software/cedar-backup2/CedarBackup2
> 41/41 modules processed 0 warnings
> WARNING: guessing CedarBackup2 for project name
> writing html to apidocs using pydoctor.templatewriter.writer.TemplateWriter
> starting ModuleIndexPage ...
> Error trying to import 'epytext' parser:
> 
> ImportError: No module named epydoc.markup.epytext
> 
> Using plain text formatting only.
> took 0.006452s
> starting ClassIndexPage ... took 0.011512s
> starting IndexPage ... took 0.002281s
> starting NameIndexPage ... took 0.079562s
> starting UndocumentedSummaryPage ... took 0.004314s
> 125/125 pages written
> Generating objects inventory at apidocs/objects.inv
> 
> The generated HTML documentation is legible, if not as pretty as it
> would have been before.  Given that it works, I am going to NMU the
> version of the package that doesn't depend on epydoc.  I'll also
> create a PR on salsa.  On salsa, master has diverged from the released
> package, but I am *not* going to integrate those changes, because I
> don't want to take responsibility for them.

Sorry for the delayed reply and thanks for working on Pydoctor without epydoc.
I'm happy for you to NMU a new version, but can also merge a patch and do an
upload - as you prefer.

As far as I know pydoctor upstream is pretty dormant, but not completely
inactive. Pull requests do get looked at and there is the occasional fix to
keep it running, but that's about it.

Cheers,

Jelmer

Bug#930213: Only happens when used with paramiko

[Jelmer Vernooij]

severity 930213 normal
thanks

This only happens when bzr is used with paramiko and if there are SSH agent
keys. You should be able to work around this by setting
BZR_SSH=openssh in your environment or uninstalling paramiko.

Bug#913037: Bug #913037 in dulwich marked as pending

[Jelmer Vernooij]

Control: tag -1 pending

Hello,

Bug #913037 in dulwich reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/python-team/modules/dulwich/commit/0edda7e0191013931b8bab96e1145caeaefc54ed


Add patch 02_skip_flappy_test: Skip flappy test 
dulwich.tests.test_porcelain.PushTests.test_simple, which is subject to a race 
condition. Closes: #913037



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/913037

Bug#913037: (no subject)

[Jelmer Vernooij]

retitle 913037 "test dulwich.tests.test_porcelain.PushTests.test_simple 
contains race condition"
thanks

This is not a python3.7-specific issue, but a test that contains a
race condition that means it occasionally fails. This is reproducible
on other python versions as well (when running the test repeatedly).


signature.asc
Description: PGP signature

Bug#913771: syncthing-gtk: unsatisfiable dependency on non-existent gir-1.2-glib-2.0

[Jelmer Vernooij]

Hi Steve,

On Wed, Nov 14, 2018 at 03:16:32PM -0800, Steve Langasek wrote:
> The syncthing-gtk package is uninstallable, because it depends on
> gir-1.2-glib-2.0, which does not exist.  The correct spelling of this
> package name is gir1.2-glib-2.0.  Please find a patch attached.
Argh, that was very sloppy of me. I should have known better than to
add that missing dependency after the sbuild. :(

Thanks for the patch!

Jelmer


signature.asc
Description: PGP signature

Bug#898591: lptools: Intent to remove from Debian

[Jelmer Vernooij]

On Sun, May 13, 2018 at 08:25:39PM -0400, Jeremy Bicha wrote:
> Source: lptools
> Version: 0.2.0-2
> Severity: serious
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs pygtk
> Tags: sid buster
> X-Debbugs-CC: x...@debian.org, jel...@debian.org
> 
> lptools depends on the unmaintained pygtk which the Debian GNOME team is 
> trying to remove from Debian.
> 
> It looks like lptools itself is unmaintained. Therefore, I intend to file a 
> removal bug for lptools. Please reply immediately to let me know if you 
> approve or object.
Huh, what suggests it's unmaintained? It hasn't been changed in the
last couple of years, but it's also been functioning well and there
are no open critical bugs against it.

There are just two scripts (out of 18) in lptools that use pygtk. We
could probably just drop those.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#883743: bzr: FTBFS on armel

[Jelmer Vernooij]

On Wed, Dec 06, 2017 at 05:45:11PM -0800, Vagrant Cascadian wrote:
> Package: bzr
> Version:  2.7.0+bzr6622-9
> Severity: serious
> Tags: patch
> 
> The last armel bzr build failed to build from source, and I've tried to
> reproduce the issue unsuccessfully.
> 
>   
> https://buildd.debian.org/status/fetch.php?pkg=bzr&arch=armel&ver=2.7.0%2Bbzr6622-9&stamp=1510195017&raw=0
> 
> I tried building it on abel.debian.org, and it failed in a *different*
> way, complaining about unicode issues. Setting LC_ALL=C.UTF-8 seemed to
> fix that issue for me.
> 
> Forcing the test suite to run with the C.UTF-8 locale, available in all
> recent versions of Debian (and even some pretty old ones), at least
> fixed the unicode issues when run on abel.debian.org:
> 
> --- rules.orig2017-12-06 17:41:18.206442819 -0800
> +++ rules 2017-12-06 17:41:57.290537132 -0800
> @@ -24,6 +24,8 @@
>   BZR_PLUGIN_PATH=-site:-user \
>   BZR_DISABLE_PLUGINS=launchpad \
>   PYTHONPATH=$(wildcard $(CURDIR)/build/lib.*-$(PYVERSION)) \
> + LC_ALL=C.UTF-8 \
> + LANG=C.UTF-8 \
>   $(CURDIR)/build/scripts-$(PYVERSION)/bzr -Derror selftest -v 
> --parallel=fork
>  endif
>  
> 
> Maybe it's worth re-uploading with the above patch.
What failure do you get without LC_ALL=C.UTF-8 and LANG=C.UTF-8 set?

I'd rather avoid setting variables so that we can actually catch
and fix locale-related problems.


signature.asc
Description: PGP signature

Bug#883743: bzr: FTBFS on armel

[Jelmer Vernooij]

On Wed, Dec 06, 2017 at 05:45:11PM -0800, Vagrant Cascadian wrote:
> The last armel bzr build failed to build from source, and I've tried to
> reproduce the issue unsuccessfully.
> 
>   
> https://buildd.debian.org/status/fetch.php?pkg=bzr&arch=armel&ver=2.7.0%2Bbzr6622-9&stamp=1510195017&raw=0
> 
> I tried building it on abel.debian.org, and it failed in a *different*
> way, complaining about unicode issues. Setting LC_ALL=C.UTF-8 seemed to
> fix that issue for me.
Thanks for reporting this.

Can you reproduce the issue once you set LC_ALL=C.UTF-8 ?

The delta between -8 and -9 is minimal and not related to the test
that failed, so I'm wondering if this is a spurious failure (timing?) of some
sort or perhaps a regression introduced by a dependency.

Jelmer


signature.asc
Description: PGP signature

Bug#868542: marked as pending

[Jelmer Vernooij]

tag 868542 pending
thanks

Hello,

Bug #868542 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


https://anonscm.debian.org/cgit/python-modules/packages/dulwich.git/commit/?id=e0eb92b

---
commit e0eb92b4f51b3ee27a8850ea7e0e651baa14971e
Author: Jelmer Vernooij 
Date:   Mon Jul 24 23:51:11 2017 +

Stop shipping pypy C extensions in python-dulwich. Closes: #868542

diff --git a/debian/changelog b/debian/changelog
index 4084039..4840a64 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+dulwich (0.17.3-2) UNRELEASED; urgency=medium
+
+  * Stop shipping pypy C extensions in python-dulwich. Closes: #868542
+
+ -- Jelmer Vernooij   Mon, 24 Jul 2017 23:51:07 +
+
 dulwich (0.17.3-1) unstable; urgency=medium
 
   * New upstream release.

Bug#834654: Test failures

[Jelmer Vernooij]

I've uploaded a new Debian version to unstable packaging RC1.
Unfortunately there are a test failures on various
architectures. :(

Note that not all of these are release architectures, and that make
bails out once tests in one directory fail. Builders are still
running, but so far I've seen:

i386/kfreebsd-i386/powerpc:
FAIL: check-basic
FAIL: check-context
FAIL: check-spnego
FAIL: check-ntlm

hppa/powerpcspe:
FAIL: check-kdc
FAIL: check-kdc-weak

m68k:
FAIL: getifaddrs-test

Unfortunately I won't a lot more time to spend on the Heimdal package
before January. If somebody has a chance to help debug these, that
would be great.


signature.asc
Description: PGP signature

Bug#834654: 7.0.1

[Jelmer Vernooij]

A brief update on this: a RC release has happened upstream, which is
versioned "7.0.1". A stable release (which will be "7.1") is in the
works, but may not make it before stretch.


signature.asc
Description: PGP signature

Bug#847634: irssi-plugin-quassel: libquassel_core.so not in expected location

[Jelmer Vernooij]

On Sat, Dec 10, 2016 at 05:08:00AM +0100, Diederik de Haas wrote:
> Package: irssi-plugin-quassel
> Version: 0~git20160612-1
> Severity: grave
> Justification: renders package unusable
> 
> I followed the instructions from the README.md on github, but when I got
> to the '/load quassel' part I got the following error:
> Irssi: Error loading module quassel/core:
> /usr/lib/x86_64-linux-gnu/irssi/modules/libquassel_core.so: cannot open
> shared object file: No such file or directory
> 
> And that is because libquassel_core.so is stored at
> /usr/lib/irssi/modules/libquassel_core.so
> 
> For completeness sake I also tried '/connect ' and got:
> Irssi: Unknown chat protocol: Quassel
> 
> Therefor I set the severity to grave as I can't connect to my quassel
> core and would be surprised if others could.
Thanks for the bug report and the patch.

Note that this is caused by a change in the irssi package; previously
plugins were in the location the plugin was using
(see https://packages.debian.org/jessie/amd64/irssi-plugin-otr/filelist)
so this will need to introduce a versioned dependency on irssi.

Jelmer


signature.asc
Description: PGP signature

Bug#845335: bzr issue

[Jelmer Vernooij]

On Wed, Dec 07, 2016 at 05:47:52PM +, Ben Dooks wrote:
> The "bzr: ERROR: exceptions.TypeError: first argument must be string or
> compiled pattern" is still there after updating.
> 
> bzr is already the newest version (2.7.0+bzr6619-1).
This has been fixed. The latest version of bzr (currently in unstable, doesn't
seem to have made it to testing) is 2.7.0+bzr6619-3.

Bug#820965: [Pkg-samba-maint] Bug#820965: marked as pending

[Jelmer Vernooij]

On Wed, Sep 14, 2016 at 11:51:14AM +0300, Vlad Orlov wrote:
> Hi,
> 
> I'd like to know if there's any progress on uploading the new
> version to jessie-security. Just want to check if the update
> would fix https://bugs.debian.org/831851 as well.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836795 for the current
discussion.

Jelmer

Bug#820965: marked as pending

[Jelmer Vernooij]

tag 820965 pending
thanks

Hello,

Bug #820965 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=d4092f0

---
commit d4092f0849e2ec1c92214da90d052c7947913d19
Author: Jelmer Vernooij 
Date:   Sun Sep 4 14:21:37 2016 +

New upstream release.

diff --git a/debian/changelog b/debian/changelog
index 91abc96..711b647 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+samba (2:4.2.14+dfsg-0+deb8u1) UNRELEASED; urgency=high
+
+  * New upstream release.
+   + Fixes CVE-2016-2119: Client side SMB2/3 required signing can be 
downgraded.
+   + Various fixes for regressions introduced by the 4.2.10 security fixes.
+   Closes: #820965, #827141
+
+ -- Jelmer Vernooij   Sun, 04 Sep 2016 14:21:35 +
+
 samba (2:4.2.10+dfsg-0+deb8u3) jessie-security; urgency=high
 
   * Non-maintainer upload by the Security Team.

Bug#820965: marked as pending

[Jelmer Vernooij]

tag 820965 pending
thanks

Hello,

Bug #820965 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=d29a694

---
commit d29a694496549410931c88fccb18961399203c93
Author: Jelmer Vernooij 
Date:   Sun Sep 4 14:21:37 2016 +

New upstream release.

diff --git a/debian/changelog b/debian/changelog
index 91abc96..8374733 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+samba (2:4.2.12+dfsg-0+deb8u1) UNRELEASED; urgency=high
+
+  * New upstream release.
+   + Fixes CVE-2016-2119: Client side SMB2/3 required signing can be 
downgraded.
+   + Various fixes for regressions introduced by the 4.2.10 security fixes.
+   Closes: #820965, #827141
+
+ -- Jelmer Vernooij   Sun, 04 Sep 2016 14:21:35 +
+
 samba (2:4.2.10+dfsg-0+deb8u3) jessie-security; urgency=high
 
   * Non-maintainer upload by the Security Team.

Bug#812264: marked as pending

[Jelmer Vernooij]

tag 812264 pending
thanks

Hello,

Bug #812264 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=e23b11c

---
commit e23b11c3bccb7e463ffb51c86f3321cca63d57a9
Author: Jelmer Vernooij 
Date:   Mon Jul 4 12:23:25 2016 +

Add patch gcc_6.patch, fixing compatibility with gcc 6. Closes: #812264

diff --git a/debian/changelog b/debian/changelog
index 02eaf36..06b215c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+samba (2:4.4.4+dfsg-3) UNRELEASED; urgency=medium
+
+  * Add patch gcc_6.patch, fixing compatibility with gcc 6.
+Closes: #812264
+
+ -- Jelmer Vernooij   Mon, 04 Jul 2016 12:20:56 +
+
 samba (2:4.4.4+dfsg-2) unstable; urgency=medium
 
   * Mask samba-ad-dc.service unless needed (Closes: #828137)

Bug#821070: marked as pending

[Jelmer Vernooij]

tag 821070 pending
thanks

Hello,

Bug #821070 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

http://git.debian.org/?p=pkg-samba/samba.git;a=commitdiff;h=fcb7933

---
commit fcb793364de9bda9fae4a05476cf414f46126bc5
Author: Jelmer Vernooij 
Date:   Sat Apr 16 00:19:06 2016 +

Bump version in Replaces: samba-libs for samba-vfs-modules to 4.3.2+dfsg-1, 
to fix jessie->stretch upgrades. Closes: #821070

diff --git a/debian/changelog b/debian/changelog
index 9b028f9..c17061b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,6 +7,8 @@ samba (2:4.3.8+dfsg-1) UNRELEASED; urgency=medium
+ Drop patch
  security-2016-04-12-prerequisite-v4-3-regression-fixes.metze01.txt,
  now included upstream.
+  * Bump version in Replaces: samba-libs for samba-vfs-modules to
+4.3.2+dfsg-1, to fix jessie->stretch upgrades. Closes: #821070
 
  -- Jelmer Vernooij   Sat, 16 Apr 2016 12:18:36 +
 

Bug#815331: Still reproducible?

[Jelmer Vernooij]

severity 815331 important
tags 815331 +moreinfo
thanks

Can you still reproduce this with current pypy? It doesn't segfault
for me.


signature.asc
Description: PGP signature

Bug#814539: [Pkg-bazaar-maint] Bug#814539: bzrtools: Uninstallable with current sid bzr and python-bzrlib (2.7.0-2)

[Jelmer Vernooij]

On Fri, Feb 12, 2016 at 09:34:03PM +0100, Vincent Ladeuil wrote:
> > Agustin Martin  writes:
> 
> > Package: bzrtools
> > Version: 2.6.0-2
> > Severity: serious
> > Justification: uninstallable in sid
> 
> > Dear Maintainer,
> 
> > Seems that bzrtools needs upgrading for newer bzr package (2.7.0-2),
> 
> Fix pushed at
> https://anonscm.debian.org/bzr/pkg-bazaar/bzrtools/unstable/ as revno
> 761
> 
> patch attached.
> 
> Tested locally with adt-run .// -U --- lxc -es adt-sid
The version check also needs to be updated:

Plugin "Bzrtools" is not up to date with installed Bazaar version
2.7.0.
There should be a newer version of Bzrtools available, e.g. 2.7.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#812398: openldap: FTBFS: can't read /usr/lib/x86_64-linux-gnu/libhdb.la

[Jelmer Vernooij]

On Sun, Jan 24, 2016 at 11:44:53AM +1100, Brian May wrote:
> Ryan Tandy  writes:
> 
> > Since the .la files moved from /usr/lib/$arch to /usr/lib/$arch/heimdal, 
> > looks like their contents also need to be updated.
> 
> According to debian/changelog I deleted the *.la files in version
> 1.4.0-5 with a reference to #621340
> 
> #621340 seems to indicate it was removed for this very reason.
> 
> So I don't know what happened, apparently the *.la files seem to have
> come back again.

They were still installed in recent versions, but with my recent
upload te .la files have moved from /usr/lib/ to
/usr/lib//heimdal.

I'll re-remove them in the next upload.

Jelmer


signature.asc
Description: PGP signature

Bug#812398: openldap: FTBFS: can't read /usr/lib/x86_64-linux-gnu/libhdb.la

[Jelmer Vernooij]

On Sun, Jan 24, 2016 at 11:44:53AM +1100, Brian May wrote:
> Ryan Tandy  writes:
> 
> > Since the .la files moved from /usr/lib/$arch to /usr/lib/$arch/heimdal, 
> > looks like their contents also need to be updated.
> 
> According to debian/changelog I deleted the *.la files in version
> 1.4.0-5 with a reference to #621340
> 
> #621340 seems to indicate it was removed for this very reason.
> 
> So I don't know what happened, apparently the *.la files seem to have
> come back again.

They were still installed in recent versions, but with my recent
upload te .la files have moved from /usr/lib/ to
/usr/lib//heimdal.

I'll re-remove them in the next upload.

Jelmer


signature.asc
Description: PGP signature

Bug#808769: [Pkg-samba-maint] Bug#808769: Bug#808769: Bug#808769: LDB build failure isn't a regression

[Jelmer Vernooij]

On Sun, Jan 03, 2016 at 11:36:18AM +1300, Andrew Bartlett wrote:
> On Sat, 2016-01-02 at 22:22 +0000, Jelmer Vernooij wrote:
> > On Sun, Jan 03, 2016 at 11:00:44AM +1300, Andrew Bartlett wrote:
> > > On Sat, 2016-01-02 at 21:51 +0000, Jelmer Vernooij wrote:
> > > > On Sun, Jan 03, 2016 at 10:38:12AM +1300, Andrew Bartlett wrote:
> > > > > On Thu, 2015-12-31 at 18:53 +1300, Andrew Bartlett wrote:
> > > > > > Just a quick note to say that the LDB build failure isn't a
> > > > > > regression 
> > > > > > - whatever is going on here has always been going on, it just
> > > > > > wasn't
> > > > > > tested before ldb 1.1.23.
> > > > > 
> > > > > > That said, fixing this is going to require gdb on a s390.  Is
> > > > > > the
> > > > > > porterbox where that should be done?
> > > > > > 
> > > > > > https://db.debian.org/machines.cgi?host=zelenka
> > > > > > 
> > > > > > How do I get on such a machine?
> > > > > 
> > > > > I've asked (but not yet got, which is reasonable over the
> > > > > holidays)
> > > > > access to this machine.
> > > > FWIW this issue is reproducible on other platforms than s390 too.
> > > 
> > > Can you get me details?
> > Sorry, I don't really have any other than that I've managed to hit it
> > a few times while building locally on my amd64 laptop.
> 
> Can we re-submit it and see if it flaps to success this time?
> 
> Given it doesn't show up under valgrind or under multiple runs (Fedora
> x64, git master) here, this is going to be difficult.

I think it was consistently failing when I encountered it (on my
laptop, not in a chroot), and both s390 buildd builds (and the ubuntu
build) failed too so it is not likely to be flaky there:

https://buildd.debian.org/status/logs.php?pkg=ldb&ver=2%3A1.1.24-1&arch=s390x

Unfortunately it seems to pass on my laptop now, though I am not sure
what has changed to make it pass there.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#808769: [Pkg-samba-maint] Bug#808769: Bug#808769: LDB build failure isn't a regression

[Jelmer Vernooij]

On Sun, Jan 03, 2016 at 11:00:44AM +1300, Andrew Bartlett wrote:
> On Sat, 2016-01-02 at 21:51 +0000, Jelmer Vernooij wrote:
> > On Sun, Jan 03, 2016 at 10:38:12AM +1300, Andrew Bartlett wrote:
> > > On Thu, 2015-12-31 at 18:53 +1300, Andrew Bartlett wrote:
> > > > Just a quick note to say that the LDB build failure isn't a
> > > > regression 
> > > > - whatever is going on here has always been going on, it just
> > > > wasn't
> > > > tested before ldb 1.1.23.
> > > 
> > > > That said, fixing this is going to require gdb on a s390.  Is the
> > > > porterbox where that should be done?
> > > > 
> > > > https://db.debian.org/machines.cgi?host=zelenka
> > > > 
> > > > How do I get on such a machine?
> > > 
> > > I've asked (but not yet got, which is reasonable over the holidays)
> > > access to this machine.
> > FWIW this issue is reproducible on other platforms than s390 too.
> 
> Can you get me details?
Sorry, I don't really have any other than that I've managed to hit it
a few times while building locally on my amd64 laptop.

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#808769: [Pkg-samba-maint] Bug#808769: LDB build failure isn't a regression

[Jelmer Vernooij]

On Sat, Jan 02, 2016 at 09:51:34PM +, Jelmer Vernooij wrote:
> On Sun, Jan 03, 2016 at 10:38:12AM +1300, Andrew Bartlett wrote:
> > On Thu, 2015-12-31 at 18:53 +1300, Andrew Bartlett wrote:
> > > Just a quick note to say that the LDB build failure isn't a
> > > regression 
> > > - whatever is going on here has always been going on, it just wasn't
> > > tested before ldb 1.1.23.
> > 
> > > That said, fixing this is going to require gdb on a s390.  Is the
> > > porterbox where that should be done?
> > > 
> > > https://db.debian.org/machines.cgi?host=zelenka
> > > 
> > > How do I get on such a machine?
> > 
> > I've asked (but not yet got, which is reasonable over the holidays)
> > access to this machine.
> FWIW this issue is reproducible on other platforms than s390 too.
+xnox, who is working on Ubuntu on s390 and was asking about this
specific issue earlier :)

Jelmer


signature.asc
Description: PGP signature

Bug#808769: [Pkg-samba-maint] Bug#808769: LDB build failure isn't a regression

[Jelmer Vernooij]

On Sun, Jan 03, 2016 at 10:38:12AM +1300, Andrew Bartlett wrote:
> On Thu, 2015-12-31 at 18:53 +1300, Andrew Bartlett wrote:
> > Just a quick note to say that the LDB build failure isn't a
> > regression 
> > - whatever is going on here has always been going on, it just wasn't
> > tested before ldb 1.1.23.
> 
> > That said, fixing this is going to require gdb on a s390.  Is the
> > porterbox where that should be done?
> > 
> > https://db.debian.org/machines.cgi?host=zelenka
> > 
> > How do I get on such a machine?
> 
> I've asked (but not yet got, which is reasonable over the holidays)
> access to this machine.
FWIW this issue is reproducible on other platforms than s390 too.

Cheers,

Jelmer


signature.asc
Description: PGP signature